A Cache-Control
header is an HTTP header field that allows the server to specify caching directives for the client (such as a web browser) and intermediate caches (such as proxy servers). It controls how the client and caches should store and reuse the response to subsequent requests. It also provides a way to control various aspects of caching, including caching lifespan, cache validation, and cache revalidation.
Learn more: Mozilla Cache-Control documentation 💡
If multiple directives are passed together, each directive is separated by a comma ( , ). If the directive takes an argument, it follows the directive separated by an equal sign ( = ), e.g., max-age=86400
.
Types of Directives
Directives can be broken down into four groups: cacheability, expiration, revalidation, and others.
Cacheability
It refers to whether or not a resource should enter a cache, and the directives below indicate a resource’s cacheability:
public
— indicates any cache may store the response, even if the response is normally non-cacheable or cacheable only within a private cacheprivate
— indicates the response message is intended for a single user (e.g., a browser cache) and must not be stored by a shared cache on CDN or a corporate proxyno-store
— indicates any cache (i.e., a client or proxy cache) must not store any part of either the immediate request or response
Expiration
It refers to how long a resource should remain in the cache, and the directives below affect how long a resource stays in the cache:
max-age=seconds
— indicates the response is stale after its age is greater than the specified number of secondsAge is defined as the time in seconds since the asset was served from the origin server
The
seconds
argument is an unquoted integer
s-maxage=seconds
— indicates that in shared caches, the maximum age specified by this directive overrides the maximum age specified by either themax-age
directive or theExpires
header fieldThe
s-maxage
directive also implies the semantics of the proxy-revalidate response directiveBrowsers ignore
s-maxage
no-cache
— indicates the response cannot be used to satisfy a subsequent request without successful validation on the origin server; this allows an origin server to prevent a cache from using the origin to satisfy a request without contacting it, even by caches that have been configured to send stale responses
Ensure the HTTP Expires
header is set in your origin server to use Greenwich Mean Time (GMT) as stipulated in RFC 2616Open external link 💡
Revalidation
It refers to how and when a cache should revalidate a cached response with the server to ensure it is still valid and up to date.
An example of such type of directive is the must-revalidate
directive. When included in the Cache-Control header, it instructs caches to revalidate a cached response with the server on every subsequent request, even if the response is considered fresh according to the expiration time specified by the max-age
directive. This ensures that the cache serves only up-to-date responses and helps maintain data integrity.
Other
This group includes additional directives that control various aspects of caching, such as forcing caches to revalidate responses, preventing storage of responses in caches, or requiring the use of conditional requests for validation.