Guide · RFC 9111 · 16 Oct 2026

Age and current_age

A received Age value is an input to an HTTP cache’s age calculation, not a timeless answer to how old a stored response is now.

Standards review with invented arithmetic for illustration; no live endpoint or cache behavior was tested.

Short answer

Age is the sender’s estimate, in seconds, of time since a response was generated or successfully validated at the origin. RFC 9111 §4.2.3 calculates a receiving cache’s current_age from corrected initial age plus time resident. The calculation can use Date, received Age, request/response times, and the cache’s current time. When a cache reuses a stored response without validation, it must generate an Age equal to that stored response’s current_age at that response point, replacing any received field. RFC 9111 §4, §4.2.3, §5.1.

A receiving cache uses Date and Age along with request and response times to determine corrected initial age, adds time resident after receipt, and obtains current age.

Received response — Date · Age; request_time; response_time
Initial age — apparent_age; corrected_age_value; choose per §4.2.3 conditions
Resident time — now − response_time; time after receipt
current_age — corrected_initial_age; + resident_time
An Age value is an input; the receiving cache calculates age for the time it evaluates the stored response.

RFC 9111 §4.2.3 separates age at receipt from time spent resident in the receiving cache.

The calculation in two stages

For a response received at response_time, RFC 9111 defines age_value as the valid received Age value, or zero when no valid value is available. If the cache’s clock is reasonably synchronized with the origin, it can calculate apparent_age = max(0, response_time − date_value). For a response path whose caches all implement HTTP/1.1 or later, it also defines response_delay = response_time − request_time and corrected_age_value = age_value + response_delay.

The cache MAY use corrected_age_value as corrected_initial_age under that path condition. If very old caches that might not insert Age correctly are present, the RFC gives the more conservative calculation corrected_initial_age = max(apparent_age, corrected_age_value). These are distinct choices, not measurements of alternative behavior. After receipt, resident_time = now − response_time and current_age = corrected_initial_age + resident_time. RFC 9111 §4.2.3.

What Age can establish

RFC 9111 §5.1 says the presence of Age implies that the response was not generated or validated by the origin for this request. The field does not identify a particular cache or hop. Its absence is not proof that the origin was contacted. A correctly generated outgoing Age on unvalidated stored-response reuse represents the serving cache’s calculated age at that point; delivery and later residence can add time before another cache evaluates it.

Use current_age for freshness

RFC 9111 tests freshness with freshness_lifetime > current_age. Equality is stale. In the synthetic example, the conservative current age is 32 seconds with a 60-second lifetime, so the strict test is 60 > 32 and simple remaining-time arithmetic gives 28 seconds. This comparison does not require a cache to store or serve the response. RFC 9111 §4.2.

The worked example and both initial-age branches are detailed in the dated report. To compare a supplied age with max-age or s-maxage, use the freshness calculator; it does not derive RFC current_age from timestamps or headers.

Primary source

RFC 9111 §4 — Constructing Responses from Caches: unvalidated stored-response reuse and the generated Age requirement.
RFC 9111 §4.2 — Freshness: the strict freshness test.
RFC 9111 §4.2.3 — Calculating Age: inputs, initial-age choices, resident time, and current_age.
RFC 9111 §5.1 — Age: field meaning and its presence implication.