HTTP defines both the `Expires` header and `Cache-Control: max-age`. If a response carries both, which one wins, and why does `Expires: 0` appear so often in real responses?

## Two generations of the same idea HTTP/1.0 had one expiry mechanism: `Expires`, an absolute HTTP-date after which a stored response must not be reused without validation. HTTP/1.1 introduced `Cache-Control` and with it `max-age`, a relative lifetime in seconds. Both survive, and the rule is simple: **`Cache-Control` overrides `Expires` wherever it is understood.** The full precedence order for computing a freshness lifetime is: 1. `Cache-Control: s-maxage` — shared caches only. 2. `Cache-Control: max-age`. 3. `Expires` minus `Date`. 4. A heuristic derived by the cache, if none of the above is present. ## Why relative beat absolute `Expires` requires the cache to compare a timestamp written by the origin against its own clock. Any disagreement between the two clocks distorts the lifetime directly: an origin running five minutes fast grants five extra minutes of freshness to every cache on earth; one running slow expires content early. Caches partially defend against this by computing the lifetime as `Expires - Date` rather than `Expires - now` — using the origin's own `Date` header keeps both endpoints on the same clock — but that only works when `Date` is present and correct. `max-age` sidesteps the problem: the cache measures elapsed time locally and adds the reported `Age`, so no cross-machine clock comparison is needed. It also composes cleanly across hops, which absolute timestamps do not. ## Invalid dates mean expired RFC 9111 requires a cache to treat an `Expires` value it cannot parse — including `0`, which is not an HTTP-date at all — as a time in the past. That is what makes `Expires: 0` work as an idiom. Other forms you will see are `Expires: -1` and an explicit past date such as `Expires: Thu, 01 Jan 1970 00:00:00 GMT`. All three mean the same thing: stale immediately. The reason to write it deliberately, rather than by accident, is defence against pre-HTTP/1.1 intermediaries. In practice those are essentially extinct, so the modern equivalent of "do not reuse without checking" is `Cache-Control: no-cache`, and "do not store at all" is `Cache-Control: no-store`. Frameworks still emit the combination `Cache-Control: no-cache, no-store, must-revalidate` plus `Pragma: no-cache` plus `Expires: 0` as a defensive block; it is redundant but harmless. Note a related trap: `Pragma: no-cache` is an HTTP/1.0 *request* directive. As a response header it has no defined meaning in RFC 9111, which deprecates it, and modern caches ignore it there. Relying on it to prevent response caching does nothing. ## When Expires is still worth sending Rarely, and only as a companion. If you have a hard calendar deadline — an embargoed announcement, a scheduled price change, a token that is invalid after a specific instant — `Expires` expresses that intent directly and readably, but you should still send `max-age` computed from the same instant, because `max-age` is what will actually be obeyed. Sending `Expires` alone means the lifetime is at the mercy of clock agreement. The inverse mistake is more common: teams set a far-future `Expires` for asset caching without a `max-age`, then find behaviour varies across intermediaries, or that the date passes and everything silently becomes uncacheable on a specific day. A relative `max-age` never has a cliff edge on a calendar date. ## What to remember when reading a response Scan for `Cache-Control` first. If it contains `s-maxage` or `max-age`, `Expires` is decoration and you can ignore it. If `Cache-Control` is absent or carries no lifetime directive, then `Expires - Date` is the lifetime. If neither is present, the cache is free to invent a heuristic lifetime, which is where surprises come from. And if `Expires` holds `0`, `-1` or garbage, the response is stale from the moment it arrives — which is deliberate, not a bug.