Congratulations on getting compression dictionaries through the standards gauntlet!
On Tue, Aug 27, 2024 at 2:36 AM Tsuyoshi Horo <h...@chromium.org> wrote: > Contact emailsh...@chromium.org, pmee...@chromium.org, > nidhij...@chromium.org, yoavwe...@chromium.org, kenjibah...@chromium.org > > Explainerhttps://github.com/WICG/compression-dictionary-transport > The explainer still has "All actual header values and names still TBD". I assume that's not the case anymore? > Specification > https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary > Is there a specification for the browser side of this? I'd expect to find something in Fetch that describes, for example, the CORS, same-origin, and partitioning behavior. > Design docs > > 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 > > https://docs.google.com/document/d/1WCK965Ew0hTN6k05o2JFi9Y-AdGfkB1io_i6LrTSeQs/edit?usp=sharing > > Summary > > This feature adds support for using designated previous responses, as an > external dictionary for Brotli- or Zstandard-compressing HTTP responses. > Enterprises might experience potential compatibility issues with enterprise > network infrastructure. The CompressionDictionaryTransportEnabled policy is > available to turn off the compression dictionary transport feature. > > > Blink componentBlink>Network > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork> > > TAG reviewhttps://github.com/w3ctag/design-reviews/issues/877 > > TAG review statusIssues addressed > > Chromium Trial NameCompressionDictionaryTransportV3 > Origin Trial documentation link > https://chromium.googlesource.com/chromium/src/+/main/docs/experiments/compression-dictionary-transport.md > WebFeature UseCounter nameSharedDictionaryUsed > > Chromium Trial NameCompressionDictionaryTransport > > Link to origin trial feedback summary > https://github.com/httpwg/http-extensions/issues?q=is%3Aissue+label%3Acompression-dictionary > > Risks > > > Interoperability and Compatibility > > 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('dictionary')`. > https://www.ietf.org/archive/id/draft-ietf-httpbis-compression-dictionary-17.html#name-the-compression-dictionary- says the link relation is "compression-dictionary" instead of "dictionary". Which is being shipped? > Also web servers can know the browser support by checking the > `Accept-Encoding` request header and the new `Use-As-Dictionary` request > header. 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. > > > *Gecko*: Positive ( > https://github.com/mozilla/standards-positions/issues/771) > > *WebKit*: Support ( > https://github.com/WebKit/standards-positions/issues/160) > > *Web developers*: Positive based on origin trial feedback > > *Other signals*: > > Ergonomics > > 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. > > > Activation > > To adopt this feature, web developers need to make changes in their web > servers. Currently there is no major server softwares which supports > compression dictionaries. Some CDNs have shared interest in supporting > shared dictionary compression (e.g. publicly mentioned [*] in a blog post > by Cloudflare). [*] > https://blog.cloudflare.com/this-is-brotli-from-origin/#:~:text=One%20development%20that%20we%27re%20particularly%20focused%20on%20is%20shared%20dictionaries%20with%20Brotli > . > > > Security > > 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 stealing information. 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. > > > WebView application risks > > None > > > Debuggability > > 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, > Sec-Available-Dictionary, Accept-Encoding, Content-Encoding) using > DevTools' Network panel. > > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?Yes > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ?Yes > > https://wpt.fyi/results/fetch/compression-dictionary > > > Flag name on > chrome://flagschrome://flags/#enable-compression-dictionary-transport-backend > chrome://flags/#enable-compression-dictionary-transport > > Finch feature nameCompressionDictionaryTransportBackend > CompressionDictionaryTransport > > Requires code in //chrome?True > > Tracking bughttps://crbug.com/1413922 > > Launch bughttps://launch.corp.google.com/launch/4266286 > > Sample links > https://compression-dictionary-transport-threejs-demo.glitch.me > https://compression-dictionary-transport-shop-demo.glitch.me > > Estimated milestones > Shipping on desktop 130 > Origin trial desktop first 123 > Origin trial desktop last 125 > Origin trial desktop first 117 > Origin trial desktop last 122 > Origin trial desktop first 127 > Origin trial desktop last 129 > Shipping on Android 130 > Origin trial Android first 123 > Origin trial Android last 125 > Origin trial Android first 117 > Origin trial Android last 122 > Origin trial Android first 127 > Origin trial Android last 129 > Shipping on WebView 130 > Origin trial WebView first 123 > Origin trial WebView last 125 > Origin trial WebView first 127 > Origin trial WebView last 129 > > Anticipated spec changes > > None. The draft has been reviewed by the IETF http working group and > steering committee and approved for publication as a RFC. There are a few > mechanical process issues that need to happen for publication but the spec > itself will not be changing. > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/5124977788977152?gate=5186705503551488 > > Links to previous Intent discussionsIntent to Prototype: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-Vb1ON2XT2%2BBP27tJ4ivjgyu63jcd667am4TwcVFGsbuw%40mail.gmail.com > Intent to Experiment: > https://groups.google.com/a/chromium.org/g/blink-dev/c/7YdP2YxRQn4/m/9oPxLDdjAAAJ > Intent to Experiment: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-WyukWVPpFMFYSWVZ1%2BOuXVjtNfWiCqKvDYcdRwaApZLA%40mail.gmail.com > Intent to Experiment: > https://groups.google.com/a/chromium.org/g/blink-dev/c/9iMl0kAA2LE > > > This intent message was generated by Chrome Platform Status > <https://chromestatus.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+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-X5SPHneF3WuaDYQREdDs_vAyE3JxeRA6s5RMXXL6rVBw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-X5SPHneF3WuaDYQREdDs_vAyE3JxeRA6s5RMXXL6rVBw%40mail.gmail.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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dXkksqJzhvnHV6DdpU3GUwqbXQ%2BQ639PTJ5BhxNJ2x__oA%40mail.gmail.com.
