Repository navigation
Redesign "extract header values" and "extract header list values" #814
Description
These APIs had the wrong design and are also incorrectly used at times (#559). "Extract a MIME type" also needs a new design, likely on top of this as a new Content-Type parser: #529.
In particular, other than for Set-Cookie the ideal way to parse a header is to combine first, and then parse, which isn't really what the current operations are doing. How to combine headers is nearly settled: #813. Once that's done my tentative plan is to introduce a new "get" for header lists to solve #752 which would return null or the combined value for a given header name from a header list.
Another problem with the current setup is that the actual parsing is handwavy by referencing ABNF defined "somewhere", which in practice leads to it being poorly tested. We can continue to allow ABNF for headers where that is actually how they are implemented, but we need to be more strict about referencing the ABNF and writing the tests and not allowing as much indirection as is currently allowed for.
Unfortunately this will impact downstream, but I think it's the right thing to do long term and will lead to better considered header parsers (and encourage more reuse as well). I'll also start filing downstream issues now linking this issue to ensure we actually design something that works for everyone.
So I think what we want is basically "get" and then per header name we'll need to define its parser (which could just be an ANBF reference plus tests) or parsers (Content-Type differs between request and response, yay). Thoughts on the details here appreciated as well as on the overall plan of course.
Activity
Define parsing for X-Content-Type-Options in detail
annevk commentedon Oct 18, 2018
In #818 @mikewest suggested that perhaps it'd be useful if there was a way to always get the "string" value from a header. So basically "get" on a header list and then return the result of isomorphic decoding that (if non-null). We could add "get as string" for this provided there's more than one consumer, which seems likely if we'll continue to define most parsers on top of strings.
annevk commentedon Oct 19, 2018
Things to define anew within Fetch (and test) to get rid of "extract header values":
request DPR/Downlink/Save-Data/Viewport-Width/Width (CORS-safelisted request-header)For "extract header list values":
Define parsing for X-Content-Type-Options: nosniff in detail
annevk commentedon Nov 1, 2018
There's also headers that maybe should be defined in Fetch (or HTTP if it wants to tackle error handling):
(I might end up tracking these separately though as these would be additions rather than refactoring the status quo.)
Fetch: Access-Control-Expose-Headers parsing
Be strict on request's Content-Type
Be strict on request's Content-Type
Define the response Content-Type header parser
Define the response Content-Type header parser
Fetch: Access-Control-Expose-Headers parsing
Bug 1504103 [wpt PR 13849] - Fetch: Access-Control-Expose-Headers par…
annevk commentedon Nov 23, 2018
In HTML:
Define the Content-Type header parser
Bug 1504103 [wpt PR 13849] - Fetch: Access-Control-Expose-Headers par…
Bug 1504103 [wpt PR 13849] - Fetch: Access-Control-Expose-Headers par…
Bug 1504103 [wpt PR 13849] - Fetch: Access-Control-Expose-Headers par…
CORS preflight should use the default max-age on parse failure