Summary

  • A cache that implements targeted fields selects the first valid, non-empty field on its ordered target list; a cache that does not target that field must not let it change its behaviour.
  • The same response can therefore be stored, rejected or governed by another field at different hops, even when CDN-Cache-Control is syntactically correct.

Consider a deliberately hypothetical release. The origin sends Cache-Control: no-store and CDN-Cache-Control: max-age=600. The first CDN recognises the targeted field and stores the response for ten minutes. A downstream enterprise cache does not list that field and obeys no-store. A second CDN has a vendor-specific targeted field earlier in its configured target list and selects that field instead. Yet the deployment dashboard records a single result: “cache policy: 600 seconds.”

The header is not lying. The dashboard has erased the decision process that gives the header meaning.

RFC 9213 defines a targeted cache-control field as a response field whose distinct name identifies the intended cache or class of caches. CDN-Cache-Control is the standard example. Its value uses cache directive semantics, but an implementing cache also maintains an ordered target list. That list may be fixed, configured or generated per request. When several recognised fields are present, the cache selects the first valid, non-empty field in that order.

Selection has a strong consequence. Once a cache selects a targeted field, it uses that field to determine the response’s caching policy and ignores ordinary Cache-Control and Expires for that response. If none of its targeted fields is present with a valid, non-empty value, it falls back to the ordinary HTTP mechanisms defined by RFC 9111. Two conforming caches can therefore receive identical bytes and reach different decisions because their target lists differ.

Scope matters just as much as precedence. A targeted field absent from a cache’s target list must not change that cache’s behaviour and must be passed through. A non-CDN cache can see CDN-Cache-Control without acting on it. Conversely, a CDN that does act on it will usually forward the field for downstream CDN caches, but RFC 9213 permits removal when forwarding is undesirable. The field visible at the observation point is not proof of the field set seen at every earlier or later hop.

Parsing is another decision boundary. Targeted fields are Dictionary Structured Fields. Although their values often resemble ordinary Cache-Control, error handling is not interchangeable. An empty or invalid targeted field is ignored, which can activate fallback policy. A dashboard that records the string but not the parser verdict may attribute behaviour to a field the cache never accepted.

Freshness also remains relative to the cache that selected the policy. RFC 9213’s example allows a CDN to treat a response as fresh for 3,600 seconds while ordinary shared caches receive a 600-second lifetime and other caches receive 60 seconds. After 1,800 seconds the response is fresh to the CDN and stale elsewhere. There is no contradiction; there are different applicable policies. The operational error is to flatten them into one chain-wide freshness state.

That flattening can become a security error. RFC 9213 warns that carrying multiple caching policies can cause confusion and unintended reuse of sensitive information. A successful origin configuration test proves only that the intended fields were emitted. It does not prove which caches recognised them, which field each selected, whether parsing succeeded, whether a field was removed, or whether observed reuse matched the intended boundary.

The practical unit of evidence is therefore a per-hop policy receipt. For each material cache, record its class and identity, ordered target list, exact received fields, parser result, selected field, effective directives, freshness inputs, fallback path, forwarding or removal action, and an observed storage or reuse result. Preserve unknown hops rather than silently inheriting the nearest visible decision.

The receipt is an editorial operating control, not an IETF protocol object. Its purpose is to stop one valid field from becoming an unsupported statement about an entire chain.

Sources