When a CDN node fetches a resource from the origin server, the origin server returns a response status code. You can configure a cache duration for status codes in Alibaba Cloud CDN . When a client requests the same resource again, CDN returns the status code directly without triggering an origin fetch, which reduces the load on the origin server. When the configured cache duration expires, an origin fetch is triggered again.
Scenarios
Status code TTL applies mainly to scenarios in which the origin server returns abnormal status codes. It specifies the caching action that CDN nodes perform on these status codes.
Under normal circumstances, when a CDN node successfully fetches the requested resource from the origin server, that is, when the origin server returns a 2xx status code, the resource is cached based on Configure CDN cache expiration. If the origin server cannot respond quickly to all status codes (for example, non-2xx status codes) and you do not want all requests to be handled by the origin server, you can configure status code TTL so that CDN nodes return the status codes directly, which reduces the load on the origin server.
Typical scenario
File A has been deleted from the origin server, but clients keep requesting it. The CDN nodes do not cache file A, so 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 caching of 4xx status codes is configured on the CDN nodes, the CDN node caches the 4xx status code after the first origin fetch for file A. Within the configured cache duration, when a client requests file A again, the CDN node returns the 4xx status code directly without an origin fetch.
Cache rules for abnormal status codes
For the 204, 301, 305, 404, 405, 414, 424, 429, 500, 501, 502, 503, and 504 status codes, the cache rules are as follows:
If the origin server returns the
set-cookieresponse header, CDN does not cache the response.If the origin server does not return the Set-Cookie response header, the response is cached based on the status code TTL that is configured in the CDN console. If multiple rules are configured, see Priority of multiple rules for how the effective rule is determined.
If the origin server does not return the Set-Cookie response header and no status code TTL is configured in the CDN console, the response is cached based on the Pragma, Cache-Control, or Expires response header that is set by the origin server.
If the origin server does not return the Set-Cookie, Pragma, Cache-Control, or Expires response header and no status code TTL is configured in the CDN console, the response is cached for 1 second by default.
For the 302, 307, and 403 status codes, the cache rules are as follows:
If the origin server returns the
set-cookieresponse header, CDN does not cache the response.If the origin server does not return the Set-Cookie response header, the response is cached based on the status code TTL that is configured in the CDN console. If multiple rules are configured, see Priority of multiple rules for how the effective rule is determined.
If the origin server does not return the Set-Cookie response header and no status code TTL is configured in the CDN console, the response is cached based on the Pragma, Cache-Control, or Expires response header that is set by the origin server.
If the origin server does not return the Set-Cookie, Pragma, Cache-Control, or Expires response header and no status code TTL is configured in the CDN console, the response is not cached.
For the 304 status code, CDN does not cache the response, and the cache duration cannot be configured in any way.
For other abnormal status codes, such as the 400 status code, the cache rules are as follows:
If the origin server returns the
set-cookieresponse header, CDN does not cache the response.If the origin server does not return the Set-Cookie response header, the response is cached based on the status code TTL that is configured in the CDN console. If multiple rules are configured, see Priority of multiple rules for how the effective rule is determined.
In other scenarios, the response is not cached.
For requests that use range origin fetch, if a CDN node receives a non-206 status code from the origin server, the CDN node deletes the cached slices (an origin fetch timeout does not cause cached files to be deleted).
In a range origin fetch, the origin server splits a large file into multiple smaller slices and returns them to CDN nodes. For example, a file is split into 10 slices and a CDN node has cached five slices. When the node requests the sixth slice, the origin server returns a 5xx status code. In this case, all five slices that were previously cached are deleted.
Priority of multiple rules
You can configure multiple status code cache rules. If a request matches multiple rules at the same time, only one rule takes effect. The effective rule is determined as follows:
Evaluation order:
The rule type is evaluated first (file extension > directory), and then the rule creation time is evaluated (created earlier > created later).
Priority of rules of different types: file extension > directory.
For example, a request matches two rules at the same time (the 404 status code is configured in both rules), and the rule types are File Extension and Directory. In this case, the expiration time of the 404 status code is determined by the rule whose type is File Extension. For a specific example, see Configuration examples.
Priority of rules of the same type: created earlier > created later (from top to bottom in the rule list).
For example, a request matches two rules at the same time (the 404 status code is configured in both rules), and the rules are of the same type (both are of the File Extension type or both are of the Directory type). In this case, the expiration time of the 404 status code is determined by the rule that was created first. For a specific 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 and configure the status code TTL.
Parameter
Description
Type
Two types are supported: Directory and File Extension. Select a type based on your business requirements.
NotePriority of rules of different types: file extension > directory. For more information, see Cache rules for abnormal status codes.
Object
If you set the type to Directory, take note of the following items:
You can add only one directory at a time.
You can enter the complete path of the directory. The path must start with a forward slash (/), for example, /directory/aaa.
If you set the type to File Extension, take note of the following items:
You can enter one or more file extensions. Separate multiple file extensions with commas (,), for example,
jpg,txt.NoteIf the file extensions configured in different records are exactly the same and differ only in letter case, the record that is created later overwrites the record that is created earlier. For example, after you create a jpg,txt rule, creating another jpg,txt rule overwrites the previous jpg,txt record. In this case, if you need to configure a lowercase rule, you can create separate rules for txt and jpg. Configured rules are strictly case-sensitive when they take effect.
Asterisks (*) cannot be used to match all file types.
Expire In
The status codes to be cached and their cache durations. The maximum duration is three years. Unit: seconds. The configuration rules are as follows:
Separate multiple status codes with commas (,).
For 2xx and 3xx status codes, only exact configuration of individual status codes is supported. Fuzzy batch configuration is not supported. For example, 201=10 is supported, but 2xx=12 is not supported.
For 4xx and 5xx status codes, both exact configuration of individual status codes and fuzzy batch configuration are supported. For example, both 401=10 and 4xx=12 are supported.
Honor Origin TTL
If you turn on this switch and the origin server returns cache policy headers (including Cache-Control and Pragma), the cache policy returned by the origin server takes precedence.
Ignore Origin No-Cache Headers
If you turn on this switch, CDN nodes ignore the following cache policy headers returned by the origin server. All of these headers indicate that the content is not cached.
Cache-Control: no-store
Cache-Control: no-cache
Cache-Control: max-age=0
Pragma: no-cache
Clients Follow the CDN Cache Policy
If you turn on this switch, CDN nodes return the cache policy that finally takes effect to clients.
Force Content Revalidation
This parameter takes effect only when the cache expiration time is set to 0. The effects are as follows:
Turned off (default): If the cache expiration time of CDN is set to 0, files are not cached on CDN nodes, and each request must trigger an origin fetch to obtain the content.
Turned on: If the cache expiration time of CDN is set to 0, files can be cached on CDN nodes, and each request must trigger an origin fetch to revalidate the cached content.
Click OK to complete the configuration.
After the status code TTL is configured, you can Modify or Delete the current configuration in the Expire In list.
Configuration examples
Example 1: a directory type rule
Create a directory type rule, as shown in the following example:
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 durations, CDN nodes respond to the corresponding requests directly. After the durations expire, an origin fetch is triggered.
Example 2: a file extension type rule
Create a file extension type rule, as shown in the following example:
For files whose extension is .jpg or .txt, the 403 status code is cached for 10 seconds, and the 404 status code is cached for 15 seconds. Within these durations, CDN nodes respond to the corresponding requests directly. After the durations expire, an origin fetch is triggered.
Example 3: priority of rules of different types
A directory type rule and a file extension type rule are created, and different status code expiration times are configured, as shown in the following example:
A user requests
http://example.com/directory/aaa/test.jpg. The resource is not cached on the CDN node, so the CDN node requests the resource from the origin server, which returns the 404 status code. The request matches both the directory type rule and the file extension type rule. Because rules of different types take effect in the order of file extension > directory, the file extension type rule takes effect, and the actual cache duration of the 404 status code is 20 seconds.Example 4: priority of multiple rules of the same type
Directory type rule 1 is created first and matches the address /directory. Then, directory type rule 2 is created and matches the address /directory/aaa. Different status code expiration times are configured, as shown in the following example:
A user requests
http://example.com/directory/aaa/test.jpg. The resource is not cached on the CDN node, so the CDN node requests the resource from the origin server, which returns the 404 status code. The request matches both directory type rules. Because rules of the same type take effect in the order of created earlier > created later, directory type rule 1, which was created first, takes effect, and the actual cache duration of the 404 status code is 15 seconds.Example 5: resolve the issue that a 301 redirect is persistently cached
A CDN-accelerated domain name continuously returns a 301 redirect to another domain name, but the origin server no longer returns the redirect when it is accessed directly (bypassing CDN). In this case, you can add a rule in Status Code TTL, set the status code to
301and the cache duration to0(that is, 301=0), so that CDN nodes no longer cache 301 responses. After the configuration is complete, submit a refresh task for the URL to refresh the CDN cache, clear the cached 301 responses, and make the rule take effect immediately. Then, clear the local browser cache and access the URL again to verify the result.