Edge Security Acceleration:Default cache rules

Default cache policy

Cache configurations take effect only for client requests that are sent to the ESA cache component. To determine whether a client request is sent to the cache component, ESA carries out the following procedure:

1. Checking whether the request is of the GET or HEAD type.

2. Checking whether the request meets the conditions specified in a cache rule. If the request meets the conditions, the cache rule, instead of the global cache settings, applies to the request. For more information, see How the cache configurations work.

3. Checking if the file extension is listed under Extensions of default cached files. If it is, the global cache settings apply to the request.

How the cache configurations work

The edge cache TTL has four options, each of which is applied based on different logics:

• Honor Origin TTL or Use Default Cache Rule: If the response returned from the origin server contains the Cache-Control, Expires, Last-Modified, and ETag headers for setting a cache policy, ESA uses the cache policy of the origin server. If the response returned from the origin server does not contain any of the Cache-Control, Expires, Last-Modified, and ETag headers, ESA caches resources based on the default cache policy of ESA.

  Cache policy details

  

  Cache-Control in the response

  The Cache-Control header in the origin response specifies one of the following policies:

  1. If the Cache-Control header has one of the following directives, the resource is not cached:

     • no-cache

     • no-store

     • max-age=0

  2. If the Cache-Control header contains the max-age or s-maxage directive with a value greater than 0, such as 3600, the TTL specified by the directive is used. If both the max-age and s-maxage directives exist, the value of the s-maxage directive prevails.

  No Cache-Control in the response

  If the origin response does not contain the Cache-Control header, the default cache policy of ESA is used. Headers in responses from the origin server are in the following descending order of priority: Expires > Last-Modified > ETag.

  1. If the origin response contains the Expires header, such as Expires:Tue, 25 Nov 2031 17:25:43 GMT, ESA uses the TTL set in the Expires header.

  2. If the origin response does not contain the Expires header but contains the Last-Modified header, the TTL is calculated based on the following rules:

     • TTL = (Current time - Value of Last-Modified) × 0.1. If the resulting value ranges from 10 seconds to 3,600 seconds, the actual value is used. If the resulting value is less than 10 seconds, the TTL is 10 seconds. If the resulting value is greater than 3,600 seconds, the TTL is 3,600 seconds.

  3. If the origin response contains only the ETag header, the TTL is 10 seconds.

  4. If the origin response does not contain the Cache-Control, Expires, ETag, or Last-Modified header, the resource is not cached.

• Honor Origin TTL or Do Not Cache: If the response returned from the origin server contains the Cache-Control header for setting a cache policy, ESA uses the cache policy of the origin sever. If the response returned from the origin server does not contain the Cache-Control header, ESA does not cache resources.

  Cache policy details

  

  Determine the cache policy of the origin server

  To determine the cache policy of the origin server, check whether the origin response contains the Cache-Control header. If the header does not exist, resources are not cached. If the header exists, one of the following cache policies applies:

  1. If the Cache-Control header contains the no-cache, no-store, or max-age=0 directive, resources are not cached.

  2. If the Cache-Control header contains the max-age or s-maxage directive with a value greater than 0, such as 3600, the TTL specified by the directive is used. If both the max-age and s-maxage directives exist, the value of the s-maxage directive prevails.

• Do Not Cache: All resources retrieved from the origin server are not cached on ESA POPs.

• Use Custom TTL: ESA ignores the Cache-Control, Expires, Last-Modified, and ETag headers of the cache policy in the origin response and uses the TTL set on ESA.

Cache response information

ESA POPs provide standard and clear responses that enable you to dynamically adjust their HTTP requests. The response headers related to the cache contain the following information:

• Ali-Swift-Global-Savetime:

  • The time when the resource first entered the ESA POP (determined by the website's cache architecture, which may be an L2 POP or a POP at another cache tier).

  • The value is a UNIX timestamp. For example: 1745053111 indicates 16:58:31 on April 19, 2025.

• Date:

  • The date when the origin server returns the resource to the ESA POP.

  • The date is updated when the ESA POP initiates an origin request that contains the If-Modified-Since or lf-None-Match header to revalidate the resource and the origin server returns HTTP status code 304.

  • The time is in GMT format. Example: Sat, 19 Apr 2025 08:58:31 GMT.

• X-Site-Cache-Status:

  The cache status of the requested resource on the ESA POP. The following list describes the resource states:

  • HIT: The resource is found in the ESA POP cache.

  • MISS: The resource is not found in the ESA POP cache. The POP retrieves the resource from the origin server and then returns the resource to the client.

  • EXPIRED: The resource is found in the ESA POP cache but has expired. The POP retrieves the resource from the origin server and then returns the resource to the client. The status code returned by the origin server is 200 or 206.

  • STALE:

    The resource is served from the ESA POP cache but has expired. This occurs in the following cases:

    • The cache setting is Honor Origin TTL and the origin response contains Cache-Control:stale-while-revalidate=<seconds>. Within the specified time, the ESA initiates a request to the origin server to revalidate the resource and serves the expired cache to the client.

    • The cache setting is Honor Origin TTL and the origin response contains Cache-Control:stale-if-error==<seconds>. Within the specified time, ESA serves the expired cache to the client when ESA cannot connect to the origin server to retrieve the updated resource.

    • The Serve stale content feature is enabled. This feature allows the ESA POP to serve the expired cache to the client when the origin response times out or when the origin server is unreachable.

  • BYPASS

    The request to the resource bypasses the ESA cache. This occurs in the following cases:

    • The cache setting is not Honor Origin TTL and ESA sets a custom cache TTL to 0 seconds.

    • The cache setting is Honor Origin TTL but the value of the Cache-Control header returned by the origin server is no-cache, no-store, or max-age=0.

  • REVALIDATED

    The resource is served by the ESA cache, but it has expired. ESA initiates an origin request that contains the If-Modified-Since or lf-None-Match header to the origin server to revalidate the resource. The origin server returns HTTP status code 304.

  • DYNAMIC

    ESA detects that the resource is dynamic content and no defined cache rules apply to such a request. In this case, ESA retrieves the resource from the origin server and then returns it to the client.

• X-Swift-Cachetime:

  The cache TTL of the resource on the ESA POP. Unit: seconds.

• X-Swift-SaveTime:

  • The time when the resource first entered the current POP (L1 POP) that receives the client request.

  • The time is in GMT format. Example: Sat, 19 Apr 2025 08:58:31 GMT.

Do Not Cache policy

The ESA POP does not cache files and passes through all file requests in the following conditions:

• Edge Cache TTL on the ESA Settings page is set to Honor Origin TTL or Do Not Cache and the origin response is Cache-Control: no-store.

• Edge Cache TTL on the ESA Settings page is set to Do Not Cache.

• Edge Cache TTL on the ESA Settings page is set to Use Custom TTL and the cache TTL is set to 0 seconds.

Cache revalidation

After a cached file on the ESA POP expires, the cache revalidation mechanism takes effect the next time the client requests the file. The ESA POP sends a validation request to the origin server. If the file has not changed, the origin server returns the 304 not-modified message, and the ESA POP continues to serve the cached file to the client without the need to download the file again. This effectively improves the response speed of client requests and reduces the response traffic from the origin server.

• Special policy configuration: A file is cached for 0 seconds, and the ESA POP redirects each request to the origin server for validation.

  • Edge Cache TTL on the ESA Settings page is set to Honor Origin TTL or Use Default Cache Rule, and the origin response meets the following conditions:

    • Cache-Control: no-cache

    • Cache-Control: max-age=0

• Regular policy configuration: The origin server responds to the policy related to cache validation, and the ESA POP executes the actual policy.

  • Edge Cache TTL on the ESA Settings page is set to Honor Origin TTL or Use Default Cache Rule, and the origin response meets one of the following cache validation policies:

    • must-revalidate

    • proxy-revalidate

    • stale-while-revalidate=seconds

    • stale-if-error=seconds

• Cache validation policy

  The following list describes the cache validation policies and provides related examples:

  • must-revalidate

    • Description: This policy indicates that if a resource has expired, the resource must be returned to the origin server to validate its freshness for any cache (including proxy caches and browser caches) before the cache returns a response. Even if the user is offline or the network is unavailable, the cache cannot directly use the expired resource unless the resource has been validated to be unchanged.

    • Example: Cache-Control: max-age=3600, must-revalidate indicates that a resource must be returned to the origin server to validate its freshness after the resource expires.

  • proxy-revalidate

    • Description: Similar to the must-revalidate policy, this policy applies only to shared caches, such as CDN and proxy server caches. This policy does not apply to private caches such as browser caches. If a resource has expired, the resource must be returned to the origin server for validation before a shared cache provides a cache replica. Private caches are not subject to this limit.

    • Example: Cache-Control: max-age=3600, proxy-revalidate indicates that a resource must be returned to the origin server to validate its freshness after the resource expires.

  • stale-while-revalidate=seconds

    • Description: This policy indicates that the cache can continue to provide the old cached resource for a specified period (in seconds) after the resource expires. At the same time, the POP asynchronously requests the latest content from the origin server in the background. This policy applies when you want to reduce waiting time and can accept content that may not be the freshest within a short period of time.

    • Example: Cache-Control: max-age=3600, stale-while-revalidate=60 indicates that a resource is considered fresh for 3,600 seconds (1 hour) after it is first published. Once expired, the resource can still be provided for users for the next 60 seconds. At the same time, the POP attempts to obtain updates from the origin server.

  • stale-if-error=seconds

    • Description: This policy indicates that when the POP fails to retrieve the latest content from the origin server due to reasons such as server breakdown or network errors, this policy allows the POP to return a response indicating that the resource has expired but is still cached. A time period (in seconds) is defined, during which if an error occurs, the expired cached content can be used. This improves the fault tolerance capabilities of the system and ensures that you can access the previously cached content even if the origin server is unavailable, thereby improving user experience and reducing the impact of service interruptions.

    • Example: Cache-Control: max-age=86400, stale-if-error=604800 indicates that a resource is considered fresh for 86,400 seconds (24 hours) after it is first published. If revalidation after the 86,400 seconds fails, the last successfully cached resource can still be provided for the next 604,800 seconds (one week).