Compression Dictionary support for cross-origin no-cors requests #644
Description
WebKittens
Title of the proposal
Compression Dictionary support for cross-origin no-cors requests
URL to the spec
https://fetch.spec.whatwg.org/
URL to the spec's repository
https://github.com/whatwg/fetch
Issue Tracker URL
No response
Explainer URL
No response
TAG Design Review URL
Mozilla standards-positions issue URL
mozilla/standards-positions#1381
WebKit Bugzilla URL
No response
Radar URL
No response
Description
This is a change to Compression Dictionary Transport that we talked about during the fetch spec integration for the browser-specific CORS readability issues that are not covered by the RFC.
Current WPT's and Chrome's implementation do not allow dictionary compression for cross-origin no-cors requests to prevent oracle attacks (and clients don't send the Accept-Encoding or dictionary headers for those requests).
At TPAC 2025 in the TAG general discussion, we came up with a solution of leveraging the existing Cross-Origin-Resource-Policy: cross-origin response header to flag responses that don't need protection from oracle attacks (the current use for this header) since they contain only public data.
The current PR for the Compression Dictionary Transport spec integration into fetch includes the change but it was not part of the original WPT's or implementations so I wanted to get buy-in on the change (and provide notice for the in-flight implementation work).
If we ever want to enable dictionary compression for some no-cors requests, now is the time to do it before there are widespread deployments.
The only risk is if there are resources that are used in both same-origin and cross-origin no-cors contexts and the origin currently supports compression dictionary transport but does not have the CORP response header on the responses, it will start to fail if they are not limiting dictionary support to same-origin responses (required by the RFC but unlikely someone would notice since they don't get the headers currently if it's not supported).
Going forward it wouldn't be a problem because the issue would be discovered at the time of deployment rather that with a browser change to existing production traffic.
There aren't any deployments that I'm aware of that have that problem but the risk of it happening increases over time with more dictionary deployments, limiting the chances of making the change in the future.
The alternative would be to not allow dictionary compression for any cross-origin no-cors requests independent of the content which would be cleaner for sites since they'd never get the dictionary request headers but it also limits the ability for third-party script embeds to use dictionary compression.