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

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](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.

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](https://github.com/whatwg/fetch/issues/1747)
> 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.

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

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