Now that it has been published as an official RFC (RFC8941
), I'm in the process of updating Chrome's Structured-Headers implementation
to conform to the spec, and I'm looking for some guidance on whether this is a bug fix, or something which would require an intent.
Chrome implements two revisions of the structured headers spec. We maintain Draft 9, from circa 2018, for compatibility with the shipped WebPackaging implementation, and we have been using Draft 15 for all other features which use structured headers.
Chrome currently uses the Draft 15 structured headers parsing code for:
(For Trust tokens, it also parses Signed-Headers, Sec-Redemption-Record and Sec-Signature, but only from internally generated data -- they are request, not response headers -- or in unit tests)
There were very few changes between the Draft 15 and the final RFC; the only actual substantive change appears to be that a tab character is now accepted as a separator between top-level list and dictionary items, where before that character would have caused the parser to reject the header.
To validate that, I've regenerated all of the unit tests from the public test repo
, and confirmed that allowing TAB as a separator is the only failing behaviour.
The CL which would make this change is here
I ran an analysis
of 514M responses in HTTP Archive, and found 20K
pages (0.004%) whose response headers contained a raw TAB character, and of those, only 23
were in a header for which Chrome actually uses the SH parser. (All of those were for Permissions Policy). Those 23
responses come from exactly 4
origins (as shown in the spreadsheet). One of them is clearly malformed, while the others will start working once the change is pushed.
This is technically a web-visible change, though an extremely minor fix to bring everything in line with specs (none of the specs or code ever explicitly depended on Draft 15; the expected behaviour should be in line with the RFC) The impact seems tiny, and only positive (this shouldn't break anything; nothing should have been relying on this quirk, and HTTPArchive analysis seems to support that.)
My question for API owners is whether we can call this a bug fix (with a PSA), or should I file launch bugs, Chromestatus entries and an I2S?