How Age relates to current_age

RFC 9111 §4.2.3 inputs and steps

For a response received by a cache, §4.2.3 defines age_value as the received Age value, or zero if there is no valid value available; date_value as the response’s Date; request_time as when the request that resulted in the stored response was made; response_time as when that response was received; and now as the implementation’s clock when it evaluates age.

If the clock is reasonably synchronized with the origin, apparent_age = max(0, response_time − date_value). If every cache along the response path implements HTTP/1.1 or later, response_delay = response_time − request_time and corrected_age_value = age_value + response_delay. The RFC says a cache MAY use corrected_age_value as corrected_initial_age. When very old cache implementations that might not correctly insert Age are present, the more conservative calculation is corrected_initial_age = max(apparent_age, corrected_age_value). Finally, resident_time = now − response_time and current_age = corrected_initial_age + resident_time. RFC 9111 §4.2.3.

These are not interchangeable requirements: use of corrected_age_value as corrected initial age is expressly a MAY when the all-HTTP/1.1-or-later path condition applies; the max(...) expression is the more conservative calculation for possible legacy caches with unreliable Age insertion. The apparent_age estimate depends on reasonably synchronized clocks.

Fully synthetic arithmetic example

The following values are invented to show the calculation. They are not captured from an endpoint, browser, or cache. Assume the receiving cache’s clock is reasonably synchronized with the origin. At 06:00:12 UTC, it receives:

Date: Fri, 16 Oct 2026 06:00:00 GMT
Age: 5
Cache-Control: max-age=60

max-age=60 is a response directive. Assume this cache’s effective freshness lifetime is 60 seconds. The request began at 06:00:10, the response arrived at 06:00:12, and the cache evaluates age at 06:00:32.

This branch illustrates the RFC’s protection for a possible legacy cache that did not insert an accurate Age; it does not claim that such a cache was on any actual path. If the path is known to contain only HTTP/1.1-or-later caches, §4.2.3 permits using corrected_age_value = 7 s as initial age: 7 + 20 = 27 s. These are two identified calculation choices, not observed alternatives from a live cache.

Freshness uses the calculated age

RFC 9111 §4.2 uses the strict test response_is_fresh = (freshness_lifetime > current_age). With the conservative synthetic result and a 60-second lifetime:

60 s > 32 s  → fresh
60 s − 32 s = 28 s of freshness remain

At equality, 60 s > 60 s is false, so the response is stale. The 28-second figure is arithmetic for this example, not a claim that a cache must store or serve the response. RFC 9111 §4.2, §4.2.1.

How this relates to the freshness calculator

The Cache-Control freshness calculator accepts a supplied current-age and compares it with a freshness lifetime such as max-age or a separate shared-cache s-maxage. It subtracts the supplied age and labels equality or an overrun stale. It is a simplified comparison tool, not an RFC current-age calculator: it does not derive age from Date, received Age, request/response timing, resident time, or select an initial-age calculation. The RFC arithmetic above can supply an age for that comparison; the widget itself does not perform those steps.

Method and limits

• Checked the official RFC Editor HTML for RFC 9111 §§4, 4.2, 4.2.1, 4.2.3, and 5.1 on 16 Oct 2026. The report uses those primary standards sections; no other source was needed for its claims.
• Inspected the calculator’s published explanation to verify that it accepts a supplied current-age and freshness lifetime and does not derive current age from timestamps or headers.
• Recomputed the synthetic seconds as arithmetic. No live endpoint, browser, cache, provider, response-header behavior, or analytics was tested. The example cannot establish an implementation’s emitted Age, cache path, current age, or freshness behavior. No demand or population-level inference is made.

Checkable sources

• RFC 9111 §4 — Constructing Responses from Caches: requirement to generate Age equal to stored current_age when an unvalidated stored response is used.
• RFC 9111 §4.2 — Freshness: strict comparison between freshness lifetime and current age.
• RFC 9111 §4.2.1 — Calculating Freshness Lifetime: the freshness-lifetime input; 60 seconds here is an explicit synthetic assumption.
• RFC 9111 §4.2.3 — Calculating Age: inputs, age formulas, conditional MAY, conservative legacy-cache calculation, and resident time.
• RFC 9111 §5.1 — Age: field semantics and presence implication.