-
Notifications
You must be signed in to change notification settings - Fork 324
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTTP/1 parsing #1156
Comments
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? |
Tests: web-platform-tests/wpt#27421. Follow-up: #1156. Closes #1142.
Tests: web-platform-tests/wpt#27421. Follow-up: #1156. Closes #1142.
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. |
As the body concept is refactored for #604, XMLHttpRequest will need to use this algorithm for its events. We also want to require browsers to use this algorithm instead of the one defined by HTTP as part of #1156. Tests: web-platform-tests/wpt#10548 & web-platform-tests/wpt#27837.
As the body concept is refactored for #604, XMLHttpRequest will need to use this algorithm for its events. We also want to require browsers to use this algorithm instead of the one defined by HTTP as part of #1156. Tests: web-platform-tests/wpt#10548.
Several other differences I discovered:
|
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:
|
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.
Content-Type
andContent-Length
: Redesign "extract header values" and "extract header list values" #814cc @whatwg/http
(Previously there was https://wiki.whatwg.org/wiki/HTTP.)
The text was updated successfully, but these errors were encountered: