Summary

  • RFC 9842 permits an HTTP response to become a compression dictionary for later responses, subject to origin, URL-pattern, destination, freshness and client-choice rules.
  • The dictionary hash, Available-Dictionary signal, content-coding negotiation, cache variant, decode result and response meaning remain separate records. None alone establishes an accepted response or a business outcome.

It is tempting to describe HTTP compression dictionaries as a simple acceleration feature: a browser has an earlier byte sequence, a server sends a smaller later response, and the client gets the same content more cheaply. The mechanism is real, and the potential saving is real. The temptation becomes dangerous when that compact story erases the separate decisions that make the exchange valid.

RFC 9842 begins with a deliberately limited move. A server may attach Use-As-Dictionary to an HTTP response, saying that this response can be considered as an external compression dictionary for later requests that meet specified rules. The required match value is a same-origin URL Pattern. An optional match-dest can restrict the kind of Fetch destination. An optional identifier is opaque to the client; the RFC explicitly says a server must not use it as a guarantee of dictionary contents. The designation is neither a general permission slip nor an assertion that every later URL will use this resource.

A client next performs its own matching work. It asks whether the candidate dictionary is fresh, or is allowed to be served stale; whether the outbound request has the same origin; whether its destination fits; and whether the URL matches the stored pattern. Where more than one dictionary matches, RFC 9842 specifies a preference order rather than a declaration that every candidate is interchangeable. This is a useful control surface because it turns vague cache possession into a testable sequence.

It does not turn the outcome of that sequence into proof that an HTTP representation is semantically current, suitable for an operation, or seen by a user.

When the client has one appropriate dictionary and chooses to make dictionary coding available, it can send one Available-Dictionary value containing the SHA-256 hash of that dictionary. It may also offer dcb or dcz in Accept-Encoding. These facts are often compressed into the phrase “the client has the response.” They are not the same thing. The client has a locally retained byte sequence identified by a hash. It has offered a capability for a specific request. It has not chosen the server’s representation, inspected its meaning, or decided what a later application should do.

The server retains a distinct choice. It can select a normal representation. It can select a different non-dictionary content coding. If it supports one of the dictionary codings advertised by the client and chooses to use the indicated dictionary, it can return Content-Encoding dcb or dcz. The binary representation carries the dictionary hash so both sides can align the external dictionary with the compressed stream. Alignment is important, but it is not authority.

A matching hash says which bytes are to be used for decompression; it does not certify that the response expresses a current entitlement, a price, a configuration, a security decision or an action result.

Caching adds another boundary instead of removing one. For a cacheable dictionary-compressed response, RFC 9842 requires Vary on Accept-Encoding and Available-Dictionary. That protects clients from receiving a representation compressed with an unsupported encoding or the wrong dictionary. It does not prove that the cache key captures every fact an application needs to make a later decision. HTTP cache correctness and business-state correctness are different questions. A correctly varied object can still be stale under the application’s own rules, irrelevant to a changed authorization state, or unsuitable evidence for a costly operational act.

The security section is equally resistant to shortcuts. Compression Dictionary Transport is confined to secure contexts. The dictionary/request match is same-origin. A client must drop the response if the required mitigations fail. These are meaningful protections, but they do not confer broad authority. RFC 9842 warns that a dictionary can change decompressed content and that mixing public and private inputs into compression can leak information through size or timing. It also treats dictionary hashes as tracking-sensitive state that clients should partition and clear like cookies.

HTTPS, a hash, a same-origin rule and a safe decoding path are not a substitute for a separate authorization, confidentiality classification or outcome record.

The compression-dictionary link relation shows the same discipline. It can indicate that fetching a related resource is likely to help later compression. The client decides when, if ever, to fetch it. The fetched response must still carry Use-As-Dictionary and cache metadata before it is usable. A link is an invitation to obtain a possible input, not a declaration that the input arrived, matched, was used or changed the later response.

For Leadership Alliance readers, the practical record is a chain rather than a slogan: dictionary URL and bytes; hash; origin and pattern evaluation; freshness; request destination; one client advertisement; accepted content coding; cache variant; decode result; response semantics; and the independently accountable decision or effect. The chain gives engineers room to optimise. It also gives leadership a way to stop a compression artifact from silently becoming evidence of a result it cannot establish.

Heng Lu’s distinction is especially helpful here. A portable protocol mechanism can make coordination cheaper while leaving choice local. RFC 9842 supplies the mechanism. The client and server still choose whether to participate. A cache still has a bounded representation rule. The receiving application still has to evaluate meaning, rights, risk and action. Treating the dictionary as the response would erase the very boundaries that make the optimisation safe to operate.

Sources