Show search and navigation.
By default, caching is disabled on the ADN platform.
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:
No. There are only two conditions under which content is cached on our network:
No. The factors described below affect whether the requested content will be cached on our network.
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.
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.
Number of Requests
By default, content may only be cached after a POP receives two requests for it.
Rules Engine's Bypass Cache feature can be used to prevent certain types of requests from being cached.
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:
Rules Engine does not prohibit caching.
By default, content requested from CDN storage is cached by our edge servers for 7 days.
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.
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.
Due to the amount of time it takes to deliver large files (e.g., ISO images, high-resolution images, software updates, etc.), a client may cancel a request before an edge server is able to retrieve the entire asset from the origin server. Use the Partial Cache Sharing feature to allow our edge servers to 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. If you have not purchased Rules Engine, please contact your CDN account manager for more information.
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.
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.
In this example, an edge CNAME called "secure.mydomain.com" points to:
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:
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.
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 ADN 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:
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.
This is the default mode for handling URLs that contain query strings (e.g., Asset.txt?Data=True). This mode will ignore query strings in the URL. It will only cache a single asset per URL, regardless of the presence of query strings.
This mode prevents requests containing query strings from being cached. All requests that contain query strings will be forwarded to the customer origin server.
This mode will cache an asset for each request made with a unique URL. A unique cache asset will be created by even the slightest variation in the query string.
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.
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.
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:
Upon setting the above configuration, requests will be handled as described below.
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.
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?
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.
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 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:
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.
Yes. This feature is known as "load to edge." An asset can be loaded to all POPs from the Purge/Load page.
Our live streaming solutions implement a custom cache solution and do not support the load to edge feature.
Yes. On-demand content may be cached using either a CDN or edge CNAME URL.
No. The recommended procedure for loading a new version of existing content is to: