How to set status code TTL - CDN - Alibaba Cloud Documentation Center

When an Alibaba Cloud Content Delivery Network (CDN) point of presence (POP) fetches a resource from your origin server, the origin server returns a response status code. You can configure a cache duration for these status codes in CDN. When a client requests the same resource again, the CDN POP returns the status code directly without performing an origin fetch. This reduces the load on your origin server. When the cache duration for the status code expires, a new origin fetch is triggered.

Scenarios

You can configure status code TTL to specify the caching action that a POP performs when the origin server returns an abnormal status code.

Normally, when a POP retrieves a requested resource from the origin server and the origin server returns a 2xx status code, the resource is cached based on the default cache rules and priorities of Alibaba Cloud CDN and DCDN. If the origin server returns an abnormal status code, such as a non-2xx code, and you do not want the origin server to process every identical request, you can specify a cache duration for the status code. This allows POPs to cache the status code and return it directly to clients, which reduces the load on the origin server.

Use case

A client continuously tries to access File A, which has been deleted from the origin server. The POP does not have a cached copy of File A. All requests for File A are forwarded to the origin server, which returns a 4xx status code. This significantly increases the load on the origin server. If you configure the POP to cache 4xx status codes, the POP caches the 4xx status code after the first origin fetch. Within the preset cache duration, when the client requests File A again, the POP returns the 4xx status code directly without performing an origin fetch.

Cache rules for abnormal status codes

For status codes 204, 305, 404, 405, 414, 424, 429, 500, 501, 502, 503, and 504, the cache rules are as follows:
1. If the origin server returns a set-cookie response header, CDN does not cache the response.
2. If the origin server does not return a Set-Cookie response header, the response is cached based on the expiration time of the status code that you configure in the CDN console. For information about how multiple rules take effect, see the Priority of multiple rules section.
3. If the origin server does not return a Set-Cookie response header and you do not configure an expiration time for the status code in the CDN console, the response is cached based on the Pragma, Cache-Control, or Expires response header from the origin server.
4. If the origin server does not return a Set-Cookie, Pragma, Cache-Control, or Expires response header and you do not configure an expiration time for the status code in the CDN console, the response is cached for 1 second by default.
For status codes 302, 307, and 403, the cache rules are as follows:
1. If the origin server returns a set-cookie response header, CDN does not cache the response.
2. If the origin server does not return a Set-Cookie response header, the response is cached based on the expiration time of the status code that you configure in the CDN console. For information about how multiple rules take effect, see the Priority of multiple rules section.
3. If the origin server does not return a Set-Cookie response header and you do not configure an expiration time for the status code in the CDN console, the response is cached based on the Pragma, Cache-Control, or Expires response header from the origin server.
4. If the origin server does not return a Set-Cookie, Pragma, Cache-Control, or Expires response header and you do not configure an expiration time for the status code in the CDN console, the response is not cached.
For the 304 status code, CDN does not cache the response. You cannot set a cache duration for this status code.

For other abnormal status codes, such as 400, the cache rules are as follows:
1. If the origin server returns a set-cookie response header, CDN does not cache the response.
2. If the origin server does not return a Set-Cookie response header, the response is cached based on the expiration time of the status code that you configure in the CDN console. For information about how multiple rules take effect, see the Priority of multiple rules section.
3. In other scenarios, the response is not cached.
For requests that use range origin fetch, if a CDN POP receives a non-206 status code from the origin server, the CDN POP deletes the cached file shards. An origin fetch timeout does not cause the cached file shards to be deleted.
In a range origin fetch scenario, the origin server splits a large file into multiple smaller file shards and returns them to the CDN POP. For example, a file is split into 10 shards. The CDN POP has already cached five shards. When the POP requests the sixth shard, the origin server returns a 5xx status code. In this case, the five previously cached shards are deleted.

Priority of multiple rules

You can set multiple cache rules for status codes. If a request matches multiple rules, only one rule takes effect. The effective rule is determined as follows:

Evaluation order:
Rules are evaluated first by type (File Extension > Directory) and then by creation time (older > newer).
Priority of rules with different types: File Extension > Directory.
For example, a user request matches two rules that are configured for the 404 status code. The rule types are File Extension and Directory. The expiration time of the 404 status code is determined by the rule with the File Extension type. For a detailed example, see Configuration examples.
Priority of rules with the same type: Older > Newer (from top to bottom in the rule list).
For example, a user request matches two rules that are configured for the 404 status code. The rules are of the same type, which can be File Extension or Directory. The expiration time of the 404 status code is determined by the rule that was created first. For a detailed example, see Configuration examples.

Procedure

Log on to the CDN console.
In the left navigation pane, click Domain Names.
On the Domain Names page, find the target domain name and click Manage in the Actions column.
In the domain's navigation pane, click Cache.
Click the Status Code TTL tab.

Click Create Rule to configure the expiration time for a status code.

Type	Notes
Type	You can set this parameter to Directory or File Extension. Select a type as needed. Note Priority of rules with different types: File Extension > Directory. For more information, see Cache rules for abnormal status codes.
Object	If you select Directory as the type, the instructions are as follows: You can add only one directory at a time. Enter the full path of the directory. The path must start with a forward slash (/). For example, /directory/aaa. When you select File Extension as the type, the parameters are described as follows: Enter one or more file extensions. Separate multiple file extensions with commas (,). For example, `jpg,txt`. Note If you create rules for file extensions that are identical except for the case, the rule that is created later overwrites the rule that is created earlier. For example, after you create a rule for jpg,txt, you create another rule for JPG,TXT. The JPG,TXT rule overwrites the jpg,txt rule. If you want to create a rule for lowercase file extensions, create separate rules for txt and jpg. The rules are case-sensitive. You cannot use an asterisk (*) to match all file types.
Expire In	Specify the status codes that you want to cache and their cache durations. The maximum cache duration is three years. The unit is seconds. Follow these rules: Separate multiple status codes with commas (,). For 2xx and 3xx status codes, you can specify only individual status codes. You cannot use a blur match. For example, 201=10 is supported, but 2xx=12 is not supported. For 4xx and 5xx status codes, you can specify individual status codes or use a blur match. For example, both 401=10 and 4xx=12 are supported.
Honor Origin TTL	If you enable this feature and the origin server returns a cache policy header, such as Cache-Control and Pragma, the cache policy of the origin server takes precedence.
Ignore Origin No-Cache Header	If you enable this feature, CDN POPs ignore the following cache policy headers from the origin server. These headers indicate that the response should not be cached. Cache-Control: no-store Cache-Control: no-cache Cache-Control: max-age=0 Pragma: no-cache
Follow POP Cache Policy	If you enable this feature, the CDN POP returns the final effective cache policy to the client.
Force Revalidation	This parameter takes effect only when the cache duration is 0. The effects are as follows: Shutdown (default): If the time-to-live (TTL) for CDN is set to 0, the CDN nodes do not cache files. Each request must perform an origin fetch to retrieve content. Enabled: When the time-to-live for CDN/ is set to 0, files can be cached on CDN/ nodes, but each request requires an origin fetch to authenticate the cached content.

Click OK.
After you configure the expiration time for a status code, you can find the rule in the list on the Expire In tab. You can Modify or Delete the rule.

Configuration examples

Example 1: Directory rule
The following figure shows how to create a directory rule.
In the /directory/aaa directory, all 4xx status codes are cached for 10 seconds, and the 201 status code is cached for 15 seconds. Within these time ranges, POPs respond directly to access requests. After the cache duration expires, requests are redirected to the origin server.
Example 2: File extension rule
The following figure shows how to create a file extension rule.
For files with the .jpg or .txt extension, the 403 status code is cached for 10 seconds, and the 404 status code is cached for 15 seconds. Within these time ranges, POPs respond directly to access requests. After the cache duration expires, requests are redirected to the origin server.
Example 3: Priority of rules with different types
A directory rule and a file extension rule are created with different expiration times for status codes, as shown in the following figure.
A user requests http://example.com/directory/aaa/test.jpg. The resource is not cached on the POP. The POP requests the resource from the origin server, and the origin server returns a 404 status code. The request matches both the directory rule and the file extension rule. Because the rule priority is File Extension > Directory for rules of different types, the file extension rule takes effect. The actual cache duration for the 404 status code is 20 seconds.
Example 4: Priority of multiple rules of the same type
First, Directory Rule 1 is created for the /directory path. Then, Directory Rule 2 is created for the /directory/aaa path. The rules have different expiration times for status codes, as shown in the following figure.
A user requests http://example.com/directory/aaa/test.jpg. The resource is not cached on the POP. The POP requests the resource from the origin server, and the origin server returns a 404 status code. The request matches both directory rules. Because the rule priority is Older > Newer for rules of the same type, Directory Rule 1, which was created first, takes effect. The actual cache duration for the 404 status code is 15 seconds.

Related API

BatchSetCdnDomainConfig