Re: [whatwg/fetch] HTTP/1 parsing (#1156)

Several other differences I discovered:
1. Space (or tab) between `header-name` and `:`, e.g., `x-frame-options : DENY`:
- [HTTP spec](https://www.rfc-editor.org/rfc/rfc9112.html#name-field-line-parsing) 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](https://github.com/whatwg/fetch/issues/1747)
- 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](https://github.com/web-platform-tests/wpt/issues/45737) 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: https://github.com/whatwg/fetch/issues/472
5. Lone CR (0x0D) in responses
- Mostly tested in https://github.com/web-platform-tests/wpt/pull/13524
- Currently, only tests with `fetch`, it seems to be sometimes different to top-level, or subresource parsing

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1156#issuecomment-2059234753
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1156/2059234753@github.com>