Content caching
In the CDN resource settings, you can enable content caching to temporarily store the file copies loaded from origins. There are two types of caching:
- On CDN servers located at the points of presence.
- In client browsers.
Caching on CDN servers
If CDN server caching is enabled for a resource, files are copied from origins to the server cache in the following cases:
- File the user has requested from the CDN resource is not yet cached on the responding sever.
- Lifetime of the file’s copy cached on the CDN server has expired, and the file stored on the origin has changed (otherwise, the lifetime is prolonged for the same duration).
- You prefetched files from origins to the CDN server cache in the CDN resource settings.
Cache lifetime
Until the cache lifetime expires, the CDN server returns a cached copy of the file to the clients without accessing origins.
Note
If end users do not request content for 36 hours, it is deleted from the CDN server cache regardless of the option settings.
You can choose one of two modes to define the cache lifetime:
| Mode | Description |
|---|---|
| Same as origin | The file is cached for the period specified in the origin's response to the request. The origin must add to the response the Cache-Control HTTP header with the max-age (specifies the cache lifetime in seconds) and public (allows file caching at any level) directives.If the origin responded with the 200, 201, 204, 206, 301, 302, 303, 304, 307, or 308 HTTP status code but the response includes no header meeting the above conditions, the file is cached for the period specified in the resource settings. Files from responses with other status codes are not cached if the header is missing. |
| Custom | The default cache lifetime is specified in the resource settings. It applies to all the origin responses with the 200, 206, 301, and 302 HTTP status codes. For any status code (regardless of whether it's listed above or not), you can separately specify the cache lifetime that takes precedence over the default time.If a status code is not included in the list and no cache lifetime is specified for it separately, a file from the response with such a code is not cached. |
Caching in browsers
If caching in browsers is enabled for a resource, CDN servers will add the Cache-Control header with the max-age (indicates the cache lifetime in seconds) and public (allows file caching at any level) directives to responses with the 200, 201, 204, 206, 301, 302, 303, 304, 307, and 308 HTTP status codes. The cache lifetime is specified in the resource settings.
Files from responses with other status codes are not cached.
Cookies and query parameters
Requests to the CDN server may contain the same path in the URI but different cookies (the Cookie HTTP header) and/or different query parameters.
In the resource settings, you can specify how to cache files that match such requests:
|
Argument |
Ignore disabled |
Ignore disabled |
|
Query parameters |
Uses the query string as part of the object key in the cache. Each unique set of parameters is a separate copy of the file. |
Ignores the query string. One copy of the file is saved for all options. |
|
Cookie |
Does not cache any responses to requests with the |
Caches responses to requests with the |
Cache prefetching
You can forcibly (manually) fetch individual files from sources into the CDN server cache before they are requested by clients. We recommend prefetching large files of 200 MB or more.
You can only prefetch the cache for content that is not yet available on CDN servers. To update cached files, you need to purge the cache first.
There are technical limits on cache prefetching.
Purging cache
You can delete cached file copies from CDN servers by purging the cache. This lets you quickly update in the CDN the content that has changed in the origins.
Warning
The number of file paths per cache purging request is limited.
You can purge cache either fully or partially. Partial purge is recommended: if you delete copies of all files from the cache, CDN servers will significantly increase the load on the origins, having to access them at every file request.
For partial purging, you can specify paths to individual files and folders. Each path must start with /.
Note
-
The
*wildcard character can only be used at the end of the path. If you specify*at the beginning or middle of a path, the cache for matching files will not be purged. -
If file segmentation is enabled for the resource, keep in mind that when you perform a selective cache purge for a specific file, the file is stored in parts across the CDN servers. Use one of the following options:
- Append the
*wildcard character to the file path, e.g.,/image/foobar.png*. - Specify a segment byte range using the
@bytes=<start>-<end>suffix, e.g.,/image/foobar.png@bytes=0-10485759, to clear the first 10 MB segment.
If you specify only the file path without
*or the@bytessuffix, the segmented file cache will not be cleared. - Append the
Examples of paths:
/image/foobar.png: An individual file./image/foo*: All files in the/image/folder with names starting withfoo./static/*: All files in the/static/folder.
If the file is cached based on the query parameters (that is, for each request with new parameters, a separate copy was saved), all copies of the file are deleted by default. To delete only specific copies, you need to explicitly specify their query parameters, e.g., /image/foo.png?id=12345.
Warning
If the CDN resource uses Vary headers (e.g., Vary: Accept-Encoding), you must add the * wildcard character to the end of the path when purging the cache to remove all possible cached versions of the files, e.g., /image/foobar.png*.
Use cases
- Enabling a blue-green and canary deployment of web service versions
- Publishing game updates using Yandex Cloud CDN