Repository navigation
HTTP/1 parsing #1156
Description
HTTP/1 was poorly tested for error handling and as a result implementations are not interoperable. This lack of interoperability reaches Fetch at times. Where HTTP/1 itself takes no stance or implementations cannot follow it, it might make sense to document it in Fetch or at least document it in this issue.
- status-line parsing: Test HTTP parsing web-platform-tests/wpt#5102
- status-code parsing: "A status is a code" doesn't actually mean anything #1142
- message parsing (in particular incomplete responses): Acting on incomplete headers #472
- CR parsing: HTTP: message parsing with CR web-platform-tests/wpt#13524
- 0x00 parsing: Why does headers-normalize-response.htm expect null bytes to be allowed? xhr#165 (comment) (apart from Firefox and a bug in Safari this is pretty close; agreement here is network error)
- field-value is "incorrect" (this might go beyond H/1, not sure): https://fetch.spec.whatwg.org/#concept-header-value (there is agreement on this, modulo 0x00 above)
- Parsing of specific headers (this goes beyond H/1), such as
Content-TypeandContent-Length: Redesign "extract header values" and "extract header list values" #814
cc @whatwg/http
(Previously there was https://wiki.whatwg.org/wiki/HTTP.)
Activity
MattMenke2 commentedon Feb 1, 2021
Unfortunately, removing old behavior here is now pretty resource intensive, in terms of launch process in Chrome:
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?
Clarify what a status is
Clarify what a status is
MattMenke2 commentedon Feb 3, 2021
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.
Define Content-Length parser
Define Content-Length parser
JannisBush commentedon Apr 16, 2024
Several other differences I discovered:
header-nameand:, e.g.,x-frame-options : DENY:fetch, it seems to be sometimes different to top-level, or subresource parsingMattMenke2 commentedon Apr 16, 2024
A couple thoughts (note that I'm no longer on Chrome's network team, though still care about this area).
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.
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: