CDN:Configure CDN cache expiration time

By configuring cache expiration time rules, you can precisely control how long resources are cached on POPs (points of presence) to balance content updates, access performance, and origin-fetch costs. This document describes how cache rules work, how to configure and verify them, and provides troubleshooting steps and best practices.

How it works

When a request reaches a POP, the system uses the following decision flow to determine whether to serve a cached copy or fetch the latest content from the origin server.

1. Do not cache resources: When the origin server responds with pragma:no-cache, cache-control:no-cache (or no-store, or max-age=0), the POP follows the origin's policy and does not cache the resource.

2. Follow console cache rules: If you have configured rules for a specific directory or file extension in the console, and the origin server does not send the "do not cache" headers mentioned above, the console cache rule takes precedence.

   • Priority logic when multiple console cache rules match:

     Scenario	Logic	Example
     Different weight	The rule with the higher Weight value (1-99) takes precedence.	If Rule A (for the /image/ directory, Weight 50) and Rule B (for the .jpg extension, Weight 90) both match image/a.jpg, Rule B is applied.
     Same weight	The rule that was created first takes precedence.	If you configure a directory rule (/static/) and a file extension rule (.js) with the same Weight of 60, and the directory rule was created before the extension rule, /static/app.js will match the directory rule.

   • Once a request matches a cache rule, no other rules are checked.

   • By default, if the origin server responds with Pragma: no-cache or Cache-Control: no-cache/no-store/max-age=0, the POP does not cache the resource. To force caching, select Ignore Origin No-cache Header when configuring a cache rule in the console.

3. CDN follows the origin server cache policy: If a request does not match any console rules, or if the matched rule has Honor Origin TTL enabled, the CDN honors the HTTP response headers from the origin server. The priority of these headers is, from highest to lowest: cache-control > expires > last-modified > ETag.

   Response header	How it is handled	Example
   Cache-Control	The s-maxage directive is prioritized for cache duration, followed by max-age.	s-maxage=86400, max-age=3600
   Expires	Specifies the expiration date and time. This is used only if no Cache-Control header is present.	Expires: Wed, 21 Oct 2025 07:28:00 GMT
   Last-Modified	Last-Modified is a timestamp that indicates when the resource was last modified. The cache duration is calculated as follows: (Current Time - Last-Modified) * 0.1, with the resulting duration clamped to a range of 10 to 3,600 seconds.	Last-Modified: Wed, 21 Oct 2023 07:28:00 GMT
   ETag	An ETag is a unique identifier generated by the server for a specific version of a resource, typically a hash value or version number. By default, resources with an ETag are cached for 10 seconds.	ETag: "abc123"

4. No-cache policy: If a request does not match any console cache rules and the origin server returns no cache-related response headers (such as Cache-Control), the POP does not cache the resource.

Procedure

Make rule changes take effect immediately

New or modified rules apply only to newly cached resources. Resources that were cached before the change will continue to use the old cache policy until they expire.

To apply new rules across the entire network immediately, you must manually clear the existing cache. If you change a rule, refresh the cached content by using the Purge resource feature. If you add a new rule, pre-populate the cache by using the Prefetch resource feature.

Verify the configuration

After configuration, you can use the curl command or browser developer tools to inspect the HTTP response headers of a resource to verify that caching is working as expected.

1. Run the verification command

Run the following command in your terminal to test the configuration.

curl -I "https://your.domain.com/path/to/file.jpg"

2. Interpret key response headers

Best practices

• Use versioned filenames (recommended): When updating a static resource like style.css, use a new filename with a version or hash value, such as style-v2.css or style-a1b2c3d.css, and update the reference in your HTML. This method does not require a manual cache refresh and ensures users get the latest content immediately. This is the recommended way to manage cache updates.

• Separate dynamic and static assets: Use different domains or directory paths for dynamic and static resources. Configure separate, high-weight cache rules for each resource type to avoid policy conflicts. For example, set a long cache duration for all resources under the /static/ directory and set no-cache for resources under the /api/ directory.

• Use the browser cache: Enable Follow POP Cache Policy to reduce repeated requests to POPs, which improves loading speed and saves traffic.

• Avoid setting the cache duration too short: An overly short cache duration leads to frequent origin requests, which negates the benefits of acceleration and increases your origin server's traffic and costs.

• Avoid setting the cache duration too long: An overly long cache duration can prevent clients from receiving timely data updates. For content that needs frequent updates, use the cache refresh feature or versioned filenames.

HTTP cache control mechanisms

The HTTP protocol defines three types of headers to implement cache control.

1. Expiration time validation

   When a server sends a resource, it can include an expiration time in the response. Before this time, the resource (cached copy) is considered fresh. After this time, it is considered stale.

   In HTTP, the following headers are commonly used to control cache expiration:

   Header name	Protocol version	Function	Example value	Type
   Pragma	HTTP/1.0	Pragma is used to indicate whether content should be cached. The value is typically no-cache. It is often used for compatibility with servers that only support HTTP/1.0.	Pragma:no-cache	Request/Response
   Expires	HTTP/1.0	The Expires response header contains a date/time after which the cached content will be considered stale. An invalid date, such as `0`, indicates that the resource is already expired.	Expires: Wed, 21 Oct 2022 07:28:00 GMT	Response
   Cache-Control	HTTP/1.1	The Cache-Control response header can be set with different directives for flexible cache control. It is the primary header used by modern clients (like browsers) to control caching.	The following three examples mean the file should not be cached: - Cache-Control:no-cache - Cache-Control:no-store - Cache-Control:max-age=0 An example indicating a cache validity of 1 hour: Cache-Control:max-age=3600	Request/Response

2. Resource tag validation

   When a client requests a resource, the server can include a resource tag (such as an `ETag`) in the response. The client then stores this tag. For subsequent requests for the same resource, the client sends the tag back to the server. If the tag matches the server's current version, the server responds with a `304 Not Modified` status, telling the client to use its cached copy. If the tags do not match, the server sends the full, updated resource.

   In HTTP, the following headers are commonly used to control cache versions:

   Header name	Protocol version	Function	Example value	Type
   Last-Modified	HTTP/1.0	Last-Modified indicates the last modification time of the resource.	Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT	Response
   ETag	HTTP/1.1	ETag provides a unique identifier for a specific version of a resource. Comparing ETag values can determine if a resource has changed. If it has not, the origin server does not need to send a full response.	ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"	Response

3. Content negotiation

   Caching software uses a key to index cached objects. In HTTP/1.0, this key was typically the resource URL. However, different resources can exist at the same URL. To distinguish them, more information is needed from the client, such as Accept-Language and Accept-Charset headers. To support this content negotiation, HTTP/1.1 introduced the Vary header in the response, which lists the request headers that are used for content negotiation.

   The `Vary` HTTP header is the mechanism for this. It tells caches which request headers to check when determining whether a cached response can be used.

   Header name	Protocol version	Description	Example value	Type
   Vary	HTTP/1.1	Common examples: - Server specifies: <br> Vary: Accept-Encoding<br> This tells the receiver (e.g., a POP) to cache two versions of the resource (compressed and uncompressed). When a client requests the resource, older browsers can get the uncompressed version for compatibility, while modern browsers get the compressed version to reduce data transfer and traffic. - Server specifies: <br> Vary: User-Agent<br> This is used to identify the browser type and tells the receiver (e.g., a POP) to cache different versions of the resource based on the browser type.	Vary: Accept-Encoding Vary: Accept-Encoding,User-Agent	Response

FAQ

• FAQ about caching

• What is the mechanism for clearing the cache?

• Increase the cache hit ratios of Alibaba Cloud CDN

• How do I configure POPs not to cache resources but to retrieve resources from origin servers?

• How can I configure the CDN to cache multiple representations of a resource for the same URL (e.g., compressed vs. uncompressed)?