Intent to Ship: Compression dictionary transport Updates
Frédéric Wang Nélar
Gecko: Mozilla is implementing Compression dictionary transport and will have to align with the changes to make the test pass.
WebKit: Igalia is currently upstreaming their implementation and we are aligned with these changes.
Web developers: No signals
Other signals:
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No information providedhttps://wpt.fyi/results/fetch/compression-dictionary/fetch-destination.tentative.https.html
https://wpt.fyi/results/fetch/compression-dictionary/dictionary-fetch-with-link-element-crossorigin.tentative.https.html
https://wpt.fyi/results/fetch/compression-dictionary/dictionary-fetch-with-link-referrer-and-referrerpolicy.tentative.https.html
| Shipping on desktop | 156 |
Dan Clark
Yoav Weiss (@Shopify)
Frédéric Wang Nélar
> Specification> 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 CompatibilityNo 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?
- 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.
Daniel Bratell
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
--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5cb080a5-6d3d-4205-a1ed-23755ad23ec9%40igalia.com.
Yoav Weiss (@Shopify)
Do you know if they shipped with these updates? Are there tests for these updates?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Patrick Meenan
The RFC was ratified some last year if I remember right. The fetch and html spec PR's have mostly been waiting on a second implementor and for final sign-off from the owners before merging. There have been a bunch of spec language/flow changes since the feature launched but mostly just to get the PR to properly plug the RFC into the spec-defined path - the Chrome implementation hasn't substantially changed.
I'm not 100% sure that the new platform status entry is needed. AFAIK, it's mostly fixes to align with the actual spec writeup and there were a couple of bugs that were closed but nothing that changed from a web developer's perspective (except maybe the compression-dictionary dest). There were a lot of WPT tests added as part of the effort to make sure we have consistent cross-browser behavior, particularly around CORS handling.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Frédéric Wang Nélar
> 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?
>
general. This has been implemented in Firefox
(https://bugzilla.mozilla.org/show_bug.cgi?id=1882979) and WebKit
(https://bugs.webkit.org/show_bug.cgi?id=295249) recently, after RFC was
ratified but while the HTML and fetch PRs were still under review. Some
spec clarification happened during that period and a lot of new tests
added but mostly they follow what Chromium ships. I can't speak for
Mozilla, but at Igalia, we have been closely following the spec/tests
changes and once the runtime flag is enabled WebKit should also pass
most of the tests.
Now regarding the updates, as I mentioned in the intent to ship,
specific tests for them are:
https://wpt.fyi/results/fetch/compression-dictionary/fetch-destination.tentative.https.html
https://wpt.fyi/results/fetch/compression-dictionary/dictionary-fetch-with-link-element-crossorigin.tentative.https.html
https://wpt.fyi/results/fetch/compression-dictionary/dictionary-fetch-with-link-referrer-and-referrerpolicy.tentative.https.html
WebKit once the runtime flag is enabled.
I see Firefox is only failing request destination, I opened
https://bugzilla.mozilla.org/show_bug.cgi?id=2077064 so they have it
tracked.
Frédéric Wang Nélar
Sorry, I was planning to do it but I forgot. Review requested now.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d9b21640-1e86-4e13-95d6-495ec8b8d2c8%40gmail.com.
Alex Russell
Sorry, I was planning to do it but I forgot. Review requested now.
Le 30/09/2026 à 16:48, Daniel Bratell a écrit :
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
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.
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:> Interoperability and CompatibilityNo 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?
- 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 blink-dev+unsubscribe@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5cb080a5-6d3d-4205-a1ed-23755ad23ec9%40igalia.com.
--
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 blink-dev+unsubscribe@chromium.org.
Philip Jägenstedt
LGTM1 contingent on nits being satisfied.
On Thursday, October 1, 2026 at 1:16:35 PM UTC+2 fw...@igalia.com wrote:
Sorry, I was planning to do it but I forgot. Review requested now.
Le 30/09/2026 à 16:48, Daniel Bratell a écrit :
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
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.
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:> Interoperability and CompatibilityNo 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?
- 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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5cb080a5-6d3d-4205-a1ed-23755ad23ec9%40igalia.com.
--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d9b21640-1e86-4e13-95d6-495ec8b8d2c8%40gmail.com.
--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e933f8bf-5fd8-4a49-b42c-ae082c2f11fdn%40chromium.org.