DCDN points of presence (POPs) fetch resources from an origin server, and the origin server returns a response with an HTTP status code. You can configure a Time-to-Live (TTL) for these status codes on Alibaba Cloud DCDN. When a client requests the same resource again, DCDN returns the status code instead of redirecting the request to the origin server, which reduces the load on the origin server. After the TTL expires, requests are redirected to the origin server.
Scenarios
You can configure the expiration time of status codes to specify how DCDN POPs cache responses when your origin server returns an error status code.
Normally, when a DCDN POP retrieves a resource from the origin server and the origin server returns a 2xx status code, DCDN handles the request based on the Default cache rules and priorities of Alibaba Cloud CDN and DCDN. If your origin server cannot quickly respond to all requests, such as those that result in non-2xx status codes, you can specify a time-to-live (TTL) for these HTTP status codes. Then, DCDN POPs can directly return the cached status codes in response to requests. This reduces the load on the origin server.
Typical scenario
File A is deleted from the origin server, but clients continue to access it. The DCDN POP does not have File A cached. All requests are forwarded to the origin server, which returns a 4xx status code. This increases the load on the origin server. If you configure caching for 4xx status codes, the DCDN POP caches the 4xx status code after the first origin fetch. During the cache duration, when a client requests File A again, the DCDN POP directly returns the 4xx status code without an origin fetch.
Cache rules for HTTP status codes
The following figure shows the cache rules for HTTP status codes 204, 305, 400, 403, 404, 405, 414, 500, 501, 502, 503, and 504.
If requests are processed by the range origin fetch feature, the following cache rules apply:
For HTTP status codes other than 200 and 206, such as 204, 305, 400, 403, 404, 405, 414, 500, 501, 502, 503, and 504, resources are not cached.
For HTTP status codes 200 and 206, resources are cached based on the cache rules that are described in Alibaba Cloud CDN/DCDN default cache rules and priorities.
An HTTP 5xx status code allows the POPs to remove cached file chunks. If origin fetch times out, the file chunks are not removed.
NoteIf you enable the range origin fetch feature, origin servers divide a large file into chunks before the file is returned to POPs. For example, a file is divided into 10 chunks, 5 of which are cached on POPs. When a user requests the 6th chunk, the origin server returns an HTTP 5xx status code, and the POPs remove the 5 chunks that are cached.
If requests are not processed by Range origin fetch, the following cache rules apply:
If an origin server returns the
set-cookieresponse header, the POPs do not cache the retrieved resource.If the origin server does not return the
Set-Cookieresponse header, the retrieved resource is cached based on the cache rules that are configured in the Alibaba Cloud CDN console. For more information, see How cache rules are applied.If the origin server does not return the
Set-Cookieresponse header and no cache rules are configured in the CDN console, the retrieved resource is processed based on the directive of thePragma,Cache-Control, orExpiresresponse header.If the origin server does not return the
Set-Cookie,Pragma,Cache-Control, orExpiresresponse header and no cache rules are configured in the CDN console, the retrieved resource is cached for 1 second.
For HTTP 303, 304, 401, 407, 600, and 601 status codes, resources are not cached.
How multiple rules take effect
You can set multiple cache rules for status codes. If a request matches multiple rules, only one rule takes effect. The rule that takes effect is determined as follows:
Evaluation order:
The rule type is evaluated first (File Extension > Directory), and then the creation time is evaluated (earlier created > later created).
Priority of different rule types: File Extension > Directory.
For example, if a user request matches two rules (both configured for the 404 status code) with different rule types, File Extension and Directory, the expiration time for the 404 status code is determined by the rule of the File Extension type. For a detailed example, see Configuration examples.
Priority of same-type rules: Earlier created > Later created (from top to bottom in the rule list).
For example, if a user request matches two rules (both configured for the 404 status code) with the same rule type (both are File Extension or both are Directory), the expiration time for 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 DCDN console.
In the left-side navigation pane, click Domain Names.
On the Domain Names page, find the domain name that you want to manage and click Configure in the Actions column.
In the left-side navigation tree of the domain name, click Caching.
Click the Expiration Time Of Status Code tab.
Click Add to configure the expiration time of status codes.
Type
Notes
Type
Select Directory or File Extension as needed.
NotePriority of different rule types: File Extension > Directory. For more information, see How multiple rules take effect.
Address
If you set Type to Directory, note the following:
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.
If you set Type to File Extension, note the following:
Enter one or more file extensions. Separate multiple file extensions with commas (,). For example,
jpg,txt.NoteIf you create rules for file extensions that are identical except for their case, the rule created later overwrites the rule created earlier. For example, a rule for `JPG,TXT` overwrites a rule for `jpg,txt`. Rules are case-sensitive when they are applied.
You cannot use an asterisk (*) to match all file types.
Status Code Expiration Time Settings
The status codes to cache and their cache durations. The maximum duration is three years. The unit is seconds. The rules are as follows:
Separate multiple status codes with commas (,).
For 2xx and 3xx status codes, only exact matches are supported. Wildcard matches are not supported. For example, 201=10 is supported, but 2xx=12 is not.
For 4xx and 5xx status codes, both exact matches and wildcard matches are supported. For example, 401=10 and 4xx=12 are both supported.
Prioritize Origin Server Cache Policy
If you enable this feature and the origin server returns cache policy headers, such as Cache-Control and Pragma, the cache policy of the origin server takes precedence.
Ignore No-cache Headers From Origin Server
If you enable this feature, DCDN POPs ignore the following no-cache headers from the origin server.
Cache-Control: no-store
Cache-Control: no-cache
Cache-Control: max-age=0
Pragma: no-cache
Client Follows DCDN Cache Policy
If you enable this feature, the DCDN POP returns the final effective cache policy to the client.
Force Content Revalidation
This parameter takes effect only when the cache expiration time is set to 0. The effects are as follows:
Off (default): When the time-to-live for DCDN is set to 0, files are not cached on DCDN nodes. Every request must be fetched from the origin server.
Enabled: When the time-to-live (TTL) of DCDN is set to 0, files can be cached on DCDN nodes, and each request requires back-to-origin validation.
Click OK to save the configuration.
After you add a rule, it appears in the Expiration Time Of Status Code list, where you can Modify or Delete it.
Configuration examples
Example 1: Directory-based rule
Create a directory-based rule as shown in the following figure:
For the /directory/aaa directory, all 4xx status codes are cached for 10 seconds, and the 201 status code is cached for 15 seconds. During these periods, DCDN POPs directly respond to requests. After the cache expires, an origin fetch is triggered.
Example 2: File extension-based rule
Create a file extension-based rule as shown in the following figure:
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. During these periods, DCDN POPs directly respond to requests. After the cache expires, an origin fetch is triggered.
Example 3: Priority of different rule types
A directory-based rule and a file extension-based 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 DCDN POP. The DCDN POP requests the resource from the origin server, and the origin server returns a 404 status code. The request matches both the directory-based rule and the file extension-based rule. Because the priority of rule types is File Extension > Directory, the file extension-based 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-based Rule 1" is created for the '/directory' path. Then, "Directory-based Rule 2" is created for the '/directory/aaa' path. They 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 DCDN POP. The DCDN POP requests the resource from the origin server, and the origin server returns a 404 status code. The request matches both directory-based rules. Because the priority for rules of the same type is Earlier created > Later created, "Directory-based Rule 1", which was created first, takes effect. The actual cache duration for the 404 status code is 15 seconds.