Skip to content

SYSTEM Cited by 1 source

RFC 9842 — Compression Dictionary Transport

RFC 9842: Compression Dictionary Transport is the IETF standard that defines how an HTTP server and a browser negotiate a shared compression dictionary — specifically, how a previously-fetched response becomes the dictionary against which the next version is delta-compressed. It's the modern successor to Google's 2008-2017 SDCH effort, which was un-shipped from Chrome in 2017 after accumulating security + specification gaps.

Core mechanism

Two HTTP headers + two content encodings.

Response header on the first fetch

Use-As-Dictionary: match="/app.bundle.*.js", id="sha-256:abc..."

Tells the browser: "hold onto this response — it'll be useful as a dictionary when you fetch future URLs matching this pattern." The match= parameter specifies which URL classes the dictionary applies to; id= is the dictionary's content-addressed hash.

Request header on subsequent fetches

Available-Dictionary: sha-256:abc...

Browser tells the server: "here's the dictionary hash I've got cached." The server chooses whether to honour it.

Response encodings

  • Content-Encoding: dcb — delta-compressed [Brotli] (prefix dcb).
  • Content-Encoding: dcz — delta-compressed [Zstandard] (prefix dcz).

The response body is the diff between the new resource and the cached dictionary, compressed with Brotli or Zstandard using the dictionary as the reference. The browser reconstructs the full new response by decompressing the diff against its cached copy of the dictionary.

Why RFC 9842 succeeded where SDCH failed

SDCH accumulated a trio of fatal problems:

  1. Compression side-channel attacks (CRIME / BREACH) — attackers injected content alongside sensitive data (session cookies, CSRF tokens) that got compressed together, watched the compressed-output size shrink byte-by-byte as guesses matched the secret, and extracted bytes of the secret at a time.
  2. Cross-origin dictionary model — SDCH dictionaries could be served from any origin, which powered performance (you could serve one dictionary that worked across multiple domains) but couldn't be reconciled with CORS.
  3. Cache-API specification gaps — unspecified interactions between SDCH dictionaries and the Cache API made correct implementation ambiguous.

RFC 9842 closes each gap. Most load-bearingly: dictionaries are only usable for responses from the same origin that served them, which prevents most SDCH-era side-channel attacks (attackers can't inject content across origins to exploit a dictionary served on a different origin). The same-origin constraint also resolves the CORS incompatibility — there's nothing cross-origin to reconcile.

Implementation scope

  • Browsers: Chrome 130+, Edge 130+ ship support (advertise dcb/dcz in Accept-Encoding, send Available-Dictionary, decode dcb/dcz responses). Firefox tracking; Safari not yet committed.
  • Servers / CDNs: serve Use-As-Dictionary on responses that should become dictionaries; generate dcb/dcz responses for requests that advertise Available-Dictionary; manage cache variants on both Accept-Encoding and Available-Dictionary. systems/cloudflare-shared-dictionaries is the canonical CDN implementation, phasing from passthrough (2026-04-30 beta) to managed to automatic.
  • Customer origins: can implement directly (e.g. Patrick Meenan's dictionary-worker — RFC 9842 author's WASM-Zstandard reference implementation in a Cloudflare Worker) or rely on a CDN's managed implementation.

Relationship to traditional compression

  • gzip has no dictionary — finds patterns inside each response in real time.
  • Brotli ships with a built-in static dictionary of common web patterns (HTML attributes, common phrases) — useful for HTML/JS/CSS bytes that recur across the web, but the dictionary is fixed at the protocol level.
  • Zstandard is purpose-built for custom dictionaries: you can feed it representative content samples and it generates an optimised dictionary for the content type.
  • RFC 9842 takes the custom-dictionary idea further: the dictionary is the previously cached version of the same resource. No separate dictionary file; the mechanism bootstraps from ordinary HTTP caching.

See also

Seen in

Last updated · 200 distilled / 1,178 read