Caching
HTTP's caching mechanism allows intermediary servers between a web server and its clients to cache responses according to set of heuristics. There are a number of approaches to this.
Expiration and validation
These mechanisms are server-side, implicit directives.
Modification date
In requests clients will include an If-Modified-Since
header for all resources that already exist within their caches, containing the value of the Date
sent by the server in response.
The server can either:
- find that the resource has not been modified since this date and return a 304 Not Modified response; or
- serve the updated content with a new
Last-Modified
value.
ETag
The server can assign opaque values representing a file's content (e.g. a hash) which a client can store for use in subsequent requests. The protocol defines an optional "weak validator" syntax (prefixing the value with a W/
) to indicate semantic compatibility but not byte-for-byte compatibility.
For resources already in the cache, the client can send and If-None-Match
header with the value of the previous ETag
. If the resource remains unchanged the server may respond with a 304 Not Modified.
Can also be used to avoid collisions during a POST
with the If-Match
header, allowing the server to respond with a 412 Precondition Failed to signal that the resource has been modified while the user was completing a form.
Control
These mechanisms are explicit, and both client-side and server-side.
Expiry
Optionally, an Expires
header can be sent to cause the content to expire at a specific time.
Cache control
Clients can include Cache-Control
headers in requests:
max-age=seconds
, relative to request time.max-stale[=seconds]
accepts a stale response, relative to request time.min-fresh=seconds
requires a response will be fresh for the specified number of seconds.no-cache
allows storage in caches, but forces revalidation.no-store
forbids storage in any cache.no-transform
forbids caches/proxies modifying the response body,Content-Encoding
,Content-Range
orContent-Type
.only-if-cached
allows a client to prevent a cache from going out to an origin server to request a page. It should respond with a 504 Gateway Timeout if not.
Servers can include Cache-Control
headers in responses:
must-revalidate
forbids caches from using their stale copies without revalidation with the origin server.no-cache
no-store
no-transform
public
allows any cache to store the response, even if it'd otherwise be considered non-cacheable.private
allows storage only in a user's browser.proxy-revalidate
appliesmust-revalidate
for shared caches.max-age=seconds
s-maxage=seconds
overridesmax-age
or theExpires
header, but only for shared caches.
Browsers typically provide multiple ways of triggering these behaviours:
- "Refresh" actions typically send
Cache-Control: max-age=0
, - "Hard refresh" actions typically send
Cache-Control: no-cache
.
The old Pragma: no-cache
response header will behave the same way as Cache-Control: no-cache
.
Backlinks