Dated report · request-side cache controls · 7 Oct 2026

What does request Cache-Control ask the next cache to do?

A request directive expresses a client’s cache-use preference or storage instruction. It does not rewrite the response’s cache policy, and it cannot identify which cache honored it.

Standards review only · expected semantics, not live observations. No authorized runtime or browser/provider experiment was available. No endpoint, browser, cache, CDN, origin, provider, or analytics test was run.

The short answer

RFC 9111 classifies request directives as advisory: a cache MAY implement them, but is not required to. Response directives have the stronger role: caches MUST obey them. The two directions are not copied into each other. Forwarding proxies pass request cache directives along, but a request field cannot target one named cache in a chain. RFC 9111 §5.2.1

Do not read a request header as a universal bypass, origin-contact, or purge command. It cannot prove that a particular cache received or honored the field, that the application origin was contacted, or that old copies were erased.

Request preference versus response policy

These six request directives have different jobs. The distinction is direction-specific: a request-side max-age is not the response-side freshness lifetime with the same name.

`no-cache`

Request asks: Prefer not to use a stored response without successful validation.
Response contrast: Response no-cache must be successfully validated before reuse, although it may be stored.
Limit: The request preference is advisory. It is not a universal end-to-end revalidation guarantee or an origin-fetch command.

`no-store`

Request asks: A cache applying it must not store this request/response exchange and must make the specified best-effort attempt to remove volatile copies promptly after forwarding.
Response contrast: Response no-store also bars using that response to satisfy another request.
Limit: It does not delete an older matching response or provide reliable privacy. If a cache serves an already-stored response, this request directive does not apply to that stored response.

`max-age=N`

Request asks: Prefer a response whose current age is no more than N seconds; absent max-stale, the client does not wish to receive stale content.
Response contrast: Response max-age=N sets the freshness lifetime for a stored response.
Limit: Request max-age=0 does not set response lifetime to zero, purge a copy, or guarantee validation.

`min-fresh=N`

Request asks: Prefer a response with at least N seconds of freshness remaining: lifetime must be at least current age plus N.
Response contrast: RFC 9111 defines no response-side min-fresh policy.
Limit: It filters the request’s freshness preference; it does not shorten or change the response lifetime.

`max-stale[=N]`

Request asks: Accept a response past its freshness lifetime by up to N seconds; with no value, the client accepts stale content of any age.
Response contrast: Response rules such as no-cache, must-revalidate, and applicable shared-cache directives can prohibit stale reuse.
Limit: A request allowance does not override a response prohibition; request directives remain advisory.

`only-if-cached`

Request asks: The client only wishes to obtain a stored response. A cache honoring it SHOULD return a stored response that satisfies the other constraints, or 504 Gateway Timeout.
Response contrast: Request-only in RFC 9111; it does not create a response storage policy.
Limit: It is not a universal no-forwarding guarantee, nor does it permit stale reuse barred by response policy.

A small selection example — synthetic, not fetched

Assume a matching stored response has current age 50 s and response freshness lifetime 300 s. Request max-age=60, min-fresh=30 fits both preferences: 50 ≤ 60, and 250 seconds remain fresh, which is at least 30. At age 290 seconds, only 10 seconds remain, so min-fresh=30 is not met. These are arithmetic examples, not cache behavior measurements; an implementation may not honor the optional request preferences.

Combined or contradictory fields do not supply a portable precedence rule for every implementation. Do not infer how a cache resolves combinations such as no-cache with only-if-cached or max-stale.

Trace the direction of each field

This hypothetical exchange uses example.invalid intentionally, so it performs no network request:

Earlier stored response:
Cache-Control: max-age=600
ETag: "v7"

Later client request:
Cache-Control: no-cache

The first Cache-Control field is response metadata; the second is a request directive. If a cache honors request no-cache, it should not reuse the stored representation for this request without successful validation. It may send a conditional request using the ETag. A successful 304 Not Modified lets the evaluating recipient reuse its stored body after updating metadata; a full response may replace it. A validating next hop is not necessarily the application origin, and the response’s max-age=600 does not become response no-cache.

RFC 9111 §4.3 covers cache validation. For conditional request precedence and 304 semantics, see RFC 9110 §13.1.2 and §15.4.5.

What request directives do not establish

Not a purge. Request no-cache, max-age=0, and no-store do not invalidate old stored responses. RFC invalidation is a separate rule; a provider purge is a separate, provider-scoped operation.
Not proof of origin contact. A cache can validate with a next hop, which may be another cache. A 304 shows a conditional result at a responder, not which hidden hop produced it.
Not a complete cache inventory. Request directives do not clear browser history/bfcache, script-managed Cache Storage, another proxy, another CDN tier, or an application cache.
Not a privacy guarantee. RFC 9111 warns that caches may be noncompliant or compromised and that network observation remains possible. Use the response storage policy and controlled system design for privacy requirements.

When tracing a permitted fixture, capture status, request directives and validators, response Cache-Control, body identity, Age, Cache-Status if present, and a correlated origin marker/counter. Record the vantage and named hop. RFC 9211 makes Cache-Status optional; its absence is not proof of a cache miss. A present Age has defined scope, while its absence does not prove origin contact. See RFC 9111 §5.1 and RFC 9211 §2.

Browser controls are a different layer

A browser reload or developer-tools cache toggle controls that user agent’s behavior; it is not an HTTP request directive sent to every intermediary. Chrome’s documentation describes its browser-cache controls as DevTools features, not a report of CDN/proxy state. Application caches such as service-worker Cache Storage have their own logic. These controls were not exercised in this review. Chrome DevTools Network reference · Service-worker update report

Sources and retrieval limits

Primary RFC Editor pages were reviewed on 7 Oct 2026, 06:05–06:12 UTC. RFC 9111 is the controlling source for cache directives; the cited MDN and Chrome pages are secondary/browser-context checks. No vendor behavior comparison or live fixture was performed.

RFC 9111 — HTTP Caching, §§2, 4.2–4.4, 5.1, 5.2.1–5.2.2, 6.
RFC 9111 status page — STD 98 / Internet Standard.
RFC 9110 — HTTP Semantics, §§13.1.2–13.1.3, 13.2.2, 15.4.5.
RFC 9211 — Cache-Status, §2; optional named-cache evidence.
MDN: Cache-Control and MDN: HTTP caching — secondary wording cross-check.
Chrome DevTools: Network reference — scoped browser-cache control example.