Expiry time is a time stamp linked to each file accessed over the cdn. It is the amount of time, in seconds, before a cached file is re-validated with the origin server. This document explains how to control it.

How caching and re-validation work

Re-validation occurs after that number of seconds has passed since the last re-validation. It involves initiating a GET request between the cdn and the origin server. When the headers are returned from the GET request, the cdn will check the Last-Modified, Content-Length and ETag headers and compare them with the cached values. If any one of them has changed, the GET request continues to download the body and replaces the cached version. If the headers have not changed, the GET request is cancelled (before the body is downloaded) and the old cached file is considered re-validated, because it has not changed. In this case, the GET request acts more like a HEAD request, since the body is not transferred.

Expiry times

By default, the expiry times used on your content are taken from the Cache-Control or Expires header returned from the initial caching request to the origin server. If the origin server does not return a Cache-Control or Expires header, then the expiry time is taken from the “Default Values”, which includes provision for setting a different expiry time based on the response status code.

Origin configuration

Cache-Control header is the best way to manage the caching policy on your files. This is because you are in total control of the caching policy, which means that when using multiple cdns or changing cdn provider, the cache policy does not need to be duplicated for each cdn.

Configuring the Cache-Control header is your responsibility, as it is an origin server setting. Individual configurations will vary greatly, so we have provided links for the most relevant http servers

nginx – http://nginx.org/en/docs/http/ngx_http_headers_module.html

Apache – http://httpd.apache.org/docs/current/mod/mod_expires.html

IIS – https://www.iis.net/configreference/system.webserver/staticcontent/clientcache

Recommended settings

Static content

Description: Content which rarely changes, such as images, css & javascript, non-live video files (including hls/segmented vod types), software downloads
Caching policy: Between 1 and 7 days
Example: Cache-Control: public, max-age=86400

Dynamic content

Description: Content which constantly changes, such as server-side generated web pages which respond differently to each user
Caching policy: do not cache
Example: Cache-Control: no-cache

HTTP-Live streaming

Description: Live streaming using HLS, DASH, HDS, Smooth Streaming. Where there is a playlist or manifest as well as video segments.
Caching policy: Cache playlists & manifests for only a few seconds, since they are constantly changing. Cache video segments for as long as likely to still need to be accessed by clients
Example: (manifest) Cache-Control: public, max-age=1
Example: (video segment) Cache-Control: public, max-age=3600

Manual expiry

Manual expiry is available through the control panel or the api. A manual expiry differs from re-validation in that the cached file is completely deleted. On the next request for the expired file, the file will appear as a new file to the cdn and it will proceed to cache it again from scratch.