Test HTTP parsing - #5102

@mnot this is a mess. I guess I can change the pass conditions for a couple of these (though not entirely clear if they all should outright fail or do something else), but I wonder how much browsers are willing to change here. IETF should get a bit more serious about testing I think.

Result in Safari TP Release 24 (Safari 10.2, WebKit 12604.1.6)

There isn't any intention of introducing new versions of HTTP/1, because this phenomenon has been observed for a long time; there are lots of bits of software that get this wrong (not just browsers).

See also: https://tools.ietf.org/html/rfc2145#section-2

All of that said, I understand that there are some situations where browsers need to treat protocols specially, e.g., for ICECAST and a few others. @mcmanus might have some thoughts here.

most of these non HTTP/1 cases are being interpreted as HTTP 0.9... which is fair enough - they aren't HTTP/1 and there is no version negotiation outside of the TCP stream. There is no response code in 0.9 so calling it 200 or parsing it and calling it 280 all seem fair game. Not a useful test.

The exception is the HTTP/2 case (in what is obviously not RFC 7540 HTTP2..).. as mark notes, that's just a bugwards accommodation for shoutcast to treat that as http/1. Similarly allowing mixed-case HttP is something that a receiver is just going to do for legacy interop. We've cleaned it up going forward

Right, it seems suspicious that all user agents support HTTP/2.0 and case-insensitive mostly worked.

There's also a difference between returning a network error and continuing to treat as HTTP/0.9 (the latter is what Firefox does and Edge maybe (although Edge uses the status code 520), the former is more like Safari and Chrome (although Chrome only does one scenario that way)).

So if some of this is required it would be good if the HTTP specification actually said so. Otherwise it's hard to come up with pass/fail criteria here and get browsers to align on how they handle pass/fail.

There are no owners for this pull request. Please reach out on W3C's irc server (irc.w3.org, port 6665) on channel #testing (web client) to get help with this. Thank you!

@MattMenke2 Could you tell me if Chrome uses the same HTTP parser in Fetch and in normal loads? And more generally, could you link me to the code, please?

Chrome uses the same HTTP parsers for all requests.

https://source.chromium.org/chromium/chromium/src/+/master:net/http/http_stream_parser.h is Chrome's HTTP/0.9 and HTTP/1.x parser (assume you don't also want H/2 or H/3 as those are much more complicated).

HttpStreamParser::FindAndParseResponseHeaders (https://source.chromium.org/chromium/chromium/src/+/master:net/http/http_stream_parser.cc;drc=6687e9201a1b0d2c9c81ad7e4dd113fb09547953;bpv=0;bpt=1;l=966) is the most relevant function, along with the HttpUtil/HttpResponseHeaders methods it calls, though need to go a level up if you want to dig into how Chrome deals with truncated responses.

There's a lot of allowance for incorrectly formatted headers that would be great if we could get rid of, but not sure how much interest there is in actively investing in it, since deprecations can involve a lot of legwork.

https://source.chromium.org/chromium/chromium/src/+/master:net/http/http_stream_parser.h is Chrome's HTTP/0.9 and HTTP/1.x parser (assume you don't also want H/2 or H/3 as those are much more complicated).

So Chrome does accept HTTP/0.9 responses? In which circumstances? I ran this PR and tried to load https://web-platform.test:8443/http/resources/version.py?input=splitonspace%20280 in Chrome and got a ERR_INVALID_HTTP_RESPONSE error page from the UA.

Oh, that's because 8443 is not the default port, I see. https://source.chromium.org/chromium/chromium/src/+/master:net/http/http_stream_parser.cc;l=1022-1023;drc=6687e9201a1b0d2c9c81ad7e4dd113fb09547953

Yea, other than on default ports, Chrome only allows HTTP/0.9 for Shoutcast responses ("ICY/...") over HTTP, because we got a bunch of bug reports about that when we disabled HTTP/0.9 on non-standard ports.