Caching creates a copy of the requested content on our edge servers. This dramatically reduces the distance that the data has to travel to fulfill all future requests.
Learn how to override this behavior.
By default, only GET requests that result in a 200 OK response are eligible to be cached.
This section does not apply to our live streaming solutions.
Our edge servers cache content according to the cache instructions provided by the origin server. If an origin server does not provide cache instructions, then it will be assigned a time to liveTime 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. (TTL) of 7 days (i.e., Cache-Control: max-age=604800). Content is considered freshIdentifies cached content that can be served directly by an edge server without requiring revalidation with an origin server. It also indicates that the cached content's TTL has not expired. until its TTL has expired.
Once the assetA file is the most commonly known example of an asset. Refers to any collection of data that is typically stored as a single unit on a storage unit (e.g., disk drive). An example of an asset that is not physically stored on a disk drive occurs when dynamically generated content is not cached. has been cached on a POP, all future requests from the region served by that POP will be served directly from that POP while the asset is fresh. Once the asset’s TTL has expired, then an edge server from that POP may revalidate the asset with the origin server. If the asset has not been modified, then the asset's TTL on that edge server will be updated to reflect the origin server's cache instructions or a default TTL of 7 days. Otherwise, a new version of the asset will be retrieved and cached on the edge server.
Rules Engine, which must be purchased separately, may be used to override the above behavior. For example, it can be configured to define a custom caching policy for certain types of requests.
Learn more.
An origin server can provide cache instructions for the requested content via response headersThis type of header describes the HTTP response provided by a server. Among their many uses, certain response headers may be used to define the cache policy for the requested content..
Our CDN origin servers (CDN storage) do not provide cache instructions. Therefore, a default TTL of 7 days is assigned to all content requested from CDN storage.
Revalidation is the process through which an edge server checks the origin server to find out whether a newer version of the requested cached content exists. If the origin server indicates that the requested content has not changed, then our edge servers will serve the cached content to the media player and then update its TTL according to the provided cache instructions.
Our edge servers can only perform a revalidation when the following conditions are true:
If either response tag is not found, then our edge servers will perform an unconditional GET request to the customer origin server.
User agent caching determines whether the requested asset will be cached by a user agent (e.g., web browser) and for how long. By default, this type of caching determines when a user agent (e.g., browser) will revalidate the cached asset with the edge server.
Clearing a web browser’s cache will override user agent caching.
The manner through which incomplete downloads are handled varies by platform.
If a client requests an asset that has not been previously cached on the corresponding POP, then an edge server will retrieve it from the origin server. The entire asset may then be cached on that edge server provided that its headers do not prohibit caching, regardless of whether the client performed an HTTP range request or aborted their download. By automatically retrieving and caching the entire asset, future requests for that asset will not require an edge server on that POP to download it again from your origin server while the asset is still fresh. This functionality reduces the load on the origin server and allows future requests to be served from cache. This ensures the speedy delivery of your content to your customers.
An asset will not be cached on an edge server until it receives the entire asset from the origin server. In other words, if a client aborts a download or performs an HTTP range request, then the asset will not be cached on the edge server. This should not be an issue, since small assets can be quickly downloaded from an origin server and HTTP range requests are typically performed for video content which should be hosted on the HTTP Large platform.
There are three cache layers for assetA file is the most commonly known example of an asset. Refers to any collection of data that is typically stored as a single unit on a storage unit (e.g., disk drive). An example of an asset that is not physically stored on a disk drive occurs when dynamically generated content is not cached.s routed using our ADN service, which are ADN Gateway, edge server, and user agent caching. A brief explanation for each one is provided below.
A user can clear a web browser’s cache.
As mentioned above, the caching mechanism for the ADN Gateway and edge servers is disabled by default. However, if your customer origin server assigns a TTL to a request, then our servers will forward the corresponding header information (i.e., Cache-Control and Expires) to the user agent that requested it.
Rules Engine, which must be purchased separately, may be used to override the above behavior. For example, it can be configured to allow caching for certain types of requests on the ADN platform.
Learn more about the Bypass Cache feature.
For detailed information on when content is cached, please refer to the Request topic.
The following information is only applicable for requests where CDN caching has been enabled:
An asset's TTL is determined by its response headers.
Edgecast CDN