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 or Content-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 applies must-revalidate for shared caches.
max-age=seconds
s-maxage=seconds overrides max-age or the Expires 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