Last updated: February 20, 2017
Introduction to Serve Stale
Content is stale if it has expired in cache. CDNs don't hold objects in cache forever: an object has a TTL (Time To Live) and once the TTL is zero, the object has expired and is stale. The CDN must contact the origin first before sending the object to clients.
Imagine the CDN gets a request for
/images/logo.png and the image has expired in cache. The CDN tries to get fresh copy from origin but the origin is unavailable. What should the CDN do? Send a timeout error or serve the cached, stale object?
Serve Stale means the CDN serves an expired object from cache while the origin is unresponsive and/or returns an error. In most cases it's better for the user to get a good but expired/old/outdated response from the CDN than getting a timeout or other error response.
Some CDNs serve stale by default (e.g. StackPath) while others provide serve stale as a feature you can turn on (e.g. Tata Communications).
Fastly and CDN77 are two of the CDNs that support HTTP Cache-Control Extensions for Stale Content (RFC5861) which means you can control the CDN's stale content serving behaviour from headers the origin sends. For example,
Cache-Control: max-age=600, stale-while-revalidate=30 instructs the CDN to cache the object for 10 minutes and, at the end of that 10 minutes, serve stale for up to 30 seconds while new content is being fetched.
Serve Stale does not mean the same on all CDNs.
See the table below for an overview of the behaviour and options per CDN.
CDNs and Serve Stale
CDNs missing in this table? That is because we don't have the relevant info
= Sort of/partially
= Extra costs
More info per CDN
If "Ignore cache control" option is enabled, by default the CDN for Static Content serves stale content from cache by default in case the origin serves error, is down or unresponsive. VideoCDN does not have behaviour to serve stale content.
BaishanCloud supports the
stale-if-error headers from origin, enabling the customer to control the serve stale behaviour.
CacheFly CDN can honour the serve stale headers from origin. Customer must ask support to activate this. Furthermore, Cachefly support engineers can alter the behavior either with a rewrite of the incoming headers or with logic to preserve stale content longer than the default. Cachefly can also provide (at a cost) permanent cache that can be used to keep stale content indefinitely, and build behavior around that cache to meet the customer's retention needs.
By default, Cloudflare will not serve stale content if the edge server cannot get a response from the customer origin. Depending on what exactly happened, Cloudflare will serve one of their 52x responses, for example Error 522: Connection timed out or Error 521: Web server is down. View a full overview of possible 52x error responses.
Note: Cloudflare will serve stale responses from cache while the cache is validating/fetching the object from the origin. In this case, Cloudflare will serve the stale response with a
CF-Cache-Status: STALE header. Learn more about the various Cloudflare cache responses.
AWS Documentation: Origin Unavailable
Edgecast provides two relevant features: Stale content Delivery on Error and Stale While Revalidate. Both features are part of the Advanced Rules Engine package (extra costs apply).
- Stale Content Delivery on Error: when active, the CDN caches will serve stale content when an error occurs during a connection to an origin server (note: error responses served by the origin like 404 and 502 will be passed along to the client!)
- Stale While Revalidate: the customer can specify a length of time and select a time unit (e.g. seconds, minutes, hours, etc.) to allow stale content delivery.
Fastly can do it all. As a customer, you have full control over the stale content serving behaviour, either by way of the headers your origin sends or by using custom VCL code. Read the Fastly documentation Serving Stale Content to get detailed insight into how this all works at Fastly. Or, read the easier to consume blog post Stale-While-Revalidate, Stale-If-Error Available Today by Steve Souders on the Fastly blog.
More info in their Always Online article.
Imperva supports the delivery of stale content in cases where the origin server is unresponsive. Imperva will respect stale content for a duration of 2 to 24 hours based on the time passed since the resource was last updated. Frequent updates will result in a shorter stale period. Non-frequent updates will result in a longer stale period.
Kingsoft Cloud supports the
stale-if-error headers from origin, enabling the customer to control the serve stale behaviour. Customer can activate/configure this in the portal.
Tata can do serve stale but the customer needs the Tata support team to turn this on.
Tencent Cloud does not support the
stale-if-error headers from origin but customers can configure the CDN to serve stale content in the event the origin server returns a 5xx error. This can be configured in both the console and the API.
Share this page on Twitter
More CDN Guides