Summary

  • HTTP Vary identifies request header fields that might have influenced an origin's choice of representation; a cache must match those nominated fields before reusing the stored response without validation.
  • The field does not attest the deployed cache configuration, every application selection input, tenant or authorization separation, or the digest of the representation actually served.

A hypothetical platform serves tenant-specific configuration through one shared URI. Tenant A requests the resource, the origin returns A's branding, and the response says Vary: Accept-Encoding. An assurance dashboard sees a valid Vary field and marks cache isolation green. Tenant B later asks for the same URI with the same content-coding preference and receives A's bytes from the edge.

Nothing in that sequence makes Vary defective. The field described the dimension the origin declared for selecting that response. The defect lies in treating the declaration as evidence of a broader boundary it never claimed to certify.

What Vary actually says

RFC 9110 defines Vary as a response field describing which parts of the request, beyond the method and target URI, might have influenced the origin server's process for selecting the response content. When it contains field names, those names are the selecting header fields. The wording matters: this is an origin-side statement about possible selection inputs for one response.

The field has two protocol purposes. It warns caches not to reuse the response for a later request unless the nominated fields match, or reuse has been validated by the origin. It also tells a user agent that content negotiation occurred and that different values might produce another representation. Neither purpose turns the header into observations from the cache that later stores or serves the response.

The wildcard makes the boundary even clearer. Vary: * means aspects outside the named message fields might have influenced selection, possibly including the client's network address. A later recipient cannot decide suitability from the request fields alone and has to forward the request to the origin. A proxy is forbidden to generate that wildcard. The wildcard is a declaration of uncertainty, not a universal isolation switch.

The actual cache key is a separate fact

RFC 9111 calls the cache key the information a cache uses to choose a stored response. At minimum it is built from method and target URI, although common caches often store only GET responses and consequently appear to use the URI as the primary key. A cache can incorporate nominated request fields from Vary, and it can add other material of its own.

When a stored response carries Vary, a cache must not reuse it without validation unless all nominated request fields match their values in the request that created the stored response. The comparison can normalize whitespace or other details only where the field's semantics allow equivalence. If a nominated field was absent, it matches only a later request where that field is also absent. A stored response whose Vary value contains * always fails to match.

Those are strong matching rules. They still do not answer four operational questions. Did the deployed cache parse and enforce the field? Did an intermediary rewrite or strip it? Did the application select on an input it failed to nominate, such as a tenant context resolved after authentication? Did the delivered representation correspond to the stored variant the cache thought it selected? The response field is evidence relevant to those questions, but it is not their answer.

Isolation can depend on dimensions HTTP does not name for you

Applications commonly derive representation choices from facts that are not safely captured by copying one convenient header into a key: an authenticated account, a tenant mapping, a feature cohort, a policy epoch, a jurisdictional rule, or an edge configuration version. Some of those facts may be represented by request fields; others emerge from server-side state. RFC 9110 allows Vary: * when aspects outside message syntax affected selection, but that deliberately prevents ordinary reuse rather than documenting a reusable private partition.

An operator therefore cannot infer tenant isolation from the mere presence of Vary, nor from a list that names only language and encoding. A syntactically correct field may be incomplete for the application's real selection logic. Conversely, a cache might add privacy-oriented partitioning beyond Vary. The visible response does not reveal either outcome.

The distinction is also separate from freshness. A variant can be fresh and still be the wrong variant because the key omitted a selection dimension. It can be stale yet correctly partitioned. Revalidation can confirm that a stored representation remains usable under HTTP validators without proving that the request was placed in the right tenant partition. Freshness, validation, authorization and variant selection are related controls, not synonyms.

Evidence for a defensible claim

To claim that a deployment kept representations isolated, join the protocol declaration to what the cache actually did. Record the cache instance or cohort and configuration version; the request method and target URI; the exact Vary value as received by that cache; the normalized values and absence state for every nominated field; every application dimension that selected content; the tenant and authorization context at decision time; the hit, miss or revalidation decision; the stored-representation identifier; and a digest of the bytes served.

That proposed variant-selection receipt is an editorial evidence synthesis, not an IETF-defined protocol element. Its purpose is to prevent a narrow standards signal from being promoted into a wider operational assurance claim. It should also preserve where the observation was made, because an origin response, a shield cache and a delivery edge can see different fields and apply different configuration.

Vary remains useful precisely when its boundary is respected. It makes declared content negotiation visible and gives compliant caches concrete matching obligations. The assurance error begins when a team treats that declaration as proof of implementation, isolation or outcome. A header can state the intended selection dimensions. Only joined configuration and delivery evidence can show that the right representation stayed on the right side of the boundary.

Sources