= HTTP heuristic freshness
{c}
<HTTP heuristic freshness> estimates an <HTTP freshness lifetime> when a stored <HTTP response> lacks explicit expiration information and is otherwise eligible for that treatment. It allows constrained reuse when the origin has not supplied a lifetime, without pretending that the origin explicitly guaranteed one.<HTTP Caching>[§4.2.2, Calculating Heuristic Freshness]{ref}
Eligibility comes first. The RFC permits heuristics for otherwise allowed responses that are heuristically cacheable by status or explicitly marked cacheable, when explicit freshness information is absent. A cache must not replace an explicit expiration time with its own heuristic. The ordinary storage constraints still apply.<HTTP Caching>[§4.2.2, permitted responses and prohibition when explicit expiration is present; §3, storage constraints]{ref}
For an own example, assume a successful response satisfies those conditions and has no restrictive directives. Its `Date` corresponds to time $1000$ seconds and `Last-Modified` to $400$ seconds. Choose a cache policy that fixes its lifetime at one tenth of the interval between those timestamps:
$$
L=0.1(1000-400)=60\ \text{seconds}.
$$
At <HTTP current age> $45$ seconds, $L>45$ and fifteen seconds remain until the freshness boundary. At age $60$, the strict comparison fails.
The fraction and exact timestamp policy are stated assumptions of this example. The RFC encourages a fraction of the interval since modification and mentions ten percent as a typical setting, but does not prescribe a universal heuristic algorithm or require that fraction.<HTTP Caching>[§4.2.2, Last-Modified heuristic and typical-fraction discussion]{ref}
A long time since modification is evidence useful to an estimate; it is not proof that the origin will remain unchanged for the chosen lifetime. <HTTP cache validation> can later check whether a stored representation remains suitable. Different permitted heuristics can also produce different lifetimes from the same metadata.
An <HTTP private cache> and an <HTTP shared cache> must each respect the applicable caching constraints; being private or shared does not authorize arbitrary estimation. When an origin needs explicit freshness behavior, an explicit control such as `max-age` avoids relying on the cache to infer that lifetime.<HTTP Caching>[§§4.2.1–4.2.2, explicit lifetime and heuristic roles]{ref}
Back to article page
