Cache duration refers to the amount of time that a resource is cached on Alibaba Cloud Dynamic Route for CDN (DCDN) nodes. When the cache duration of a cached resource ends, the resource on the DCDN nodes 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 DCDN nodes. You can add a cache rule for static resources based on file directories or filename extensions.

Usage notes

  • When you update a file on the origin server, we recommend that you add version numbers to the name of the file. This way, you can differentiate between file versions.

    To differentiate file versions after updates, we recommend that you add version numbers to file names. This way, each file version has a unique name. For example, you can name a file img-v1.0.jpg before it is updated and img-v2.1.jpg after it is updated.

  • The resource cache duration affects the back-to-origin routing frequency. Set a proper cache duration based on your business requirements.

    A short cache duration may cause frequent back-to-origin routing and increase loads on the origin server. A long cache duration may cause resources on DCDN nodes to be outdated.

  • Cached resources that are infrequently requested may be removed from the DCDN nodes before they expire.
  • If a DCDN node retrieves a static file from an origin server, the node processes the file based on the priorities of the cache rules. For more information, see Priorities of DCDN cache rules.

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 in the Actions column.
  4. In the left-side navigation pane of the domain name, click Caching.
  5. On the Cache Duration tab, click Add.
  6. In the Cache Duration dialog box, configure the parameters that are described in the following table.
    Add a cache rule
    Parameter Description
    Type You can select Directory or Filename Extension.
    • Directory: Add a cache rule for resources under the specified directory.
    • Filename Extension: Add a cache rule for resources with the specified filename extension.
    Content Specify the directories or filename extensions 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 (/), for example, /directory/aaa.
    • If you select Filename Extension, take note of the following rules:
      • You can enter one or more filename extensions and separate them with commas (,), for example, jpg,txt. Filename extensions are case-sensitive.
        The following static file types 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, and TS.
      • You cannot use a wildcard character (*) to specify all file types.
    Expire In The cache duration for cached resources. The maximum cache duration is three years. Take note of the following rules:
    • Specify a cache duration of one month or longer for static files that are infrequently updated, such as images and application packages.
    • Specify a cache duration based on your business requirements for static files that are frequently updated, such as JS and CSS files.
    • We recommend that you specify a cache duration of 0 seconds to disable caching for dynamic files, such as PHP, JSP, and ASP files.
    Weight The weight for a cache rule, which indicates the priority of the cache rule. Valid values are 1 to 99. A greater value indicates a higher priority.
    Note
    • If you create multiple cache rules, we recommend that you set a unique weight for each cache rule to define their priorities.
    • Cache rules that have the same weight are prioritized in order of creation time, regardless of the rule type. The rule with the earliest creation time applies.
    • If you have configured multiple cache rules for the same cached resource, only the first matched rule is applied.
  7. Click OK.

    After you add a cache rule, you can Modify or Delete the cache rule on the Cache Duration tab.

Priorities of DCDN cache rules

After a DCDN node retrieves a static file from an origin server, the node processes the static file based on the cache rules in the following order. A smaller value indicates a higher priority.Cache rules
  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 cache duration for cached resources, or the validity period for HTTP status codes set in the DCDN console.
    Note
    If a request matches multiple cache rules, only one rule is applied in the following order of priority: weight > rule creation time.
    • If you create multiple cache rules, we recommend that you set a unique weight for each cache rule to define their priorities. A higher weight indicates a higher priority.
    • Cache rules that have the same weight are prioritized in order of creation time, regardless of the rule type. The rule with the earliest creation time applies.
  3. DCDN 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, which is set to a value greater than 0, for example, cache-control:max-age=3600.
    2. The response carries the Expires header, for example, expires:Tue, 25 Nov 2031 17:25:43 GMT.
    3. If the response carries the ETag or Last-Modified header, the cache duration is calculated based on the following rules:
      1. If the response carries the Last-Modified header, the cache duration is calculated based on the following formula: Cache duration = (Current time - Last-Modified) × 0.1. If the result is between 10 seconds to 3,600 seconds, the result applies. If the result is less than 10 seconds, the cache duration is 10 seconds. If the result is greater than 3,600 seconds, the cache duration is 3,600 seconds.
      2. If the response carries only the ETag header, the cache duration 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 node.

HTTP caching mechanisms

HTTP provides three types of headers that can be used to control caching behaviors.
  1. Cache duration

    When a client requests resources from a server, the client and server define the cache duration of the returned resources that are cached on DCDN nodes. The resources expire when the cache duration ends.

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

    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 time. The cached resource expires at the specified time.

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

    Expires: Wed, 21 Oct 2022 07:28:00 GMT Response
    Cache-Control HTTP/1.1 The Cache-Control header can be set to different directives to control the caching behaviors. Most mainstream clients, such as browsers, use Cache-Control to control the caching behaviors.
    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 the subsequent requests for the same resource carries this tag. If the server checks the tag and confirms that the requested resource is not updated, the HTTP 304 status code is returned to the clients. The clients retrieve 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 has been updated or has expired. In this case, the clients 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 indicates 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 indicates whether a resource has been updated. If the resource has been 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 them, clients must provide more 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, Vary is used to differentiate versions of the requested resource so that the clients can retrieve the desired version of the requested resource.

    Header Protocol version Description Example Type
    Vary HTTP/1.1
    Examples
    • A server uses Vary: Accept-Encoding to inform the recipient, such as a DCDN node, that the requested resource has two versions. One is compressed, and the other is not. When the client sends requests to DCDN for the same resource, the browser with an earlier 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 DCDN node, of the browser types. The DCDN node caches the resource of the required version based on the browser types.

    Vary: Accept-Encoding

    Vary: Accept-Encoding,User-Agent

    Response

Configuration examples

Example 1: If you want DCDN nodes to cache .txt files for 7 days, add a cache rule for .txt files in the DCDN console and set the cache duration to 7 days. No caching
Example 2: The following cache rules are set for the accelerated domain name demo.aliyun.com. When DCDN nodes retrieve the resource http://demo.aliyun.com/image/example.png, each of the rules is a match. 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. Cache rule 2

Related API operations

BatchSetDcdnDomainConfigs