Consider restricting 103 Early Hints to HTTP/2 or later

[tunetheweb]

As mentioned in various places (see references below), informational responses like 103 Early Hints were previously not common, and may cause issues for clients that do not expect these. Should we restrict 103 Early Hints in the browser context to HTTP/2 or later as most implementations have done so far?

• 103 Early Hints RFC 8297 Security Considerations
• Chrome only implemented support on HTTP/2 or above
• Safari only implemented support on HTTP/2 or above
• Cloudflare only implemented support on HTTP/2 or above
• Fastly only implemented support on HTTP/2 or above
• Apache only implemented support on HTTP/2 or above

In fact the only HTTP/1.1 implementation I am aware of is Firefox, but this still has not been enabled by default.

[annevk]

@valenting thoughts?

cc @mnot @ekinnear

[mnot]

The security (and interoperablity) considerations mostly fall on servers in terms of what they send hints to (because some clients don't handle them well); a client artificially constraining whether they accept hints isn't very helpful.

[davidben]

To add to that, I think this bug may be based on a slightly mixed up premise. None of the reasons about early hints over HTTP/1.1 are related to browsers. Even if some browsers only pay attention to early hints over HTTP/2, doesn't mean it's unsafe to send them over HTTP/1.1. It's still a 1xx response code, which, as far as I know browsers all correctly skip over. It may be pointless if unused, but it's still safe to send when the other end is a browser HTTP/1.1 stack.

The problem is there are a lot of HTTP/1.1 clients out there, not just browsers. There are also a lot of HTTP/1.1 intermediaries, including deployments where those intermediaries may be in front of browsers, so even a browser's UA string may not be enough. Broken HTTP/1.1 clients may not necessarily correctly skip over 1xx responses, which would then cause a problem. Thus, RFC 8297 recommends against sending it over HTTP/1.1. But the Chrome or Safari behavior cited in the bug is not a reason for it.

Conversely, the RFC 8297 recommendation isn't a reason for browsers to ignore early hints over HTTP/1.1. I don't think it's worth putting a whole lot of effort into it (servers can't safely deploy it anyway, and anyone who cares about perf should start by updating to HTTP/2), but it's also perfectly fine to process them.

[davidben]

@bashi and @ricea FYI, regarding https://crrev.com/c/4603363

[valenting]

In fact the only HTTP/1.1 implementation I am aware of is Firefox, but this still has not been enabled by default.

Indeed Firefox accepts early hints over HTTP/1.1, but that doesn't necessarily mean that it should. In fact, it's entirely possible that it could hurt performance when used with HTTP/1.1, but we haven't actually looked at it until now. We are currently looking into adding telemetry for how often we see this on the web, and if it has any performance impact. We'll probably end up only allowing EH on H2+ protocols anyway.

[annevk]

Having some data sounds good!

I would prefer mandating something one way or another so web developers know what to expect. We similarly restricted streaming features to H/2 so this would be consistent with that.