To use a resource as a dictionary, the server should include the Use-As-Dictionary header in the response that provides the resource: Use-As-Dictionary: match="/js/app.*.js" The value of this header indicates the resources that can use this resource as a dictionary: in this case, that includes any resources whose URLs match the given pattern. When a resource is later requested that matches the given pattern (for example, app.v2.js), the request will include a SHA-256 hash of the available dictionary in the Available-Dictionary header, along with dcb and/or dcz values in the Accept-Encoding header (for delta compression using Brotli or ZStandard as appropriate): Accept-Encoding: gzip, br, zstd, dcb, dcz Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=: The server can then respond with an appropriately-encoded response with the chosen content encoding given in the Content-Encoding header: If the response is cacheable, it must include a Vary header to prevent caches serving dictionary-compressed resources to clients that don't support them or serving the response compressed with the wrong dictionary: Vary: accept-encoding, available-dictionary An optional id can also be provided in the Use-As-Dictionary header, to allow the server to more easily find the dictionary file if they do not store the diction by the hash: Use-As-Dictionary: match="/js/app.*.js", id="dictionary-12345" If this is provided, the value will be sent in future requests in the Dictionary-ID header: Accept-Encoding: gzip, br, zstd, dcb, dcz Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=: Dictionary-ID: "dictionary-12345" The server must still check the hash from the Available-Dictionary header — the Dictionary-ID is additional information for the server to identify the dictionary but does not replace the need for the Available-Dictionary header.
First seen: 2025-07-04 16:12
Last seen: 2025-07-05 02:14