Summary

  • RFC 9211 defines Cache-Status as an ordered Structured Fields list in which every member represents one cache. The origin-side member comes first and the user-side member last; the list is not a consensus decision.
  • Parameters have local, bounded meanings. A hit can be stale, a negative ttl can be valid, and stored or collapsed means nothing without fwd. Identifiers and detail values are supplied by the reporting cache, not independently certified identities.
  • Useful governance preserves the chain, records the observer and time, and releases only the detail appropriate to the audience. It does not turn optional diagnostics into a universal audit trail or a central permission service.

Three caches, three statements

Imagine a response travelling from an origin through a regional cache, an enterprise gateway and a browser cache. If all three elect to report, Cache-Status contains three members. RFC 9211 fixes their order: the cache nearest the origin is listed first, and the one nearest the user is last. The sequence therefore describes a path of local observations.

That is already more precise than the familiar dashboard tile labelled “cache hit.” The regional cache might have forwarded because its stored response required validation. The enterprise gateway might then have stored the returned response. The browser might have answered a later request locally. Each action belongs to a different decision-maker, at a different point, under a different policy.

The field does not ask those caches to vote. Nor does it compute an authoritative result over them. It gives each participating cache a place to describe its own role. RFC 9211 also tells a cache adding a member to preserve the members already present, so an operator can inspect the chain rather than only the final hop.

Preservation does not create completeness. A cache chooses whether to emit Cache-Status on all responses, only when configured, or in response to a debugging request. Parameters are optional. An intermediary can alter an HTTP field. A chain with two members therefore proves that two statements arrived at the observation point; it does not prove that exactly two caches handled the request.

The identifier identifies the speaker; it does not authenticate one

Every member begins with an identifier. RFC 9211 permits a product or service name, a hostname, an IP address or a generated string, encoded as a Structured Fields String or Token. This flexibility helps deployments avoid exposing more topology than they need.

It also sets a clear evidentiary limit. The identifier is chosen by the cache that inserts the member. It is not a certificate, an attestation or proof that the named component actually controlled the response. A collector may have strong contextual reasons to trust a member from a managed edge, but that confidence comes from the transport path, deployment controls, collection point or a separately configured integrity mechanism—not from the identifier syntax itself.

RFC 9421 defines HTTP Message Signatures that can cover selected message components. That can support a distinct integrity policy when parties deploy it correctly. It does not retroactively make ordinary Cache-Status members signed, and a signature over a final field still needs an explicit trust model for keys, intermediaries and transformations.

A sound record therefore keeps four things apart: the identifier written into the member; the network or application vantage point where the field was observed; the evidence that binds the message to an expected sender; and the confidence assigned by the analyst. Combining those into a Boolean called trusted erases the reason for trust.

A hit is not a freshness certificate

The hit parameter is deliberately narrow. When hit is true, that cache did not forward the request and obtained the response from its cache. That does not mean the response was fresh. A cache can serve a stale response without forwarding when applicable rules permit it, and RFC 9211 still allows that handling to be described as a hit.

The inverse shortcut is equally unreliable. If a stored response required the cache to forward the request—for example, to validate it—the handling is not reported as a hit. The cache had an object, but it did not answer without forwarding. The hit and fwd parameters are mutually exclusive because they describe those two branches.

For governance, this means a service objective cannot be derived from the word hit alone. An operator who cares about origin avoidance can count non-forwarded handling, while an operator who cares about freshness must inspect freshness and validation evidence. A security team asking whether a personalized response was reusable needs the cache key, response controls and request context. One token cannot answer three different questions.

Forwarding parameters form a small grammar

When a cache forwards, fwd records the most specific reason it knows. RFC 9211 defines tokens for situations such as bypass, method restrictions, URI mismatch, misses, staleness and validation. The point is not to force every implementation to expose an identical internal state machine. It is to provide interoperable categories for a common diagnostic question.

Several parameters are scoped to that forwarding branch. fwd-status is meaningful only with fwd; if it is absent, the status sent to the client is the implied value. stored reports whether the forwarded response was stored. collapsed reports whether this request successfully reused an already outstanding forwarded request or caused a new request to be made. Reading stored or collapsed after a hit member invents semantics the specification does not provide.

This is where many data pipelines damage the evidence. A flat table gives every possible parameter its own column, fills missing values with false, and then aggregates across members. Missing is not always false. It can mean not applicable, not emitted or not observed. The correct internal model retains the member, its parameter set and the conditions that make each parameter meaningful.

A practical parser should reject the temptation to manufacture defaults beyond those defined by the RFC. A practical analyst should preserve the raw ordered field beside any normalized representation. That allows a future interpretation to be checked against the original statement.

ttl belongs to one cache and one moment

The ttl parameter reports the remaining freshness lifetime as calculated by the reporting cache near the time it adds the field. A negative value can represent a stale response. The calculation can incorporate HTTP age rules, heuristics and local configuration.

Consequently, two ttl values in one chain are not readings from a single clock. They can refer to different stored responses, policies and calculation moments. Subtracting one from another to estimate transit latency is not justified. Selecting the lowest value and calling it “the response TTL” is not justified either.

The useful questions are smaller. Did a particular cache report a negative value when it served without forwarding? Did one deployment begin applying a different freshness heuristic after a configuration change? Does a cache repeatedly forward for validation even though its own ttl remains positive? Those questions preserve provenance and can be tested against the cache's own policy.

Time also matters when storing the observation. A diagnostic capture should record when and where it was obtained. Cache-Status describes handling of one response, not a durable property of a URL. A later request may traverse another path or produce a different member list without either record being wrong.

key and detail are powerful precisely because they are local

The key parameter can expose an implementation-specific representation of the cache key. The detail parameter can carry implementation-specific information as a String or Token. RFC 9211 warns that the same detail value can mean different things at different caches. If a meaning is intended to interoperate, the specification recommends a registered parameter or another field.

That boundary is healthy. Operators need a place for local diagnostics, but local vocabulary should not silently become a cross-vendor standard. The IANA Cache-Status registry offers a route for generic parameters through Expert Review. Vendor-specific names can remain scoped to their implementation. The registry coordinates names and definitions; it does not approve each live disclosure.

The key parameter also demonstrates why observability cannot be governed only by parser validity. A technically valid cache-key representation may reveal the inputs an attacker needs to explore cache poisoning. Hostnames can reveal topology. Details can expose routing or tenancy. RFC 9211 notes that merely obfuscating the key does not remove the risk.

The minimum safe practice is audience-specific release. A public response might expose only a coarse identifier and interoperable handling category. An authenticated operations request might receive more diagnostic parameters. Highly sensitive key material may remain confined to protected logs. The decision belongs near the cache and its threat model.

A reading protocol for operators

The simplest defensible workflow has six passes.

First, save the field as received and record the capture time, request context and observation point. Second, parse it as an ordered Structured Fields list; never split on commas with an ad hoc string function. Third, preserve each member as a separate statement and attach every parameter only to that member.

Fourth, interpret parameters under their preconditions: hit versus fwd, fwd-status only under fwd, stored and collapsed only under fwd, and ttl as a local calculation. Fifth, classify confidence independently from content. A syntactically valid member can remain unverified. Sixth, apply a disclosure tier before forwarding the diagnostics to another audience.

This process produces a useful chain even when trust is incomplete. It can say, “At this collector, a member identifying itself as the regional edge reported a miss and storage; a later member reported a hit; the first identity is bound to managed infrastructure, while the second is not independently authenticated.” That sentence is longer than “global miss,” but it is auditable.

Sources