Contact emails
ho...@chromium.org, pme...@chromium.org, yoav...@chromium.org, kenji...@chromium.org, deno...@chromium.org
https://github.com/WICG/compression-dictionary-transport
https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/
https://docs.google.com/document/d/1IcRHLv-e9boECgPA5J4t8NDv9FPHDGgn0C12kfBgANg/edit
https://github.com/WICG/compression-dictionary-transport
https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/
Summary
We are running the second round of the Origin Trial until Chrome 125. The design of the feature has also evolved during the origin trial and RFC process. We’d like to run a third round of the Origin Trial to get more feedback on the updated design.
https://github.com/w3ctag/design-reviews/issues/877
Closed
Interoperability and Compatibility risk are low. This feature introduces a new compression method for transporting resources over HTTP. Web sites can know the browser support for the new feature by checking `document.createElement('link').relList.supports('compression-dictionary')`. The feature is a negotiation between servers and clients that involves a server specifying that a resource should be used as a dictionary for future requests with a ‘Use-As-Dictionary’ response header. Clients that don’t support the feature will ignore the header and nothing further will happen.
This feature is an opt-in feature. And the dictionary storage is isolated using the top level site and the frame origin as the key. That means, if there is no dictionary registered for the site, the behavior of Chrome will not change while browsing the site. Also this feature is only usable within a secure-context so this feature will not increase the risk of having network proxies meddle with the content’s encoding. For enterprises that have deployed HTTPS-intercepting proxies that do not properly handle unknown encodings there is an enterprise policy exposed to disable the feature. The feature is currently enabled only over connections using a well-known trust root for the secure connection which eliminates the risk of security devices and proxies breaking traffic. The roll-out plan for production has steps to remove the trust root restriction and enable support in enterprise environments where intercepting proxies are common.
Gecko: Positive (https://github.com/mozilla/standards-positions/issues/771)
WebKit: Positive (https://github.com/WebKit/standards-positions/issues/160)
Web developers: Positive
Other signals:
To reduce memory usage in network services, dictionary metadata is stored in a database on disk. And to avoid performance degradation for normal requests that do not use a dictionary, the reading of this metadata is designed not to block network requests. In other words, if the reading of metadata from the database is not completed before the request header is ready to be sent to the server, the dictionary may not be used even if it is already registered in the database.
To adopt this feature, web developers need to make changes in their web servers or build processes for static resources. Currently there is no major server software which directly supports compression dictionaries. Some CDNs have shared interest in supporting shared dictionary compression (e.g. publicly mentioned in a blog post by Cloudflare).
Chrome registers the response as a dictionary only when the response is CORS-readable from the document origin. Also we use a registered dictionary to decompress the response only when the response is CORS-readable from the document origin. Additionally, the dictionary and the compressed resource are required to be from the same origin as each other. So this should not introduce any new attack vector of information leaks.
The dictionaries are partitioned with the storage cache and are cleared whenever cookies or cache is cleared to ensure that the dictionaries can not be abused as a tracking vector.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No
Goals for experimentation
We would like to collect feedback on the updated API design of Compression Dictionary Transport feature. Also, we would like to continue some experiments using this feature to measure its performance impact.
The difference from the previous Origin Trial:
- Renamed the link rel attribute for fetching the dictionary from "dictionary" to "compression-dictionary".
- Using "dcb" and "dcz" content encoding in place of "br-d" and "zstd-d". The new encodings incorporate the dictionary hash.
- Removed the dictionary hash check logic using the "Content-Dictionary" response header, and instead checking the hash within the encoded response body.
None
We have introduced chrome://net-internals/#sharedDictionary. Using it, web developers can manage the registered dictionaries. Also web developers can check the related HTTP request and response headers (Use-As-Dictionary, Available-Dictionary, Accept-Encoding, Content-Encoding).
Any errors in processing responses as a result of dictionary compression issues are reported as issues in Dev Tools. This includes things like dictionary hash mismatches and cors-readability failures.
Yes
Yes. https://wpt.fyi/results/fetch/compression-dictionary
chrome://flags/#enable-compression-dictionary-transport-backend chrome://flags/#enable-compression-dictionary-transport
CompressionDictionaryTransportBackend CompressionDictionaryTransport
True
https://launch.corp.google.com/launch/4266286
https://chromestatus.com/feature/5124977788977152
Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/-qYpLo9DTjw/m/JX6kbUOtBQAJ
Intent to experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/NgH-BeYO72E/m/oup5DpbxAAAJ
Intent to extend Origin Trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/7YdP2YxRQn4/m/9oPxLDdjAAAJ
Hi there,
Would you mind commenting on progress for the following items, per OT renewal guidelines:
Draft spec (early draft is ok, but must be spec-like and
associated with the appropriate standardization venue, or WICG)
TAG review (see exceptions)
bit.ly/blink-signals requests
Outreach for feedback from the spec community
WPT tests
thanks,
Mike
--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-UpM8k_NGuqbuA%2BNuC%2BTdGDjGzUt0Fp05Y8pHROjH-WZA%40mail.gmail.com.
Hi there,
Would you mind commenting on progress for the following items, per OT renewal guidelines:
Draft spec (early draft is ok, but must be spec-like and associated with the appropriate standardization venue, or WICG)
TAG review (see exceptions)
bit.ly/blink-signals requests
Outreach for feedback from the spec community
WPT tests
Thanks all. LGTM to extend from 127 to 129 inclusive.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f9f7a485-94d3-45cf-a0b1-3021c6d7526a%40chromium.org.
Thanks Domenic - I agree.
Tsuyoshi,Previously your third OT stage on ChromeStatus got associated with your second trial on OT Console. That is probably due to a bug in ChromeStatus. We'll look into that.To let you continue with requesting this new trial, I have cleared out the trial ID for that third OT stage on ChromeStatus. Now you should see a "Request Trial Creation" button on that stage that looks like: