LGTM to experiment from 117 to 122 inclusive.
(Good luck, looks cool!)
On 7/25/23 9:52 PM, Tsuyoshi Horo wrote:
Contact emails
[email protected], [email protected],
[email protected], [email protected]
Explainer
https://github.com/WICG/compression-dictionary-transport
Specification
https://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 component
Blink>Network
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork>
TAG review
https://github.com/w3ctag/design-reviews/issues/877
TAG review status
Pending
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://flags
chrome://flags/#enable-compression-dictionary-transport-backend
chrome://flags/#enable-compression-dictionary-transport
Finch feature name
CompressionDictionaryTransportBackend
CompressionDictionaryTransport
Requires code in //chrome?
True
Tracking bug
https://crbug.com/1413922
Launch bug
https://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 discussions
Intent 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 [email protected].
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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-WyukWVPpFMFYSWVZ1%2BOuXVjtNfWiCqKvDYcdRwaApZLA%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 [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f161f75c-7786-f4a3-1bb2-b8813577451b%40chromium.org.
