All Products
Search
Document Center

CDN:Create a cache rule for resources

Last Updated:Oct 14, 2024

Time-to-live (TTL) is the amount of time that a resource is cached on Alibaba Cloud CDN points of presence (POPs). When the TTL of a cached resource ends, the resource on the POPs expires. Requests that attempt to access expired resources are redirected to the origin server. The retrieved resources are returned to the clients and cached on the POPs. You can create a cache rule for static resources based on file directories or file name extensions.

Usage notes

  • After you add a domain name, you can modify the TTL value. The amount of origin traffic and the fees incurred vary based on the TTL that you specify. The resource TTL affects the origin fetch frequency. Specify a TTL based on your business requirements.

    A short TTL may cause frequent origin fetches and increase loads on the origin server. A long TTL may cause resources on the POPs to become outdated.

  • If a resource that is cached on a POP is infrequently accessed, the resource may be overwritten by frequently accessed resources on the POP before the resource expires.

  • If a POP retrieves a static file from an origin server, the POP processes the file based on the priorities of the cache rules. For more information, see Default cache rule and priorities of cache rules.

  • When you update a file on the origin server, we recommend that you add a version number to the file name to differentiate file versions after updates.

    This way, each version of the file after an update has a unique name. For example, you can name a file img-v1.0.jpg before the file is updated and img-v2.1.jpg after the file is updated.

Procedure

  1. Log on to the Alibaba Cloud CDN console.

  2. In the left-side navigation pane, click Domain Names.

  3. On the Domain Names page, find the domain name that you want to manage and click Manage in the Actions column.

  4. In the left-side navigation tree of the domain name, click Cache.

  5. On the Cache Expiration tab, click Create Rule.

  6. In the Create Expiration Rule dialog box, configure the parameters. The following table describes the parameters.

    缓存过期时间

    Parameter

    Description

    Type

    Select Directory or File Extension.

    • Directory: creates a cache rule for the resources in the same directory.

    • File Extension: creates a cache rule for the resources that have the same file name extension.

    Object

    Specify the directory or file name extension for which you want to add the cache rule.

    • If you select Directory, take note of the following rules:

      • You can enter only one directory at a time. You can use a forward slash (/) to specify all directories.

      • You can enter a full path. The path must start with a forward slash (/). Example: /directory/aaa.

    • If you select File Extension, take note of the following rules:

      • You can enter one or more file name extensions. Separate multiple file name extensions with commas (,). Example: jpg,txt.

      • File name extensions are case-sensitive.

      • You cannot use an asterisk (*) as a wildcard character to specify all file types.

    Expire In

    Specify the TTL. The maximum TTL is three years. Take note of the following rules:

    • Specify a TTL of one month or longer for static files that are infrequently updated, such as images and application packages.

    • Specify a TTL based on your business requirements for static files that are frequently updated, such as JavaScript and CSS files.

    • Specify a TTL of 0 seconds to disable caching for dynamic files, such as PHP, JSP, and ASP files.

    Weight

    Specify a weight for the cache rule. The weight specifies the priority of the cache rule. Valid values: 1 to 99. A larger value specifies a higher priority.

    Note
    • If you create multiple cache rules, we recommend that you specify a unique weight for each cache rule to define the priorities of the cache rules.

    • Cache rules that have the same weight are prioritized based on the creation time, regardless of the rule type. The rule that has the earliest creation time takes precedence.

    • If you have configured multiple cache rules for a cached resource, only the first matched rule takes effect.

    Rule Condition

    Rule conditions can identify parameters in a request to determine whether a configuration applies to the request.

    • Do not use conditions

    • Select the configured rule conditions in Rules Engine. For more information, see Rules engine.

  7. Click OK.

    You can click Modify or Delete to modify or delete the cache rule on the Cache Expiration tab.

Default cache rule and priorities of cache rules

After a POP retrieves a static file from an origin server, the POP processes the static file based on the priorities of the following cache rules. A smaller number specifies a higher priority.缓存优先级

  1. If the response carries the pragma:no-cache, cache-control:no-cache, cache-control:no-store, or cache-control:max-age=0 directive, the static file is not cached.

  2. Alibaba Cloud CDN follows the TTL for cached resources, or the TTL for HTTP status codes that are configured in the console.

    Note

    If a request matches multiple cache rules, only one rule takes effect based on the following order of priority: weight > creation time.

    • If you create multiple cache rules, we recommend that you specify a unique weight for each cache rule to define the priorities of the cache rules. A higher weight specifies a higher priority.

    • Cache rules that have the same weight are prioritized based on the creation time, regardless of the rule type. The rule that has the earliest creation time takes precedence.

  3. Alibaba Cloud CDN follows other cache rules set on the origin server. Headers in responses from the origin server are in the following descending order of priority: Cache-Control > Expires > Last-Modified > ETag.

    1. The response carries the Cache-Control header, and the directive is max-age or s-maxage, which is set to a value that is greater than 0, such as Cache-Control:max-age=3600. If both the max-age and s-maxage directives exist, the value of the s-maxage directive prevails.

    2. The response carries the Expires header, such as Expires:Tue, 25 Nov 2031 17:25:43 GMT.

    3. If the response carries the ETag or Last-modified header, the TTL is calculated based on the following rules:

      1. If the response carries the Last-Modified header, TTL = (Current time - Last-Modified) × 0.1. If the result is from 10 seconds to 3,600 seconds, the result applies. If the result is less than 10 seconds, the TTL is 10 seconds. If the result is greater than 3,600 seconds, the TTL is 3,600 seconds.

      2. If the response carries only the ETag header, the TTL is 10 seconds.

  4. If the response does not carry the ETag, Last-Modified, Cache-Control, or Expires header, the static file is not cached on the POP.

HTTP caching mechanisms

HTTP provides three types of headers that can be used to control caching behavior.

  1. Cache TTL

    When a client requests resources from a server, the client and server define the TTL of the returned resources that are cached on the POPs. The resources expire when the TTL ends.

    HTTP provides the following types of headers that can be used to define the cache TTL.

    Header

    Protocol version

    Description

    Example

    Type

    Pragma

    HTTP/1.0

    The Pragma header specifies whether a resource is cached. If Pragma is set to no-cache, the resource is not cached. Pragma is compatible with servers that use only HTTP/1.0.

    Pragma:no-cache

    Request and response

    Expires

    HTTP/1.0

    The Expires header specifies a date and point in time. Cached resources expire at the specified point in time.

    If Expires is set to an invalid value, such as 0, the resource has expired.

    Expires: Wed, 21 Oct 2022 07:28:00 GMT

    Response

    Cache-Control

    HTTP/1.1

    The Cache-Control header holds different directives that specify caching policies. Mainstream clients, such as browsers, use the Cache-Control header to control caching behavior.

    The following directives specify that files are not cached:

    • Cache-Control:no-cache

    • Cache-Control:no-store

    • Cache-Control:max-age=0

    The following directive specifies that files are cached for 1 hour: Cache-Control:max-age=3600.

    Request and response

  2. Resource tags

    The first time a client requests a resource from a server, the server adds a tag to the response headers. The next time the client requests the resource from the server, the tag is used to identify the requested resource. The header of subsequent requests carries this tag. If the server checks this tag and confirms that the requested resource is not updated, the HTTP 304 status code is returned to the client. The client retrieves the resource from the local cache. If the server detects that the tag is different from that of the resource on the server, the server informs the clients that the resource is updated or has expired. In this case, the client must retrieve the latest version of the resource from the server.

    HTTP provides the following types of headers that can be used to control cache versions.

    Header

    Protocol version

    Description

    Example

    Type

    Last-Modified

    HTTP/1.0

    Last-Modified specifies the time when a resource was last updated.

    Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT

    Response

    ETag

    HTTP/1.1

    The ETag header is the unique identifier of each version of a resource.

    ETag specifies whether a resource is updated. If the resource is updated, the server does not need to return a complete response.

    ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

    Response

  3. Content negotiation

    Caching software uses keywords to index objects on disks. In HTTP/1.0, URLs are used as keywords. However, different resources may point to the same URL. To differentiate the resources, clients must provide additional information, such as the Accept-Language and Accept-Charset headers. HTTP/1.1 introduced the Vary response header to implement content negotiation. The Vary header lists the request headers that must be included to implement content negotiation.

    In content negotiation, the Vary header is used to differentiate variants. This way, the clients can retrieve the desired variants.

    Header

    Protocol version

    Description

    Example

    Type

    Vary

    HTTP/1.1

    Examples

    • The server uses Vary: Accept-Encoding to inform the recipient, such as a POP, that the requested resource has two variants. One of the variants is compressed, and the other is not compressed. When the client sends requests to Alibaba Cloud CDN for the same resource, the browser with an outdated version requires the resource to be uncompressed to prevent incompatibility. The browser with the latest version requires the resource to be compressed to reduce data transfer.

    • The server uses Vary: User-Agent to identify the browsers that initiate the requests and inform the recipient, such as a POP, of the browser types. The POP caches variants based on the browser types.

    Vary: Accept-Encoding

    Vary: Accept-Encoding,User-Agent

    Response

Configuration examples

Example 1: If you want the POPs to cache TXT files for seven days, create a cache rule for TXT files in the Alibaba Cloud CDN console and set the TTL to seven days.

image.png

Example 2: The following cache rules are configured for the accelerated domain name demo.aliyun.com. When the POPs retrieve the resource http://demo.aliyun.com/image/example.png, the two rules are matched. In addition, the rules have the same weight. In this case, the rules are prioritized based on the creation time. The rule that has the earliest creation time has the highest priority. Therefore, the rule that is configured for the /image directory takes effect.image.png

Related API operations

BatchSetCdnDomainConfig

FAQ