Dec 14, 2017

The Cache-Control header can include a number of directives.

 If multiple directives are passed together, each is separated by a comma. If the directive takes an argument, it follows the directive separated by an equals sign.

Broadly, the directives break down into broad buckets around cacheability (should this object enter a cache?), expiration (how long should it stay in cache?), revalidation (how should the cache behave when an object has “expired”?) and a few others that control how caches should handle content.

The "public" response directive indicates that any cache MAY store the response, even if the response would normally be non-cacheable or cacheable only within a private cache.
The "private" response directive indicates that the response message is intended for a single user (eg. a browser cache) and MUST NOT be stored by a shared cache (like Cloudflare, or a corporate proxy).
The "no-store" response directive indicates that any cache (ie a client or proxy cache) MUST NOT store any part of either the immediate request or response.
The "max-age" response directive indicates that the response is to be considered stale after its age is greater than the specified number of seconds. Age is defined as the time in seconds since the asset was served from the origin. The seconds argument is an unquoted integer.
The "s-maxage" response directive indicates that, in shared caches, the maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header field.  The s-maxage directive also implies the semantics of the proxy-revalidate response directive.
The "no-cache" response directive indicates that the response MUST NOT be used to satisfy a subsequent request without successful validation on the origin server. This allows an origin server to prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to send stale responses.
The "must-revalidate" response directive indicates that once it has become stale, a cache (client or proxy) MUST NOT use the response to satisfy subsequent requests without successful validation on the origin server.
The "proxy-revalidate" response directive has the same meaning as the must-revalidate response directive, except that it does not apply to private client caches.
When present in an HTTP response, the stale-while-revalidate Cache-Control extension indicates that caches MAY serve the response in which it appears after it becomes stale, up to the indicated number of seconds since the object was originally retrieved.
The stale-if-error Cache-Control extension indicates that when an error is encountered, a cached stale response MAY be used to satisfy the request, regardless of other freshness information.
The "no-transform" response directive indicates that an intermediary (regardless of whether it implements a cache) MUST NOT transform the payload
Indicates to clients that the response body will not change over time. The resource, if unexpired, is unchanged on the server and therefore the client should not send a conditional revalidation for it (e.g. If-None-Match or If-Modified-Since) to check for updates, even when the user explicitly refreshes the page. This directive has no effect on public caches like Cloudflare, but does change browser behavior.