Looking at WPTs, it seems like Firefox is passing most of them: https://wpt.fyi/results/fetch/compression-dictionary?label=experimental&label=master&aligned
Do you know if they shipped with these updates? Are there tests for these updates? On Wednesday, September 30, 2026 at 4:48:58 PM UTC+2 Daniel Bratell wrote: > Looking at the shipping entry in chromestatus, it seems to lack the > necessary reviews for privacy, security and so on. Can you please request > those parts? > > (Yoav mentioned this last week but maybe his mail got lost) > > /Daniel > On 2026-09-28 16:39, Frédéric Wang Nélar wrote: > > > Le 21/09/2026 à 20:17, 'Dan Clark' via blink-dev a écrit : > > *> Specification* > *> https://github.com/whatwg/html/pull/11620 > <https://github.com/whatwg/html/pull/11620>* > > Is anything blocking this spec PR from landing? > > Patrick can say more but I think this just pending review from the WHATWG > editors and addressing review comments, no fundamental blockers. > > That said, this PR is much bigger that the small changes proposed here. > Actually none of the compression dictionary PRs ( > https://github.com/whatwg/html/pull/11620 > https://github.com/w3c/webappsec-clear-site-data/pull/94 > https://github.com/whatwg/fetch/pull/1854) are merged yet but API owners > already approved shipping this feature in > https://groups.google.com/a/chromium.org/g/blink-dev/c/MuaRf28nExk. The > change I'm proposing here only aligns with the spec PR / tests / webkit so > in some way, doing soe would help a bit to get the spec PR merged. > > > *Interoperability and Compatibility* > *No information provided* > > Since this would change a shipped API, can you comment on the > compatibility risk? Is there a possibility that sites already using the > feature could be affected? > > Again, Patrick is probably in a better position to comment, but AFAIK we > haven't done any stats on current usage, because the expectation that this > change is minor and wouldn't have compat impact: > > - For the fetch parameters, I understand they were too restrictive in the > initially shipped implementation, and were also ignoring attributes that > allow to change the default behavior. So removing this restriction > shouldn't "break" websites (in the sense that some fetches could start > being blocked). It also aligns with what other kinds of links are doing, so > it's something more expected for developers and following existing security > models. > > - Regarding the "compression-dictionary" string, typical way of triggering > a dictionary load is via the link element / header and the destination > string is only set when the fetch request is created, without implication > on how the compression dictionary is used later. It's possible for > developers to observe this destination string (WPT tests I mentioned above > do that with some complex logic involving a worker that observes fetch > events) but it's not clear to me what would be the use case for that. > > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5cb080a5-6d3d-4205-a1ed-23755ad23ec9%40igalia.com > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5cb080a5-6d3d-4205-a1ed-23755ad23ec9%40igalia.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/07ea6855-aeb0-4cb7-9077-c532a91a30f9n%40chromium.org.
