Contact emailsh...@chromium.org, pmee...@chromium.org, yoavwe...@chromium.org, kenjibah...@chromium.org
Explainerhttps://github.com/WICG/compression-dictionary-transport Specificationhttps://github.com/WICG/compression-dictionary-transport Design docs https://docs.google.com/document/d/1IcRHLv-e9boECgPA5J4t8NDv9FPHDGgn0C12kfBgANg/edit https://github.com/WICG/compression-dictionary-transport https://datatracker.ietf.org/doc/draft-meenan-httpbis-compression-dictionary Summary This feature adds support for using designated previous responses, as an external dictionary for Brotli-compressing HTTP responses. 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 statusPending 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')`. 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 usable only on secure-context. So this feature will not increase the risk of non-supporting network proxies misunderstanding the content’s encoding. *Gecko*: Positive (https://github.com/mozilla/standards-positions/issues/771 ) *WebKit*: No signal ( https://github.com/WebKit/standards-positions/issues/160) *Web developers*: No signals *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. 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 Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? Goals for experimentation We would like to collect feedback on the Compression Dictionary Transport feature of API design. We would also like to run some experiments using this feature to measure its performance impact. Ongoing technical constraints 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 tab. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, 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> ?No. We will rewrite some browser_tests to WPT. 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 Estimated milestones OriginTrial desktop last 122 OriginTrial desktop first 117 OriginTrial Android last 122 OriginTrial Android first 117 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5124977788977152 Links to previous Intent discussionsIntent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-Vb1ON2XT2%2BBP27tJ4ivjgyu63jcd667am4TwcVFGsbuw%40mail.gmail.com 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-WyukWVPpFMFYSWVZ1%2BOuXVjtNfWiCqKvDYcdRwaApZLA%40mail.gmail.com.
