Request for Mozilla Position on Compression dictionary transport

[pmeenan]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Compression Dictionary Transport
• Specification or proposal URL (if available): https://github.com/WICG/compression-dictionary-transport
• Explainer URL (if available): https://github.com/WICG/compression-dictionary-transport/blob/main/README.md

Other information

Chrome Status Page: https://chromestatus.com/feature/5124977788977152
Example compression gains over Brotli: https://github.com/WICG/compression-dictionary-transport/blob/main/examples.md

It's still very early in the standards process but it will likely span the IETF HTTP working group and WHATWG HTML and Fetch standards and we wanted to bring the relevant parties together sooner rather than later to hash out the designs.

Compression dictionary transport provides a mechanism for websites to use existing resources in their cache as compression dictionaries for future requests. The key points are:

• The compression is currently limited to Brotli but the dictionary negotiation is independent of compression protocol.
• The dictionaries must be same-origin as the resources they compress.
• The dictionaries and resources they are applied to are required to be cors-readable from the document (side-channel timing attacks make them effectively readable so the requirement makes it explicit).
• The dictionaries are existing resources in the partitioned caches and cleared when either caches or cookies are cleared.

The flow as it currently stands is (generally):

• Fetch response for a cacheable resource includes a use-as-dictionary: response header that specifies the path matching rules for fetches where the dictionary would be applied (either for different versions of the same js/css/wasm/etc resource or a path spec for html pages where a stand-alone dictionary would be applied).
• Future fetches that match the path of a dictionary in cache send a sec-available-dictionary: request header with the hash of the dictionary with the most specific match for the request. It also includes the dictionary compression algorithms it understands. i.e. Accept-Encoding: sbr,....
• If the server has the requested resource compressed against the dictionary the client advertised (or if it can generate it dynamically), it returns the dictionary-compressed response along with Content-Encoding: sbr and Vary: Accept-Encoding,Sec-Available-Dictionary

[zcorpan]

@valenting

[valenting]

This looks promising and is definitely worth prototyping.