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.
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; ...