Repository navigation
Heuristic freshness computed from Last-Modified #3
Description
challenge / use case
A response stating no explicit expiration is revalidated on every exchange, even where it carries a Last-Modified
field that says how volatile the content actually is. An origin whose content has not changed in a year is re-fetched
as eagerly as one edited a minute ago.
proposal
Derive a freshness lifetime from the response header fields where the origin states no explicit expiration, as
permitted by RFC 9111 § 4.2.2: take the interval since Last-Modified and treat a fraction of it as the lifetime,
around 10% as the RFC encourages.
Guards:
- apply only where no
Cache-Controlfreshness directive and noExpiresis stated;no-cacheandmax-age=0are
stated expirations and must keep winning, so the test is whether a directive is present, not whether the computed
lifetime is0 - apply only for the heuristically cacheable status codes of RFC 9110 § 15.1
- bound the result, so a distant
Last-Modifieddoes not yield an unbounded lifetime - let
ttlcap the result as it caps any computed lifetime
alternatives
Leaving it to the consumer to state a flat lifetime. That covers an origin stating nothing at all, but ignores the
volatility an origin does state, so a stable and a churning resource are reused for the same span.
notes
Ranks between the two cases already settled: a stated expiration wins over this, and this wins over a flat lifetime
the consumer states for an origin whose responses carry no Last-Modified either.
Activity
[-]Heuristic freshness for responses stating no explicit expiration[/-][+]Heuristic freshness computed from Last-Modified[/+]feat!: assume a freshness lifetime from the last modification time
knoan commentedon Sep 3, 2026
Implemented in
4dc394donrelease/0.1.Approach
A response stating no expiration but reporting a usable
Last-Modifiedis now reused for a tenth of the interval its content had already gone unchanged when the response was generated, measured up to the instant the origin server states inDateand falling back to the reception time where it states none, matching how the lifetimeExpiresstates is measured.Guards
Cache-Controlno-cache,max-age,must-revalidateorproxy-revalidatedirective or anExpiresfield keeps winning, tested by presence rather than by the lifetime it computesttlcaps the assumed share as it caps a stated expiration, and supplies the freshness where no usableLast-Modifiedis reportedOpen point
The bound is
ttlalone, so the defaultttlof0leaves the assumed share uncapped: aLast-Modifiedten years back yields a one-year lifetime. Filed separately if a built-in ceiling is wanted.