Cache-Control appears on HTTP requests as well as responses. What do the request directives `no-cache`, `max-age=0`, `max-stale`, `min-fresh` and `only-if-cached` ask a cache to do, and how do they interact with what the origin declared?

## Two sides of one header `Cache-Control` is defined for both directions. On a response it is the origin's statement of policy: how long this may be reused, by whom, and under what conditions. On a request it is the client's statement of tolerance: how old an answer it is willing to accept and whether it will accept a network trip. A cache sitting between them must satisfy both constraints simultaneously. The asymmetry to internalise: a request directive can almost always make reuse *stricter*, and only in one narrow case (`max-stale`) can it loosen it — and even then, not past `must-revalidate` or `no-store`. A client cannot talk a cache into serving something the origin marked unservable. ## The directives **`no-cache`** on a request tells every cache along the path not to reuse a stored response without end-to-end revalidation. The stored copy is still valuable: revalidation usually yields `304 Not Modified` and the cache serves its bytes. This is exactly what a browser sends when the user presses reload. **`no-store`** on a request asks that neither this request nor its response be written to cache storage. It is rarely sent and unevenly honoured. **`max-age=N`** says the client will not accept a stored response whose current age exceeds N seconds. `max-age=0` therefore rejects everything stored and forces a revalidation — which is why it behaves much like request `no-cache`. The nuance: `no-cache` demands revalidation regardless of age, while `max-age=0` frames it as an age constraint; when combined with `max-stale` the two behave differently, since `max-age=0, max-stale=300` would permit a response up to five minutes stale. **`max-stale[=N]`** relaxes the requirement: the client accepts a response that is stale, by up to N seconds, or by any amount if the value is omitted. This is the one client-side loosening directive, and it is bounded — a cache must not serve stale in response to it if the stored response carried `must-revalidate` or `no-cache`. It is useful for tolerant background jobs, prefetching, and clients on flaky links. **`min-fresh=N`** is the opposite: the client wants a response that will *remain* fresh for at least N more seconds. The motivating case is a client about to lose connectivity or start a long operation, which does not want something that expires mid-way. **`only-if-cached`** instructs the cache to answer from storage or, if it has no suitable stored response, return `504 Gateway Timeout` without contacting the origin. It underpins offline-first patterns and lets a client probe cache contents without generating upstream traffic. In a browser this is one of the primitives behind cache-first fetch strategies. **`no-transform`** forbids intermediaries from altering the payload — recompressing images, minifying, rewriting media types. It exists in both directions and matters where an intermediary would otherwise "helpfully" degrade content. ## Reload semantics in browsers Understanding these explains browser behaviour that otherwise looks arbitrary. A **normal reload** sends `Cache-Control: max-age=0` (some browsers `no-cache`) for the document, and revalidates subresources — which is precisely the behaviour `immutable` on a response suppresses. A **hard reload** sends `Cache-Control: no-cache` (historically also `Pragma: no-cache`) and refuses stored responses for the document *and* its subresources, so everything is re-fetched. This is why "it works after a hard refresh" is a caching diagnosis, not a fix: it tells you the stored response differed from the origin's current one. ## Why this matters in debugging When a client claims it is seeing stale data, the request directives determine what is even possible. If the client sends no directives, the stored response's `max-age` fully governs reuse and the client cannot force freshness without changing the URL. If the client can send `no-cache`, you have a way to test the origin without waiting for expiry. And if a proxy is returning `504` for requests that clearly should reach the origin, an `only-if-cached` directive slipped in by a client library is a real, if uncommon, cause. One caution: request directives are honoured by caches, not by the origin. Sending `Cache-Control: no-cache` on a request does not tell the application to skip its own database or Redis cache — those are outside the HTTP caching model entirely, and treating the header as a general "bypass all caching" signal is a category error unless the application deliberately implements it.