Introduction

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.

This proposal adds support for using designated previous responses, as an external dictionary for Brotli-compressing HTTP responses.

HTTP Content-Encoding is extended with a new encoding type and support for allowing responses to be used as dictionaries for future requests. All actual header values and names still TBD:

• Server responds to a request for a cacheable resource with an bikeshed-use-as-dictionary: <scope/path>.
• The client will store a SHA-256 hash of the uncompressed response and the applicable scope for the resource with the cached response to identify it as a dictionary.
• On future requests, the client will match a request against an available dictionary with the best-matching scope. If a dictionary is available for a given request, the client will add sbr to the Accept-Encoding request header as well as a sec-bikeshed-available-dictionary: <SHA-256> header with the hash of the best available dictionary.
• If the server has a compressed version of the request URL with the matching dictionary, it serves the dictonary-compressed response with Content-Encoding: sbr and Vary: Accept-Encoding,sec-bikeshed-available-dictionary.

Read the complete Explainer.

Feedback

I welcome feedback in this thread, but encourage you to file bugs against the Explainer.