Seed 103 Early Hints support

[casperisfine]

I'm trying to help https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103 go a bit forward, and I think MDB compatibility data could go a long way.

I only have a few browsers around to test myself, but since at this stage no browser actually implement it, but most of them simply ignore 1xx responses, I think it would be fair to assume the support list is the same than for 100 Continue.

Fastly did put a test page online: https://early-hints.fastlylabs.com/
They do say they found a few browsers with early HTT2 support that did break https://www.fastly.com/blog/beyond-server-push-experimenting-with-the-103-early-hints-status-code

cc @mnot maybe you have some data to share?

[mnot]

So far, I haven't seen any reports from the form on that page. The only interoperability issue I'm aware of is by word of mouth from the Chrome team; apparently an early beta of H2 support in Android Browser had issues with 1xx responses.

[casperisfine]

Thanks!

[sideshowbarker]

I think our current policy is that we always try to add specific browser version numbers rather than "version_added": true — unless it’s impossible or completely impractical to determine which browser version numbers to add.

[ddbeck]

Hi @casperisfine and thanks for this PR. I see this is your first on the repo—welcome to BCD!

I have one concrete suggestion in a line comment. But a bigger concern I have is the story that the notes and "partial_implementation" flag are telling here.

Generally, we use the partial flag to indicate that a specified but required behavior is missing (e.g., an API that's specified as having two or three parameters, but an implementation that only accepts two). But a quick read of the spec seems to indicate that there's no obligatory client behavior (though it's possible I've misunderstood—I'd like to be corrected if I'm wrong).

But the notes here say that browsers are consistent in ignoring the header, even a browser which predated the specification of this feature, IE 11. If this is a partial implementation, how would I know when browsers fully implement this feature? Or, to put this another way, what has each browser done to affirmatively implement this feature?

[ddbeck]

I'm pretty sure 100 Continue isn't going anywhere 😄

Suggested change

	"experimental": true,
	"experimental": false,

[casperisfine]

Arf, no idea what happened here. I'll flip it back.

[casperisfine]

how would I know when browsers fully implement this feature?

Well, a browser actually implementing the feature would use the 103 Early Hint response to start prefetching assets. No browser does this today. Chrome did ship some instrumentation to to gather data and consider later wether it's worth implementing it.

[ddbeck]

Thanks for the context, @casperisfine. After doing some more reading and mulling this over for a while, I've come to the conclusion that ignoring 103 is an expected, specified behavior relating to status code 100. For instance, RFC 7231 section 6:

a client MUST understand the class of any status code, as indicated by the first digit, and treat an unrecognized status code as being equivalent to the x00 status code of that class

The change proposed here muddies things for web developers. It suggests that it's partially implemented when browsers are, so far, handling an unexpected status code as the specs require. It's interesting that Chrome is collecting data on this, however.

If Chrome (or another browser) does decide to implement behavior based on this status code, then I would encourage you to reopen a PR for this feature at that time, but right now, I think it's a bit early in the process to add this compat data.

Thank you for your understanding!

[casperisfine]

Up to you

It suggests that it's partially implemented when browsers are, so far, handling an unexpected status code as the specs require.

Well, they could very well have been broken by it. Nginx for instance isn't proxying such response properly (last time I checked).