Frequently Asked Questions - Cache Management

Caching is the process through which requested content is copied to the edge of our network. A cache policy is established to provide the means through which new versions of cached content can be distributed.

Caching serves the following two purposes:

1. Data Delivery Speed: Caching is designed to speed up data delivery by bringing content closer to users.
2. Network & Server Load Reduction: Caching reduces the number of requests made to an origin server, since it allows requests for cached content to be fulfilled directly by our edge servers.

No. There are only two conditions under which content is cached on our network:

1. Requested Content: Content may be cached on our network as users request it. Eligible content is cached on the POP closest to the user. Learn more.
2. Load to Edge: This feature allows content to be pre-cached onto our network. This process will cache the asset identified in the load request across our worldwide network. Learn more.

No. The factors described below affect whether the requested content will be cached on our network.

Request Headers

Our edge servers will forward requests for new and expired content to an origin server. The origin server will respond with the requested content. This response will include header information. If those headers do not prohibit caching, then the requested content may be cached on the POP where the request originated.

Learn more.

HTTP Rules Engine

HTTP Rules Engine's Bypass Cache feature can be used to prevent certain types of requests from being cached. HTTP Rules Engine is only supported on our HTTP-based platforms.

The length of time that an asset will be cached is determined by the response headers returned by an origin server.

Our edge servers will apply a default cache policy of 7 days when the following conditions are true:

• An origin server does not include cache instructions.
• HTTP Rules Engine does not prohibit caching. HTTP Rules Engine is only supported on our HTTP-based platforms.

By default, content requested from CDN storage is cached by our edge servers for 7 days.

Learn more.

If cached content contains a Last-Modified and/or ETag directive, then our edge servers will verify that the origin server does not have a newer version. This process is known as revalidation. If those directives are not present, then the request will be forwarded to the origin server.

Learn more.

No. Content is cached after it has been delivered to the client.

Additional Information

When a request for an asset is served from an origin server, an edge server will forward that data to the client as it receives it. An asset will only be cached on an edge server when the entire asset has been received by that edge server. This ensures the quickest delivery of that asset to your client.

Due to the large size of the content served on the HTTP Large platform, it is quite possible for a client to cancel a request for CDN content before an edge server is able to retrieve the entire asset from the origin server. By default, the edge server will continue to download the requested asset until the entire asset has been received. Although the content will not be delivered to the client, the requested asset will be cached on that edge server. Keep in mind that this functionality can be overridden through HTTP Rules Engine by disabling the Complete Cache Fill feature. If you have not purchased HTTP Rules Engine, please contact your CDN account manager for more information.

Note: The HTTP Small platform behaves slightly different than the HTTP Large platform. An edge server will not continue to download content after a client has canceled their download. As a result, the requested content will not be cached. This behavior is by design due to the small file size of the content served on the HTTP Small platform.

Two ways to prevent content from being cached are:

• Customer Origin Server: For each type of request that should not be cached, configure your origin server to respond with one of the following directives:
  • Cache-Control: private
  • Cache-Control: no-store
  • Cache-Control: no-cache
  • Pragma: no-cache
• HTTP Rules Engine: Define the type of request that should not be cached and then enable the Bypass Cache feature.

HTTP requests that contain a query string can be cached differently. You can choose to cache these types of assets in one of three different ways. Each cache method is explained below.

Our edge servers will cache most response headers along with the asset (response body). However, there are a few response headers (e.g., Set-Cookie) that should not be cached.

The Set-Cookie response header is not cached on our network. This response header allows an origin server to provide cookie storage instructions to a browser. This type of data is not cached since it may be irrelevant to other customers. Instead, the Set-Cookie response header is included with the initial request for the asset, but all future requests for the cached version of this asset will not provide a cached version of this header.

Our recommendation for including cookie instructions with cached content is to:

1. Set a low max-age for the desired content (e.g., Cache-Control: max-age=0).
2. Configure your customer origin server to include the Last-Modified directive. This will cause our edge servers to revalidate each request for the cached asset using the If-Modified-Since request header.

Upon setting the above configuration, requests will be handled as described below.

• Same Version: If the asset has not been modified since it was cached, then the customer origin server will only provide new response headers including the Set-Cookie header. The following will be sent to the requester:
  • Cached response headers
  • New response headers provided by the customer origin server
  • Cached body (i.e., asset)
• New Version: If the asset has been updated, then the customer origin server will provide updated request headers and body (i.e., asset). The following will be sent to the requester:
  • New response headers provided by the customer origin server
  • New body (i.e., asset)

The response to a 5xx status code is not cached by our edge servers.

The response for content served from cache will include a header called "X-Cache."

Learn how to view response headers.

The length of time it takes for an updated version of your content to be served to your users depends on whether a cached version exists and its TTL.

Note: Use our purge feature to ensure that the latest version of your content is served. Learn more.

Step through the following questions to learn more about this process.

• Does the POP closest to the requester contain a cached version of the requested content?
  • Yes: Has its time to live (TTL) expired?
    • Yes: A new version will be requested from the origin server.
    • No: The cached version will be served to all users in the region served by that POP until its TTL expires.
  • No: The requested content will be retrieved from the origin server and delivered to the requester.

Learn more.

If you would like to distribute a new version of a previously cached asset, then you will need to purge the previous version from all of our edge servers. The purge feature allows you to perform this task by simply specifying the URL of the content that will be purged.

Learn more.

Purging

Purging an asset will remove the cached instance of that asset from all of our edge servers. It will not affect the original asset stored on an origin server.

Deleting

Deleting an asset will only eliminate it from that origin server. It does not affect content that has been previously cached on our network.

The recommended method for updating content is to:

1. Overwrite the desired content on the origin server through either SFTP or rsync.
2. Purge the desired cached content from our network.
   • If multiple files in the same directory require updating, consider purging the entire directory through the use of a wildcard. The following sample purge request will recursively purge a folder called "news."
     http://cdn.mydomain.com/news/*
   • If the same set of files require frequent purging, consider the following suggestions:
     • Cache Policy: A shorter cache policy (TTL) may reduce the need for frequent purges by allowing more frequent cache revalidations. Learn more.
     • Bulk Purge: The Purge/Load page allows multiple files to be purged.
       • Keep track of frequently purged URLs.
       • Simply copy and paste the desired URLs into the Bulk Purge option.
     • Consider using unique names for each new version. This practice eliminates the need to purge content after each update.

Yes. This feature is known as "load to edge." An asset can be loaded to all POPs from the Purge/Load page.

No. You may only cache a single asset at a time by loading a CDN or edge CNAME URL that points to it.

Our live streaming solutions implement a custom cache solution and do not support the load to edge feature.