Thanks all. LGTM to extend from 127 to 129 inclusive.
On 5/29/24 10:51 AM, Patrick Meenan wrote:
On the spec side of things, there is one more issue outstanding in the
IETF discussion but it's not API-impacting and we expect that this
latest draft
<https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/04/>,
which this OT implements, has the final API shape. There will be some
tweaks around the edges as we go through the final steps of the RFC
process but the V3 OT will give sites something to test against that
matches what we expect to ship.
There are some fairly substantial changes from the previous OT that it
would be useful to get feedback on. In particular, the change to the
file format that embeds the dictionary hash into the file itself
instead of being a separate response header.
On Wed, May 29, 2024 at 10:37 AM Yoav Weiss (@Shopify)
<yoavwe...@chromium.org> wrote:
On Wed, May 29, 2024 at 4:31 PM Mike Taylor
<miketa...@chromium.org> wrote:
Hi there,
Would you mind commenting on progress for the following items,
per OT renewal guidelines:
<API owner hat off / feature champion hat on>
Draft spec (early draft is ok, but must be spec-like and
associated with the appropriate standardization venue, or WICG)
Recently published
<https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/>
with
above-mentioned changes.
+Patrick Meenan <mailto:pmee...@google.com> can probably add
precision there, but it's making good progress in the HTTPWG.
TAG review (see exceptions)
https://github.com/w3ctag/design-reviews/issues/877
bit.ly/blink-signals <http://bit.ly/blink-signals> requests
Both Mozilla
<https://github.com/mozilla/standards-positions/issues/771> and
WebKit <https://github.com/WebKit/standards-positions/issues/160>
are positive (with ongoing discussion about some details with
Mozilla folks).
Outreach for feedback from the spec community
Regular HTTPWG and WebPerfWG engagement.
WPT tests
https://wpt.fyi/results/fetch/compression-dictionary?label=experimental&label=master&aligned
<https://wpt.fyi/results/fetch/compression-dictionary?label=experimental&label=master&aligned>
thanks,
Mike
On 5/28/24 5:59 AM, Tsuyoshi Horo wrote:
Contact emails
h...@chromium.org, pmee...@chromium.org,
yoavwe...@chromium.org, kenjibah...@chromium.org,
denom...@chromium.org
*
*
Explainer
https://github.com/WICG/compression-dictionary-transport
<https://github.com/WICG/compression-dictionary-transport>
*
*
Specification
https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/
<https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/>
*
*
Design docs
https://docs.google.com/document/d/1IcRHLv-e9boECgPA5J4t8NDv9FPHDGgn0C12kfBgANg/edit
<https://docs.google.com/document/d/1IcRHLv-e9boECgPA5J4t8NDv9FPHDGgn0C12kfBgANg/edit>
https://github.com/WICG/compression-dictionary-transport
<https://github.com/WICG/compression-dictionary-transport>
https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/
<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
<https://chromium.googlesource.com/chromium/src/+/d934bf37456735d9bc03107c577804f439f8a986/docs/experiments/compression-dictionary-transport.md#changes-in-m127>design.
*
*
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
<https://github.com/w3ctag/design-reviews/issues/877>
TAG review status
Closed
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('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
<https://github.com/mozilla/standards-positions/issues/771>)
*
*
WebKit: Positive
(https://github.com/WebKit/standards-positions/issues/160
<https://github.com/WebKit/standards-positions/issues/160>)
*
*
Web developers: Positive
*
*
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 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
<https://blog.cloudflare.com/this-is-brotli-from-origin/#:~:text=One%20development%20that%20we%27re%20particularly%20focused%20on%20is%20shared%20dictionaries%20with%20Brotli.>in
a blog post by Cloudflare).
*
*
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 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.
*
*
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?
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.
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,
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.
*
*
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>?
Yes. https://wpt.fyi/results/fetch/compression-dictionary
<https://wpt.fyi/results/fetch/compression-dictionary>
*
*
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 <https://crbug.com/1413922>
*
*
Launch bug
https://launch.corp.google.com/launch/4266286
<https://launch.corp.google.com/launch/4266286>
*
*
Estimated milestones
OriginTrial desktop last
129
OriginTrial desktop first
127
*
*
OriginTrial Android last
129
OriginTrial Android first
127
*
*
*
*
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5124977788977152
<https://chromestatus.com/feature/5124977788977152>
*
*
Links to previous Intent discussions
Intent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/-qYpLo9DTjw/m/JX6kbUOtBQAJ
<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
<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
<https://groups.google.com/a/chromium.org/g/blink-dev/c/7YdP2YxRQn4/m/9oPxLDdjAAAJ>
--
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-UpM8k_NGuqbuA%2BNuC%2BTdGDjGzUt0Fp05Y8pHROjH-WZA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-UpM8k_NGuqbuA%2BNuC%2BTdGDjGzUt0Fp05Y8pHROjH-WZA%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/f9f7a485-94d3-45cf-a0b1-3021c6d7526a%40chromium.org.
