Documentation

First Steps

Content Types

All content served through the CDN should be universal, public and static. Once obtained from the origin, it can remain stored in cache for a long period of time and will be served on-demand regardless of user and without authentication of any kind. However, these definitions are not absolute and depend heavily on context. For example:

  • Dynamically generated content requiring no on-demand invalidation (eg: image thumbnails) is considered static for caching purposes.
  • There are available mechanisms to allow indirect control over object access by the origins. These mechanisms may be used, for example, to help implement geographic restrictions on content delivery (see Secure URLs).
  • Purely dynamic content (eg: soft errors) may be served through the CDN with a short lifetime or skipping cache altogether (see Serving Content Using the CDN).

Serving Content Using the CDN

The CDN pulls content from the origin and serves it to end users over HTTP or HTTPS, prioritizing "hot" objects over infrequently accessed ones. This means an object is only obtained from the origin at user request and then remains cached for an indeterminate period of time. The higher the request rate to the object, the longer it remains in cache.

Every object has a limited lifetime and, upon expiration, may undergo revalidation. When next requested by a user, the CDN will try to re-obtain it from the origin. If the object has changed since last requested, it will be refetched. If it no longer exists, it will be removed from cache.

For this mechanism to work efficiently, the origin must always send a "Last-Modified" header. If this header is missing or invalid, the object will be refetched at every revalidation cycle.

Note: The "Last-Modified" header is also required for purging individual objects. This feature is available by request, with usage limits, if necessary.

By default, object lifetime is chosen by the CDN based on its configuration. However, it is possible to control it for each individual object using the "X-Cache-TTL" header (see Controlling Object Lifetime). Also, a standard "Cache-Control" header containing max-age=0, no-cache or private makes the object uncachable.

Mapping URLs to the Content Origin

To specify where to obtain the origin's content, it is necessary to define a persistent mapping between a CDN base address and an origin base address. These mappings are configured by the Stratus team at the client's request.

Each CDN client has its own unique identifier and may have multiple mappings for different base addresses, or multiple mappings for the same base address with different sets of options controlling its behavior.

Note: The CDN rejects query strings by default. But they can (optionally) be discarded before forwarding the request to the origin, or filtered based on a whitelist of known parameters.

As an example, let's see how "Example Corp" can serve static images from its corporate website using the CDN.

Example Corp's client identifier is "c123456" and static images are all under http://www.example.com/imgs, which has been configured by the Stratus team as the imgs mapping. This makes all of them available through the CDN under the following base address:

http://c123456.cdn.sapo.io/1/c123456/imgs/v1/8417951655dc1a0

Any object path appended to this base address will be forwarded to the origin. For example, requesting the following image file from the CDN...

http://c123456.cdn.sapo.io/1/c123456/imgs/v1/8417951655dc1a0/logo.png

...is the equivalent of requesting the same image directly from the company's website using this address:

http://www.example.com/imgs/logo.png

As previously mentioned, the objects remain cached for an indeterminate, possibly long, period of time. So, how to coerce the CDN into serving a new version immediately if the company decides to change, for example, its logo?

The solution for this lies in the "/v1/8417951655dc1a0" component of the base address. This component constitutes a version token that allows the origin to force an object update without changing the object's name at the source. By changing "v1" into "v2", the new URL will be interpreted as referring to a new, separate, object.

This change requires a corresponding update to the HMAC field. This field contains "8417951655dc1a0" for "v1" but for "v2" will contain something altogether different. The CDN uses the HMAC to make sure the URL was generated by the client (and not some malicious third-party), avoiding cache pollution from many copies of the same object: if the HMAC check fails, access is denied.

Note: The client can choose a different naming scheme for the version, limited to including alphanumeric characters, dots, dashes and/or underscores only.

Each mapping has a secret key known by the client. The HMAC then becomes the last 15 characters from the output of the following function:

HMAC_SHA1(secret key, version)

This mechanism is rather simple to implement in the most popular programming languages, as well as easy to automate in build or deployment processes. If required, the Stratus team has several code examples available to clients.