HTTP: The Definitive Guide

Controlling Cachability

HTTP defines several ways for a server to specify how long a document can be cached before it expires. In decreasing order of priority, the server can:

• Attach a Cache-Control: no-store header to the response.

• Attach a Cache-Control: must-revalidate header to the response.

• Attach a Cache-Control: no-cache header to the response.

• Attach a Cache-Control: max-age header to the response.

• Attach an Expires date header to the response.

• Attach no expiration information, letting the cache determine its own heuristic expiration date.

This section describes the cache controlling headers. The next section, Section 7.10, describes how to assign different cache information to different content.

No-Cache and No-Store Headers

HTTP/1.1 offers several ways to mark an object uncachable. Technically, these uncachable pages should never be stored in a cache and, hence, never will get to the freshness calculation stage.

Here are a few HTTP headers that mark a document uncachable:

Pragma: no-cache
Cache-Control: no-cache
Cache-Control: no-store

RFC 2616 allows a cache to store a response that is marked “no-cache”; however, the cache needs to revalidate the response with the origin server before serving it. A response that is marked “no-store” forbids a cache from making a copy of the response. A cache should not store this response.

The Pragma: no-cache header is included in HTTP 1.1 for backward compatibility with HTTP 1.0+. It is technically valid and defined only for HTTP requests; ...