PSA: Updating Chrome's Structured-Fields implementation to match RFC8941

28 views
Skip to first unread message

Ian Clelland

unread,
Mar 9, 2022, 1:05:34 PM3/9/22
to blink-dev, net-dev
tl;dr: Chrome will start accepting TAB characters as separators in some headers. You almost certainly don't need to do anything.

Long version:
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. This will replace the existing code which implemented Draft 15.

Chrome currently uses the Draft 15 structured headers parsing code for:
Permissions-Policy
Document-Policy
Reporting-Endpoints
BFCache-Opt-In
Accept-CH, Critical-CH
Supports-Loading-Mode

(For Trust tokens, it also parses Signed-HeadersSec-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, whereas before that character would have caused the parser to reject the header. (There was an additional change regarding the support for asterisks starting certain fields, but we had already implemented that.)

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.)

Ian
Reply all
Reply to author
Forward
0 new messages