Summary

  • A Cache-Status member describes the reporting cache’s handling of a response and request; its hit and fwd parameters carry defined local meaning.
  • Caches decide when to emit the field, parameters are optional, and disclosure can be restricted, so a short list is not proof that no other cache or decision existed.

Consider an explicitly hypothetical incident review. A response carries Cache-Status: edge; hit. The dashboard renders one green box, labels the request a one-cache delivery and records that no upstream system participated. The member can be truthful: the edge did satisfy this request from its cache without forwarding it. But an upstream cache might have supplied the stored response during an earlier exchange and omitted its own field. The response says what the edge did now. It does not reconstruct every event that made the stored response available.

RFC 9211 gives Cache-Status a precise but bounded job. Each list member represents a cache that handled the request and chose to report. When several members survive, they are ordered from the cache closest to the origin toward the cache closest to the user. A cache adding a member should preserve values already present. Those rules make the field valuable for debugging a visible chain.

The list is not guaranteed to be exhaustive. The same specification says caches determine when adding the field is appropriate. One deployment may add it to every response; another may expose it only when configured or when a request activates a debugging mode. Security policy can also justify omission or selective disclosure because cache state, activity and key details can assist attacks. The absence of a member therefore means “not reported here,” not necessarily “no cache existed here.”

The parameters are similarly scoped. hit means that the reporting cache did not forward this request and obtained the response from cache. fwd means that it forwarded the request toward the origin and can give a reason such as uri-miss, vary-miss, stale or request. These statements are operationally useful. They should not be diluted into vague labels.

But local truth is not complete topology. A fwd-status value is the status returned by the next-hop server. That next hop may be another intermediary rather than the origin. A cache identifier can be a product name, hostname, address or generated string, depending on the deployment. Optional details can differ by implementation. Without configuration and observation-point context, identical-looking labels need not identify the same role, and different labels need not prove independent infrastructure.

Time also matters. Cache-Status describes the handling of the corresponding response and request. A hit does not, by itself, narrate when or through which chain the stored response was acquired. It does not prove that the origin was never contacted in the object’s history. Nor does one response explain how a nearby request with different directives, credentials, Vary values or freshness conditions was handled. RFC 9111 makes those request-specific cache decisions separate.

This distinction protects incident attribution. A visible fwd=stale; fwd-status=304 can support a claim about what the reporting cache received from its next hop. It cannot alone establish that the next hop was the origin, that every cache disclosed itself, or that the same decision occurred elsewhere. A sparse field might reflect a short path, a disclosure policy, an implementation limit or a mixture of all three.

Use a cache-observation receipt. This is an editorial operating construct, not an IETF-defined protocol object. Preserve the raw field bytes and bind them to the request and response, observation point and time. Record each expected cache hop, whether its configuration emits Cache-Status for this request class, the identifier mapping, parameters exposed or withheld, forwarding trace, next-hop identity and corroborating logs. Mark gaps as unknown instead of converting silence into absence.

The receipt does not replace Cache-Status; it keeps the field within its evidential scope. A reported hit remains evidence of a local hit. A reported forward remains evidence of forwarding by that cache. The additional record answers the larger question a dashboard often asks: how much of the chain was capable of reporting, how much actually reported, and what independent evidence closes the missing links?

Sources