All Products
Search
Document Center

Edge Security Acceleration:Create a cache rule for resources

Last Updated:May 24, 2024

Time-to-live (TTL) is the amount of time that a resource is cached on Dynamic Content Delivery Network (DCDN) 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.

  • For information about cache rules for static files and which rule is executed, see Default cache rule and priorities of cache rules. For information about cache rules for dynamic files, see Overview.

  • 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 DCDN 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 Configure.

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

  5. On the Cache Duration tab, click Add.

  6. In the Cache Duration dialog box, configure the parameters according to the following table.

    配置缓存过期时间

    Parameter

    Description

    Type

    Select Directory or Filename Extension.

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

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

    Content

    Specify the directory or filename 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 Filename Extension, take note of the following rules:

      • You can enter one or more filename extensions. Separate the filename extensions with commas (,). Example: jpg,txt. Filename extensions are case-sensitive.

        The following types of static files are supported:

        • Images: GIF, PNG, BMP, JPEG, and JPG.

        • Web pages: HTML, HTM, and SHTML.

        • Audio and video files: MP3, WMA, FLV, MP4, WMV, OGG, and AVI.

        • Text files: DOC, DOCX, XLS, XLSX, PPT, PPTX, TXT, and PDF.

        • Others: ZIP, EXE, TAT, ICO, CSS, JS, SWF, APK, M3U8, TS, EJS, SVG, WOFF, and OTF.

      • You cannot use the asterisk 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 for static files that are frequently updated, such as JavaScript and CSS files, based on your business requirements.

    • 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 indicates 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 their priorities.

    • 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.

  7. Click OK.

    You can modify or delete the cache rule that you created on the Cache Duration 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. DCDN 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 DCDN 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 POPs to cache .txt files for 7 days, add a cache rule for .txt files in the DCDN console and set the TTL to 7 days.不缓存

Example 2: The following cache rules are set for the accelerated domain name demo.aliyun.com. When DCDN 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 in order of creation time. The rule with the earliest creation time has the higher priority. Therefore, the rule that is set for the /image directory is applied because the rule is created the earliest.缓存策略2

Related API operations

BatchSetDcdnDomainConfigs