Decision guide · request Cache-Control · 7 Oct 2026

Request cache directives are preferences, not cache commands

A request tells an HTTP cache what the client prefers for this response. It does not change response policy, target one cache, or prove a fetch reached the origin.

Documentation-only. No authorized runtime or browser/provider experiment was available; the semantics below are expected from the standards, not live observations.

Start with the direction

Request Cache-Control is advisory under RFC 9111: caches MAY honor its directives, but need not. Response cache directives are mandatory for caches to obey. A request directive is not copied into the response, and it is not a universal bypass, origin-contact, or purge command. RFC 9111 §5.2.1

Which request preference fits?

`no-cache`

Prefer not to reuse a stored response without successful validation. Not a guaranteed origin fetch; response no-cache is the stronger reuse rule.

`no-store`

Ask applying caches not to store this exchange. It does not delete an older matching entry or promise privacy.

`max-age=N`

Prefer a response whose current age is at most N seconds. It does not set the response lifetime or purge a copy.

`min-fresh=N`

Prefer a response that will stay fresh for N more seconds. Request-only; it does not change the response lifetime.

`max-stale[=N]`

Accept stale by up to N seconds; no value means any age. A response prohibition can still bar stale reuse.

`only-if-cached`

Only wish to obtain a stored response. An honoring cache SHOULD return a suitable one or 504; this is not a universal guarantee.

Do not confuse two jobs

Request: choose among possible responses

max-age and min-fresh state freshness preferences; no-cache prefers validation; max-stale permits a stale preference; only-if-cached asks for stored content.

Response: govern stored content

Response max-age sets freshness lifetime. Response no-cache requires validation before reuse. Response no-store blocks storage and reuse. These response rules do not arise merely because a request used a directive with the same name.

Request directives are advisory, so even a well-formed preference cannot prove which cache applied it. A proxy forwards cache directives, but the field cannot address one named hop.

For a stale or unexpected response

Separate request directives from response Cache-Control and validators.
Check the named cache and the cache-key/request variant that could match.
Use Age, Cache-Status if present, Via, provider fields, and authorized logs as scoped evidence—not as a complete inventory.
Do not infer origin contact from 304 or missing Age, and do not call a request directive a purge.

See the full dated report and synthetic decision cases → for the directive-by-directive contrast, a validation example, evidence limits, and sources.