Cache-Control HTTP Headers

Although the Expires header is useful, it's still somewhat limited; there are many situations where content is cacheable, but the HTTP/1.0 protocol lacks methods of telling caches what it is, or how to work with it. HTTP/1.1 introduces a new class of headers, the Cache-Control response headers, which allow web publishers to define how pages should be handled by caches. They can be broken down into the following general categories:

• Restrictions on what are cacheable; these may only be imposed by the origin server.
• Restrictions on what may be stored by a cache; these may be imposed by either the origin server or the user agent.
• Modifications of the basic expiration mechanism; these may be imposed by either the origin server or the user agent.
• Controls over cache revalidation and reload; these may only be imposed by a user agent.
• Control over transformation of entities.
• Extensions to the caching system. 

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. The following Cache-Control 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. For instance, if your pages are authenticated, this directive makes them cacheable.

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.

no-cache

In general, this directive forces caches (both proxy and browser) to submit the request to the origin server for validation before releasing a cached copy, every time. This is useful to assure that authentication is respected (in combination with 

public), or to maintain rigid object freshness, without sacrificing all the benefits of caching. Technically speaking, if the no-cache directive does not specify a field-name, then a cache can 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 a response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-names must not be sent in the response to a subsequent request without 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 does not recognize or obey this directive. 

What May be Stored by Caches? 

no-store

The purpose of this directive is to prevent the inadvertent release or retention of sensitive information. This 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 response or the request that elicited it. "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. In general, 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. 

Modifications of the Basic Expiration Mechanism 

The expiration time of an entity may be specified by the origin server using the Expires header field. Alternatively, it may be specified using the max-age directive in a response. When the max-age cache-control directive is present in a cached response, the response is stale if its current age is greater than the age value given at the time of a new request for that resource. The max-age directive on a response implies that the response is cacheable (i.e. "public") unless some other, more restrictive cache directive is also present. If a response includes both an Expires and a max-age directive, the latter overrides the former header, even if the Expires header is more restrictive. This rule allows an origin server to provide, for a given response, a longer expiration time to an HTTP/1.1 cache than to an HTTP/1.0 cache. This might be useful if certain HTTP/1.0 caches improperly calculate ages or expiration times, perhaps due to desynchronized clocks. 

max-age = [seconds]

Specifies the maximum amount of time that an object will be considered fresh. Similar to 

Expires, this directive allows more flexibility. [seconds] is the number of seconds from the time of the request you wish the object to be fresh for.

s-maxage = [seconds]

Similar to 

max-age, except that it only applies to proxy (shared) caches. 

Cache Revalidation and Reload Controls 

Sometimes a user agent might want or need to insist that a cache revalidate its cache entry with the origin server (and not just with the next cache along the path to the origin server), or to reload its cache entry from the origin server. End-to-end revalidation might be necessary if either the cache or the origin server has overestimated the expiration time of the cached response. End-to-end reload may be necessary if the cache entry has become corrupted for some reason. 

must-revalidate

Tells caches that they must obey any freshness information you give them about an object. The HTTP allows caches to take liberties with the freshness of objects; by specifying this header, you 're telling the cache that you want it to strictly follow your rules.

proxy-revalidate

Similar to 

must-revalidate, except that it only applies to proxy caches. 

For example:

Cache-Control: max-age=3600, must-revalidate

For a more in-depth analysis of the Cache-Control directive's options, refer to the excellent documentation provided in the HTTP/1.1 draft specification (RFC 2616, Sections 13.1.3, 14.9).