Enabling Origin Cache-Control with Cloudflare Page Rules

Learn how Cloudflare interprets Cache-Control headers set at your origin server when the Origin Cache-Control feature is enabled via a Cloudflare Page Rule.


Overview

Cache-Control headers are one-way administrators can tell Cloudflare how to handle content your origin server. This article explains how Cloudflare makes caching decisions based on two phases, request and response, and the options you have for setting cache-control directives at your origin server. 

Request Phase

In the request phase, the client request URL is matched against a list of cacheable file extensions. If the request matches an extension on this list, Cloudflare serves the resource from cache if present. If the content is stale in the Cloudflare cache, Cloudflare attempts to revalidate the content with the origin before serving the response to the client.

It is possible to modify what Cloudflare deems cacheable via the Cache Level setting in the Cloudflare Page Rule app. 

page_rules_origin_cache_control.png

To learn more about creating Page Rules, refer to our Page Rules tutorial.

As an example, Cache Everything causes the extension check to be skipped, and all content will be treated as cacheable. Refer to Cloudflare's guide on how to use the Cache Everything setting.

Response Phase

If Cloudflare deems a request cacheable, we first examine our caches in multiple network locations for content. If the resource is not present in cache, Cloudflare will make a request to your origin server to fill our cache. The response is then sent to the client who initiated the request.

At this point, our cache logic examines the HTTP response received from your origin server.

Based on how Cloudflare interprets request headers, the response will either be deemed cacheable and written to disk (to be used for the next request for the same resource) or deemed un-cacheable (resulting in the next request missing cache and repeating this flow).


Set cache-control directives

The Cache-Control header can include a number of directives. If multiple directives are passed together, each is separated by a comma.

For more information about cache-control directives at origin servers, refer to the Mozilla Cache-Control documentation.

If the directive takes an argument, it follows the directive separated by an equal sign.  For example:

max-age=86400

These directives break down into groupings as follows:

Cacheability - should this resource enter a cache?

public
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.
private
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).
no-store
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.

Expiration - how long should this resource stay in the cache?

max-age=seconds
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 server. The seconds argument is an unquoted integer.
Cloudflare respects whichever value is higher: the Browser Cache TTL in Cloudflare or the max-age header.
s-maxage=seconds
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.  Browsers ignore s-maxage.
no-cache
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.
Simultaneously specify a Cloudflare Edge Cache TTL different than a browser’s cache TTL respectively via the s-maxage and max-age Cache-Control headers.  
In addition to setting the parameters below, make sure the HTTP Expires header is set in your origin server to use the Greenwich Mean Time (GMT) format as stipulated in RFC 2616.

Revalidation - how should the cache behave when a resource has expired?

must-revalidate
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.
proxy-revalidate
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.
stale-while-revalidate=seconds
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 resource expired.
If Always Online is enabled, then the stale-while-revalidate and stale-if-error directive will be ignored.
stale-if-error=seconds
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 stale-if-error directive will be ignored if Always Online is enabled or if an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive) is passed.

Other

no-transform
The "no-transform" response directive indicates that an intermediary (regardless of whether it implements a cache) MUST NOT transform the payload
immutable
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.

Examples

For more information about cache-control directives at origin servers, refer to the Mozilla Cache-Control documentation.

Not finding what you need?

95% of questions can be answered using the search tool. This is the quickest way to get a response.

Powered by Zendesk