= HTTP freshness lifetime
{c}
The <HTTP freshness lifetime> is the duration against which an <HTTP response>'s <HTTP current age> is compared to determine <HTTP freshness>. It can be specified explicitly or, where allowed, estimated by a cache. It is not the same as the amount of fresh time remaining: that depends on the response's current age as well.<HTTP Caching>[§4.2, freshness comparison; §4.2.1, Calculating Freshness Lifetime]{ref}
For valid explicit metadata, the RFC applies the first relevant rule. An <HTTP shared cache> uses `s-maxage` when present; otherwise `max-age` applies. If neither applicable directive is present, `Expires` supplies an expiration time from which the response's `Date` is subtracted, with the specified receipt-time fallback when `Date` is absent. Only when there is no explicit expiration time can <HTTP heuristic freshness> be applicable.<HTTP Caching>[§4.2.1, ordered lifetime rules and Date fallback]{ref}
Consider a response with `Cache-Control: max-age=600, s-maxage=60`. An <HTTP shared cache>, which serves more than one user, takes a $60$-second lifetime. An <HTTP private cache>, dedicated to one user, uses $600$ seconds instead. Assume the response otherwise satisfies the relevant storage and reuse rules.<HTTP Caching>[§1, private/shared cache definitions; §§4.2.1 and 5.2.2.10, s-maxage precedence]{ref}
At current age $45$ seconds, the shared cache has $15$ seconds until its freshness boundary, while the private cache has $555$. At age $60$, the shared response is no longer fresh because $60>60$ is false; the private cache's comparison $600>60$ still succeeds. These are two cache policies for the same response metadata, not conflicting estimates of the response's age.
<HTTP heuristic freshness> is constrained estimation, not an instruction to assign every response an arbitrary lifetime. The RFC allows heuristics under specified conditions and does not prescribe one universal estimation algorithm.<HTTP Caching>[§4.2.2, heuristic applicability and algorithms]{ref}
Finally, a computed lifetime does not override every other directive. Conflicting controls require the restrictive handling specified by the RFC; a freshness calculation also does not force a user agent to refresh its visible page. The lifetime governs cache operation, while the complete reuse decision still depends on the request and applicable response rules.<HTTP Caching>[§4.2.1, conflicting directives; §4.2, caches versus display/history mechanisms]{ref}
Back to article page
