A backend returns HTML with a `Last-Modified` header but no `Cache-Control` and no `Expires`. Users report seeing outdated pages. Explain what caches are permitted to do with such a response and how you would fix it.

## Silence is not "do not cache" The single most useful sentence here: **an HTTP response with no caching headers is not uncacheable.** RFC 9111 allows a cache to store a response whose status code is cacheable by default — 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414, 501 — and, if the response carries no explicit expiration, to *derive* a freshness lifetime by heuristic. Origins that emit nothing have delegated the decision to every cache between them and the user. ## The LM-factor heuristic The specification does not mandate an algorithm; it requires only that the heuristic be conservative and that caches not use one when the response has explicit expiry or is otherwise restricted. In practice essentially everyone implements a variant of the **LM factor**, inherited from RFC 2616's non-normative guidance: ``` freshness_lifetime = (Date - Last-Modified) × 0.1 ``` usually with a cap (commonly a day or a week). The reasoning is a crude stability prior: a resource that has not changed in months probably will not change in the next few hours. Implementations differ in the factor and the cap, which is itself a problem — the behaviour of your site varies by which cache a user sits behind. A related quirk: with **no** `Last-Modified` and no explicit lifetime, most caches have nothing to compute from and treat the response as immediately stale or non-cacheable. So the counterintuitive outcome is that adding `Last-Modified` to a response with no `Cache-Control` *increases* how long it may be cached. ## Diagnosing the reported symptom Work from the wire, not from theory: 1. `curl -I` the URL and read `Cache-Control`, `Expires`, `Last-Modified` and `Age`. Absent lifetime plus a distant `Last-Modified` confirms the hypothesis. 2. A large `Age` on responses through the CDN tells you the edge is holding it and gives you the elapsed time. 3. Compare through the CDN versus straight to origin to locate which layer is serving stale. 4. Check whether affected users clear up with a hard reload — that indicates a browser-side stored copy, which you cannot purge and which will keep affecting them until its heuristic lifetime expires. That last point is the reason to treat this as urgent: a CDN can be purged, browser caches cannot. If a heuristic gave browsers ten days, some users will stay stale for ten days no matter what you deploy — unless the URL changes. ## The fix **Immediately:** ship an explicit `Cache-Control` on the affected responses. For HTML that must always reflect current state, `Cache-Control: no-cache` is usually right — it permits storage and requires revalidation, so with a validator present most requests cost a 304 with no body. If a small drift window is acceptable, a deliberate `max-age=60` is cheaper still. Then purge the CDN, and accept that already-cached browser copies will age out on their own. **Structurally:** make "no caching policy" impossible. Set a default `Cache-Control` in the framework or reverse proxy so every response carries one; make the edge override missing headers rather than pass silence through; and add a smoke test that asserts key routes emit the expected directives, since caching headers are easy to lose in a refactor and the failure is invisible until users complain. ## Two footnotes worth knowing Under RFC 2616, a cache that applied a heuristic lifetime greater than 24 hours had to attach a `Warning: 113 Heuristic Expiration` header. **RFC 9111 deprecates the `Warning` header entirely**, so that signal no longer exists and you cannot detect heuristic caching from response headers alone. Also note that `404` and `410` are cacheable by default. A transient 404 emitted during a deploy, with no `Cache-Control`, can be heuristically cached and keep a page "missing" long after it exists again — the same failure mode, on a status code most people never think to set caching headers for.