Reference
Cache-Control directives
RFC 9111 defines seven request directives and ten response directives for the Cache-Control header, and four of the names — max-age, no-cache, no-store and no-transform — exist on both sides with different meanings. Three widely used extensions sit outside RFC 9111: immutable from RFC 8246, and stale-while-revalidate and stale-if-error from RFC 5861. The directives that decide most outcomes on a website are max-age, no-cache, no-store and private.
| Directive | Used in | Meaning | Defined in | What the scan reads |
|---|---|---|---|---|
| max-age | Request and response | In a response, the number of seconds the response stays fresh. In a request, the client will not accept a stored response older than that. | RFC 9111 | Read on static resources: under 24 hours is reported as a short cache lifetime. |
| s-maxage | Response | Overrides max-age and Expires for shared caches only, and adds the semantics of proxy-revalidate. | RFC 9111 | Not interpreted on its own. |
| no-cache | Request and response | In a response, a cache must not reuse it without successful validation with the origin. In a request, the client asks for that validation. | RFC 9111 | Not interpreted on its own. |
| no-store | Request and response | A cache must not store any part of the request or the response. | RFC 9111 | Makes an API response count as not publicly cacheable. |
| no-transform | Request and response | An intermediary must not transform the content, for example by recompressing images. | RFC 9111 | Not interpreted. |
| must-revalidate | Response | Once stale, the response must not be reused without successful validation, even when the origin is unreachable. | RFC 9111 | Not interpreted. |
| proxy-revalidate | Response | Same as must-revalidate, for shared caches only. | RFC 9111 | Not interpreted. |
| must-understand | Response | A cache should store the response only if it understands the caching requirements of its status code; meant to be sent with no-store as a fallback. | RFC 9111 | Not interpreted. |
| private | Response | A shared cache must not store the response; a private cache, such as the browser's, may. | RFC 9111 | Makes an API response count as not publicly cacheable. |
| public | Response | Any cache may store the response, even one that would otherwise not be cacheable, such as a response to an authenticated request. | RFC 9111 | Makes an API response under a user-specific path count as publicly cacheable. |
| max-stale | Request | The client will accept a stale response, optionally up to a given number of seconds past its freshness. | RFC 9111 | Not applicable: the scan sends no Cache-Control request header. |
| min-fresh | Request | The client wants a response that will stay fresh for at least the given number of seconds. | RFC 9111 | Not applicable: the scan sends no Cache-Control request header. |
| only-if-cached | Request | The client wants only a stored response; a cache without one answers 504. | RFC 9111 | Not applicable: the scan sends no Cache-Control request header. |
| immutable | Response | The response will not change while it is fresh, so a client need not revalidate it, even on reload. | RFC 8246 | Counted on static resources and shown in the evidence. |
| stale-while-revalidate | Response | A cache may serve the response stale for up to the given number of seconds while it revalidates in the background. | RFC 5861 | Not interpreted. |
| stale-if-error | Request and response | A cache may serve the response stale for up to the given number of seconds when revalidation meets an error. | RFC 5861 | Not interpreted. |
The four directives most policies are made of
`max-age` sets how long a response is fresh. A versioned asset whose URL changes with its content can be fresh for a year; an HTML page that changes without its URL changing usually wants a short lifetime or none.
`no-cache` does not mean "do not cache". It means "store it if you like, but check with me before every reuse" — which, with an `ETag`, costs a round trip and a 304 instead of a full download.
`no-store` is the directive that really forbids storage. It is the one for responses that must never sit in a cache: account pages, anything carrying personal data.
`private` keeps the response out of shared caches — CDNs, proxies — while letting the visitor's own browser keep it. It is the usual answer for content that is specific to one user but not secret from that user.
Why the same name means different things in a request and a response
A response directive is the origin describing how its response may be stored and reused. A request directive is a client stating what it will accept from a cache. `max-age=0` in a browser's request is a reload asking for a fresh copy; `max-age=0` in a response makes it stale immediately.
Directives combine. `public, max-age=31536000, immutable` is the common policy for fingerprinted static files; `no-store` alone is the common policy for a private API response. When `no-store` and `max-age` both appear, the response must not be stored, whatever the lifetime says.
What a scan reads from the header
`performance.cache_control` checks that the entry document declares a Cache-Control policy at all. A missing header there is reported for information only, because leaving HTML to heuristic revalidation is a defensible choice.
`performance.static_cache` requests the site's scripts, stylesheets, images and fonts, reads the number in `max-age`, counts the resources marked `immutable`, and looks for `ETag` or `Last-Modified` validators. A static resource with no cache policy and no validator is a warning; one fresh for less than 24 hours is reported for information.
`api.cache.policy` reads the header on the API responses the scan observed. A response is treated as publicly cacheable when it says `public` or a positive `max-age` and says neither `no-store` nor `private`; that combination on a path that looks user-specific — `/me`, `/account`, `/orders` and similar — is flagged.
The other directives are recorded in the evidence as they were sent but are not interpreted one by one.
Frequently asked questions
- What is the difference between no-cache and no-store?
- no-cache allows storage but requires validation with the origin before every reuse. no-store forbids storage entirely. Content that must never be kept in a cache needs no-store.
- Is immutable part of the HTTP caching standard?
- It is an extension defined in RFC 8246, outside RFC 9111. It tells the browser not to revalidate a fresh response even when the user reloads the page, which is safe only when the URL changes whenever the content does.
- Does private mean the response is secure?
- No. private only keeps the response out of shared caches such as a CDN; it says nothing about who may request it. Access control is decided by authentication, not by a caching directive.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website