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. Highwinds) while others provide serve stale as a feature you can turn on (e.g. MaxCDN).
Fastly and CDN77 are two 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
- = Yes
- = Sort of/partially
- = No
- = Extra costs
- = Unknown
|CDN||Free||Origin is unavailable||Origin serves error||Control via headers|
|Verizon Digital Media Services|
More info per CDN
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.
Incapsula supports the delivery of stale content in cases where the origin server is unresponsive. Incapsula 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.
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.
Verizon Digital Media Services
Verizon Digital Media Services (aka 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.
Tata can do serve stale but the customer needs the Tata support team to turn this on.
QUANTIL can configure the CDN to serve the stale content from the CDN edge servers in case the customer origin returns error responses of in case the origin is down or unresponsive. This is a backend feature: the customer cannot self-configure using the portal or API.
More CDN Guides