Summary

  • HTTP freshness is a comparison between current age and freshness lifetime; an Age field supplies neither the whole calculation nor the governing lifetime.
  • A defensible cache decision joins timing, directives, validation, stale authority and the delivered representation in one receipt.

Imagine an operations dashboard reading Age: 20 from a cached configuration response and colouring the delivery green. The number looks small. Yet the response carries max-age=10, and the cache is serving it under an allowed stale condition while the origin is unreachable. The header is accurate and the dashboard's conclusion is wrong.

RFC 9111 separates concepts that monitoring systems often collapse. A response is fresh when its age has not exceeded its freshness lifetime; it is stale when it has. The test is therefore not “does Age look low?” but whether freshness_lifetime is greater than current_age. A single field cannot supply that comparison.

The lifetime has its own hierarchy. For a shared cache, s-maxage takes precedence. Otherwise max-age can define the lifetime, followed by the difference between Expires and Date. When explicit expiration is absent, a cache may sometimes calculate a heuristic lifetime. RFC 9111 does not prescribe one universal heuristic, so two compliant deployments can reach different expiration times from the same response metadata.

Age is also calculated rather than simply copied. It estimates the seconds since the origin generated or successfully validated the response. The calculation can combine the received Age value with response delay, compare the response time with Date, and add resident time in the current cache. When a stored response is reused without validation, the cache must emit an Age value equal to its calculated current age.

That requirement makes Age valuable evidence, but not a verdict. A value of 20 seconds may describe a fresh response with a 60-second lifetime or a stale response with a 10-second lifetime. A value can also follow successful validation, meaning the relevant state transition is the validation outcome, not merely the response's original generation. Conversely, absence from an origin response does not prove that no cache will be involved later.

Staleness does not always mean unlawful reuse. RFC 9111 allows a cache to generate a stale response when it is disconnected or stale service is explicitly permitted, unless an applicable directive such as no-cache or must-revalidate prohibits it. Correct protocol behavior can therefore deliver stale bytes. Whether those bytes remain acceptable for a price, entitlement, configuration, revocation state or operational instruction is a separate application decision.

The practical control is a freshness-decision receipt. This receipt is an editorial evidence synthesis, not an element defined by the IETF or RFC 9111. Record the cache identity and configuration, request target, stored-response identifier and delivered digest. Preserve Date, received and emitted Age, request time, response time and resident time. Record the lifetime source—s-maxage, max-age, Expires or a named heuristic—along with the effective directives, validation request and result, any stale authority, and the final decision. Then the operator can reproduce why the response was reused instead of treating one visible number as proof.

Sources