An HTTP response arrives at your cache with `Date: 10:00:00`, `Cache-Control: max-age=300` and `Age: 240`. How long can your cache serve it, and how is a stored response's current age actually computed?

## The rule that surprises people `Cache-Control: max-age=300` does not mean "each cache may hold this for 300 seconds". It means the response may be reused until it is 300 seconds old, counted from the moment the origin generated (or last validated) it. If lifetimes restarted at every hop, a chain of three caches would turn a five-minute lifetime into fifteen, and the origin would have no control over how stale content could get. The `Age` header is the mechanism that prevents this. ## The Age header `Age` is a response header carrying the cache's estimate, in seconds, of how long it has been since the response was generated or successfully validated at the origin. An origin serving a fresh response sends no `Age` (equivalently zero). Every cache that stores and reuses a response emits `Age` reflecting its own holding time plus whatever it received. So `Age` accumulates along the path and is the shared unit of account across independent caches. ## The computation, in the RFC's terms Define `request_time` as when your cache sent the request and `response_time` as when it received the response. - `apparent_age = max(0, response_time - Date)` — how old the response looks by comparing its origin timestamp with your clock. Floored at zero because clock skew can make it negative. - `response_delay = response_time - request_time` — how long the fetch took. - `corrected_age_value = Age_header + response_delay` — the reported age, adjusted for the fact that the response spent the transfer time in flight after that value was computed. - `corrected_initial_age = max(apparent_age, corrected_age_value)` — the age on arrival. - `resident_time = now - response_time` — how long you have held it. - **`current_age = corrected_initial_age + resident_time`** The response is fresh while `current_age < freshness_lifetime`. ## Why the maximum of two estimates Each estimate has a failure mode and the maximum is the conservative choice. `apparent_age` depends on the origin's `Date` header agreeing with your clock. A misconfigured origin whose clock runs slow makes responses look older than they are; one running fast makes them look newer, which is why the value is floored at zero. `corrected_age_value` depends on upstream caches computing and forwarding `Age` honestly. An HTTP/1.0 intermediary that never emits `Age`, or a buggy proxy, would under-report. Taking the larger means a broken clock or a silent intermediary produces *earlier* expiry — an unnecessary revalidation — rather than serving content past the lifetime the origin authorised. Erring toward extra round trips is the right direction; erring toward extra staleness is not. ## Working the example `Date: 10:00:00`, `Age: 240`, `max-age=300`, and suppose the response arrives at 10:04:01 after a 1-second fetch. - `apparent_age = 10:04:01 - 10:00:00 = 241` - `corrected_age_value = 240 + 1 = 241` - `corrected_initial_age = 241` - Freshness lifetime is 300, so it is fresh while `241 + resident_time < 300`, i.e. for about **59 more seconds**. Then it goes stale and the next request triggers a conditional check. ## What this explains in practice **"Our CDN caches for an hour but browsers refetch after five minutes."** The CDN serves a response with a large `Age`; the browser subtracts it and gets a short remaining lifetime. If you want browsers to hold things longer independently of edge age, that is what `max-age` plus `s-maxage` is for — `s-maxage` governs the shared cache, `max-age` the browser, and the browser still subtracts `Age`. **Debugging staleness.** `Age` is the first header to read. A large `Age` on a response that should be fresh points at an intermediary holding it; `Age: 0` on every response points at a cache that is not caching at all. **Clock skew matters.** Because `apparent_age` compares the origin's `Date` with local time, an origin with a wrong clock systematically shortens or distorts cache lifetimes across the whole internet. NTP on origin servers is a caching concern, not just a logging one. **Heuristic freshness uses the same arithmetic.** When there is no explicit lifetime, whatever the cache derives is still compared against this same `current_age`, so `Age` accounting applies identically.