14.9.1 What is Cacheable
By default, a response is cacheable if the requirements of the request
method, request header fields, and the response status indicate that
it is cacheable. Section 13.4 summarizes these defaults for
cacheability. The following Cache-Control response directives allow an
origin server to override the default cacheability of a response:
public
Indicates that the response MAY be cached by any cache, even if it would normally be non-cacheable or cacheable only within a non- shared
cache. (See also Authorization, section 14.8, for additional details.)
private
Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache. This allows an
origin server to state that the specified parts of the
response are intended for only one user and are not a valid response for requests by other users. A private (non-shared) cache MAY
cache the response.
Note: This usage of the word private only controls where the response may be cached, and cannot ensure the privacy of the message
content. no-cache
If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request
without successful revalidation with the origin server. This allows an
origin server to prevent caching even by caches that have been
configured to return stale responses to client requests.
If the no-cache directive does specify one or more field-names, then a cache MAY use the response to satisfy a subsequent request,
subject to any other restrictions on caching. However, the specified
field-name(s) MUST NOT be sent in the response to a subsequent request
without successful revalidation with the origin server. This allows an
origin server to prevent the re-use of certain header fields in a
response, while still allowing caching of the rest of the response.
Note: Most HTTP/1.0 caches will not recognize or obey this directive.
14.9.2 What May be Stored by Caches
no-store
The purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information (for
example, on backup tapes). The no-store directive applies to the
entire message, and MAY be sent either in a response or in a request.
If sent in a request, a cache MUST NOT store any part of either this
request or any response to it. If sent in a response, a cache MUST NOT
store any part of either this response or the request that elicited
it. This directive applies to both non- shared and shared caches.
"MUST NOT store" in this context means that the cache MUST NOT
intentionally store the information in non-volatile storage, and MUST
make a best-effort attempt to remove the information from volatile
storage as promptly as possible after forwarding it.
Even when this directive is associated with a response, users might explicitly store such a response outside of the caching system
(e.g., with a "Save As" dialog). History buffers MAY store such
responses as part of their normal operation.
The purpose of this directive is to meet the stated requirements of certain users and service authors who are concerned about
accidental releases of information via unanticipated accesses to cache
data structures. While the use of this directive might improve privacy
in some cases, we caution that it is NOT in any way a reliable or
sufficient mechanism for ensuring privacy. In particular, malicious or
compromised caches might not recognize or obey this directive, and
communications networks might be vulnerable to eavesdropping.
