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.


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.


These mechanisms are explicit, and both client-side and server-side.


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.