Updating structured headers - Intent required?

[Ian Clelland]

Hey folks,

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.

Context:

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:

Permissions-Policy

Document-Policy

Reporting-Endpoints

BFCache-Opt-In
Accept-CH, Critical-CH
Supports-Loading-Mode
(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)

Change:

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.

Impact:

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?

Thanks!

Ian

[Mike West]

Hey Ian,

I think dropping our draft 15 implementation in favor of the RFC is a bug fix that might warrant a PSA to verify that we're aligning to the RFC, but does not warrant an intent in itself.

(I'd also like us to figure out how to drop the draft 9 implementation, but that would likely be a little more work given the unfortunate dependency.)

-mike

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAK_TSXJh2hY00MFSnk3kLuOKp4u_kn4ZgNmF%3DfbPz69da5jKcA%40mail.gmail.com.

[Ian Clelland]

Thanks, Mike! I'll send out a PSA to blink-dev and net-dev with the details.

Agreed that we should deprecate the old syntax. I had a plan for that a couple of years ago; I'll see if I can dig it up.

Ian