Cache Management Frequently Asked Questions

Caching refers to the process through which content is copied to the edge of our network. By default, this occurs after the second eligible request for that content in the same region.

A caching policy may be defined to determine how long cached content may be served before checking for a new version.

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: By default, content will be cached after a POP receives two eligible requests for it.

   Requests are always directed to the POP closest to the user. Content will be cached on that POP.

2. Load to Edge: This feature instructs all of our POPs to manually cache an asset.

   Learn more.

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

HTTP Method

By default, only GETThis popular request method is used to retrieve information from a server. A GET request informs the server that the asset at the requested URL should be delivered to the requester. requests may be cached. All other HTTP methods are proxied to the origin server.

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.

Number of Requests

By default, content may only be cached after a POP receives two requests for it.

Rules Engine

Rules Engine's Bypass Cache feature can be used to prevent certain types of requests from being cached.

Response

By default, only requests that result in a 200 OK response are eligible to be cached.

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.

• Rules Engine does not prohibit caching.

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

Learn more.

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

By default, content is only cached after a POP receives two requests for it.

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 may only be cached on an edge server after the entire asset has been received by that edge server. This ensures the quickest delivery of that asset to your client.

HTTP and HTTPS requests are cached separately.

Purging is scheme-independent. This means that a purge request will purge content cached for both HTTP and HTTPS requests.

Example:

In this example, an edge CNAME called "secure.mydomain.com" points to:

• CDN Storage

A unique cache-keyA relative path that uniquely identifies an asset for the purpose of caching. Our edge servers use this relative path when checking for cached content and when caching content. By default, a cache-key will not contain query string parameters. will be generated for the following two requests:

The response may vary by scheme (i.e., http vs. https), even though both of the above URLs point to the same file (i.e., news.html).

Caching improves data delivery performance when cached content will be served multiple times.

Content that meets the following guidelines should be cached:

• Infrequently updated static content (e.g., CSS, JS, HTML, etc.)

• Popular content

  Popular content should be cached even if it is being frequently updated (e.g., 10 - 30 seconds). Set a caching policy that balances performance with the need to deliver the latest version of the requested content.

  Learn more.

Caching sensitive information (e.g., user account credentials and credit card information) is strongly discouraged for security reasons and legal implications. Consider using Rules Engine to prevent sensitive information from being cached.

Certain types of dynamic content (e.g., user account credentials, credit card information, account balances, session data, etc.) will not derive a performance benefit from caching, since it is specific to a user's session. Consider delivering dynamic content via the CAN platform.
Learn more.

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
• 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.

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.

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

Learn how to view response headers.

By default, caching is only enabled for 200 OK responses. However, this behavior may be overridden by Rules Engine's Set Cacheable Status Codes feature.

Learn more.

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 or invalid for subsequent requests. 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 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 time to live (TTLTime to Live. Refers to the amount of time that a cached asset is still considered fresh. Our edge servers will continue to serve a cached version of an asset while its TTL has not expired. An asset's TTL is calculated by the Cache-Control and Expires headers associated with the response sent by the origin server.).

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 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, but it won't affect the original asset stored on an origin server. A request for purged content will be treated as a request for new content. In other words, it will follow the standard workflow through which content is cached on our network.

Deleting

Deleting an asset from an origin server does not affect content that has been previously cached on our network. Requests for deleted content will be served via the CDN until the asset is either purged or the asset's TTLTime to Live. Refers to the amount of time that a cached asset is still considered fresh. Our edge servers will continue to serve a cached version of an asset while its TTL has not expired. An asset's TTL is calculated by the Cache-Control and Expires headers associated with the response sent by the origin server. expires.

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 (TTLTime to Live. Refers to the amount of time that a cached asset is still considered fresh. Our edge servers will continue to serve a cached version of an asset while its TTL has not expired. An asset's TTL is calculated by the Cache-Control and Expires headers associated with the response sent by the origin server.) may reduce the need for frequent purges by allowing more frequent cache revalidationRefers to the process that occurs when a request for stale content requires that our edge servers check for a new version of the requested content on the origin server.s.

       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.

Alternatively, load requests may be submitted via our REST API. Create a script that submits a load request for each desired file.
Learn more.

No. The recommended procedure for loading a new version of existing content is to:

1. Upload the new version to CDN storage or a customer origin server.
2. Purge the old version.
3. Load the file.

• Content Delivery

  • CAN
  • IPv6
  • Cache Management
  • Rules Engine

• Security

  • CDN Security
  • TCC Security
  • Token-Based Authentication
  • Web Application Firewall (WAF)
• Raw Logs
• Storage