 HTTP freshness

HTTP freshness describes whether a stored HTTP response is young enough for reuse according to its applicable lifetime. The comparison isThe strict inequality matters: a response exactly at its lifetime boundary is no longer fresh.^[ref]

The HTTP freshness lifetime can come from explicit cache controls or, where permitted, a heuristic. The HTTP current age accounts for age accumulated before the response entered the present cache as well as its residence there. Counting only the seconds since this cache received the response can therefore underestimate its age.^[ref]

For an own example, suppose the applicable lifetime is $60$ seconds and the correctly calculated current age at a chosen instant is $20$ seconds. Keep the lifetime fixed. After another $30$ seconds, the age is $50$, so $60>50$ and the response remains fresh. After another $40$ seconds from the original instant, the age is $60$ and the strict comparison fails. After $45$ seconds it is $65$, again stale. These calculations start from a given current age; they do not derive it from local residence time alone.

Freshness and HTTP cache validation answer different questions. An old response might still match the origin's present HTTP representation. Validation can establish that reuse remains appropriate without retransmitting the representation body. Conversely, a fresh response has not thereby been checked against the origin at every use.^[ref]

Other rules still govern reuse. For example, the unqualified Cache-Control: no-cache response directive requires successful validation before subsequent use, even though the response can be stored. Stale-serving rules also have explicit conditions. A freshness calculation is therefore one part of deciding whether a stored HTTP response may satisfy a particular request, rather than a complete permission test.^[ref]