Casing of client headers is maybe not accurate #475
Comments
…ders() After whatwg/xhr#130, getAllResponseHeaders() runs the "sort and combine" step described in the Fetch spec, which, as of whatwg/fetch#475, causes all header names to be byte-lowercased. The regular expression in getresponseheader-chunked-trailer.htm was still trying to match "Trailer" instead of "trailer", which caused it to fail with conformant implementations.
|
@igrigorik ping. |
|
Apologies, missed this earlier. Header names are case insensitive and explicitly downcased in h2. I believe current spec definitions are a-OK. Close with no action? |
|
@igrigorik that's not true for HTTP/1 (and we actually tried lowercasing there too for a bit and it broke things). |
|
I wonder if you'll still find that breakage; we saw a little bit when H2 was deployed, but haven't heard much since. Of course, h2 is opt-in by the site... |
|
The breakage was for changing it for HTTP/1, where this matters. It was pretty recent (that's why we changed a whole bunch of things around casing in the standard). |
|
Right, but HTTP is a hop-by-hop protocol; people can (and do) use it for proxies, reverse proxies, CDNs, etc., with different versions on both sides. |
|
Yeah, breakage might increase over time. Once we disable HTTP/1 support we can remove this, but until then we might as well stick to consistent casing there. |
|
Fair enough 👍 |
Also consistly make appending these headers a "should". Fixes #475.
In step 6 of https://fetch.spec.whatwg.org/#concept-fetch we should maybe use
DPR,Save-Data, etc.? @igrigorik thoughts?The text was updated successfully, but these errors were encountered: