Unfortunately, removing old behavior here is now pretty resource intensive, in terms of launch process in Chrome:

• Add code to gather data, wait months for data.
• Get feedback from other browsers [I don't think I've ever been in contact with a single Safari person]
• Go through intent process (Tag review can probably be skipped, at least)
• Usher through release process

As I'm not longer on the network team, I have limited time to work on this sort of stuff. That having been said, I certainly support adding tests and working towards both tighter parsing and unifying behavior here, and I can probably find time to address what I view as most concerning (which, here, is status code handling/overflow).

@kinu @yutakahirano: Kinuko, Yutaka, would your team be interested in pursuing this?

Another fun one: Chrome allows 4 bytes of random slop between requests, before the start of headers. I believe this was copied from FireFox of IE's behavior at the time. I don't believe all browsers currently do this, so it may be easier to remove. My main concern is servers sending 0-length compressed gzip bodies with "Content-Length: 0", which aren't actually of length 0. In this case, there's slop on the end, which I suspect this logic deals with.

Several other differences I discovered:

1. Space (or tab) between header-name and :, e.g., x-frame-options : DENY:

• HTTP spec says that servers MUST reject such responses and proxies must remove such whitespace. It does not say what clients should do.
• Firefox ignores only the invalid header
• Chromium and Safari ignore the space, even the invalid header gets parsed and in the example here: XFO is applied

2. NULL bytes in header names

• Invalid according to the spec (token) but unclear what clients should do
• Firefox and Safari only ignore the invalid header
• Chromium treats the whole response as invalid (network error), similar to NULL in header values

3. NULL in header values

• Agreement seems to be network error
• Tests do not test for all kind of inclusions: e.g., no tests for fetch where currently browser behavior diverges

4. Lone LF (0x0A) in responses

• Similar to lone CR
• Currently behavior diverges for both browsers and within browsers (fetch (simple vs complex) vs document vs subresource, ...)
• Behavior also depends on where the lone LF is encountered, adding a bunch of tests is probably helpful
• Probably related: Acting on incomplete headers #472

5. Lone CR (0x0D) in responses

• Mostly tested in HTTP: message parsing with CR web-platform-tests/wpt#13524
• Currently, only tests with fetch, it seems to be sometimes different to top-level, or subresource parsing

A couple thoughts (note that I'm no longer on Chrome's network team, though still care about this area).

Several other differences I discovered:

1. Space (or tab) between header-name and :, e.g., x-frame-options : DENY:

• HTTP spec says that servers MUST reject such responses and proxies must remove such whitespace. It does not say what clients should do.

It would seem very weird if proxies remove it, but clients were expected to reject it. Then some sites would only work with a compliant browser connecting through a compliant proxy, but not with a compliant browser directly making the requests.

2. NULL bytes in header names
3. NULL in header values

Chrome currently rejects responses with NULLs anywhere in the headers (including in status text). Not claiming this is the correct behavior.

Other weirdness that may be worth thinking about, if you haven't already. Only know how Chrome handles these:

• Chrome allows 4 bytes of slop before the "http" (including NULLs). I assume this is for buggy servers that send 0-byte compressed bodies when they should be sending nothing, but not positive of that. Think this was copied from another browser's behavior before Chrome was released.
• Chrome allows truncated headers (Server closes socket after only sending partial headers - that is, no double terminating CRLF, or possibly no terminating CRLF at all). Chrome only does this for HTTP (not HTTPS), for security reasons, since truncating an http-only or whatnot from a Set-Cookie header is a security issue.