-
-
Notifications
You must be signed in to change notification settings - Fork 637
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Shared Brotli
and Shared Zstandard
(zstd)
#353
Comments
Thanks for this sharing @summercms. |
See slide 4 found here: https://datatracker.ietf.org/meeting/117/materials/slides-117-httpbis-compression-dictionaries-00 Here's what I understand: Use-As-Dictionary: match="/path/to/target/*" When the client Accept-Encoding: sbr
Sec-Available-Dictionary: <SHA-256 of Dictionary> The server can use the dictionary specified by the client to compress and return the content. If compression is performed using a dictionary, the response will be as follows. Since the encoding result of the same content changes depending on the dictionary, add the hash of the dictionary to the key of Content-Encoding: sbr
Vary: Accept-Encoding, Sec-Available-Dictionary Since it is a method that generates a dictionary in advance, it can be said to be a method that is compatible with static site generators. Was thinking could update this code section, with notes at a later date: Disclaimer: This spec is likely to change still, so expecting this to be put on hold for the next major semantic version of this repo. |
This feature adds support for using designated previous responses, as an external dictionary for Brotli(or Zstandard)-compressing HTTP responses.
If the browser and server share a dictionary, using the dictionary for compression can significantly reduce the amount of data transferred. This is especially useful for incremental library updates, or when browsing multiple pages that have a lot of common parts in their files.
Compression Ratio Comparison Tests
Browser Support
Shared Zstandard
support is available on Google Chrome 118 onwards.Chrome 118
Chrome 117
The following flags were enabled on Chrome Canary 117.0.5912.0 and the behaviour was verified.
Demos and samples
https://compression-dictionary-transport-threejs-demo.glitch.me/
https://compression-dictionary-transport-shop-demo.glitch.me/
Info
https://github.com/WICG/compression-dictionary-transport
https://datatracker.ietf.org/doc/draft-meenan-httpbis-compression-dictionary
https://docs.google.com/document/d/1IcRHLv-e9boECgPA5J4t8NDv9FPHDGgn0C12kfBgANg/edit#heading=h.7nki9mck5t64
https://github.com/facebook/zstd
https://en.wikipedia.org/wiki/Zstd
Examples
Bundled JavaScript on separate origin
In this example, www.example.com will use a bundle of application JavaScript that they serve from a separate static domain (static.example.com). The JavaScript files are versioned and have a long cache time, with the URL changing when a new version of the code is shipped.
On the initial visit to the site:
<script src="//static.example.com/app/main.js/123" crossorigin>
(where 123 is the build number of the code).Accept-Encoding: sbr,br,gzip
.use-as-dictionary: match="/app/main.js*"
,Access-Control-Allow-Origin: https://www.example.com
andVary: Accept-Encoding,sec-available-dictionary
.https://www.example.com/app/main.js*
URL pattern.At build time, the site developer creates delta-compressed versions of main.js using previous builds as dictionaries, storing the delta-compressed version along with the SHA-256 hash of the dictionary used (e.g. as
main.js.<hash>.sbr
).On a future visit to the site after the application code has changed:
<script src="//static.example.com/app/main.js/125" crossorigin>
.https://www.example.com/app/main.js/125
request with thehttps://www.example.com/app/main.js*
URL pattern of the previous dictionary response that is in cache and requests https://static.example.com/app/main.js/125 withAccept-Encoding: sbr,br,gzip
,sec-fetch-mode: cors
andsec-available-dictionary: <SHA-256 HASH>
.Content-Encoding: sbr
,Access-Control-Allow-Origin: https://www.example.com
,Vary: Accept-Encoding,sec-available-dictionary
.It could have also included a new
use-as-dictionary: match="/app/main.js*"
response header to have the new version of the file replace the old one as the dictionary to use for future requests for the path but that is not a requirement for the existing dictionary to have been used.Site-specific dictionary used for all document navigations in a part of the site
In this example, www.example.com has a custom-built dictionary that should be used for all navigation requests to /product.
On the initial visit to the site:
<link rel=dictionary href="/dictionaries/product_v1.dat">
.use-as-dictionary: match="/product/*"
and appropriate caching headers.https://www.example.com/product/*
URL pattern.At some point after the dictionary has been fetched, the user clicks on a link to https://www.example.com/product/myproduct:
/product/myproduct
request with thehttps://www.example.com/product/*
URL pattern of the previous dictionary request and requests https://www.example.com/product/myproduct withAccept-Encoding: sbr,br,gzip
andsec-available-dictionary: <SHA-256 HASH>
.Content-Encoding: sbr
(and Vary headers if the response is cacheable).The text was updated successfully, but these errors were encountered: