A cache key is a unique ID for a file that is cached on a Dynamic Route for CDN (DCDN) node. By default, a cache key is the URL in a request, including the parameters. DCDN allows you to rewrite the cache keys of requests that are destined for the same resource file to the same cache key. This helps you save the cache space and reduce the number of requests redirected to the origin server. This topic describes how to set a custom cache key.

Scenarios

Scenario 1:

The URLs in requests may contain complex parameters, even if they are used to retrieve the same resource file. Due to different URL parameters, DCDN nodes treat these requests as requests sent to retrieve different resource files and then cache resource files for all of the requests. As a result, a large number of requests are redirected to the origin server. Figure 1
You can set a cache key for a specified type of request to reduce the number of requests redirected to the origin server. Figure 2

Scenario 2:

The requests carry the same URL. In this case, DCDN treats these requests as requests sent to retrieve the same resource file. However, the client operating systems are specified in the client field of the HTTP header in these requests. You may need to return different resource files based on the specified operating system. Scenario 1
To resolve this problem, you can set two cache keys and include the value of the client field in the cache keys, and then use the cache keys to distinguish the requests. Scenario 2

Procedure

  1. Log on to the DCDN console.
  2. On the Domain Names page, find the domain name that you want to manage and click Configure in the Actions column.
  3. In the left-side navigation pane on the details page of the specified domain name, click Cache.
  4. On the Custom Cache Key tab, set a cache key.
    Note
    • You can modify only the URIs, parameter actions, and HTTP headers in a cache key. Custom variables are supported. You can add variables to retrieve fields from requests. A cache key consists of URIs, parameter actions, HTTP headers, and custom variables.
    • Custom cache keys do not modify the URLs of requests that are redirected to origin servers. Custom cache keys only modify the cache identifiers in these requests. Requests redirected to origin servers and sent by clients carry the same content.
    Custom cache keys
  5. Click OK.

Example

URIs

In the following figure, requests destined for URIs http://example.com/a/b/test.jpg and http://example.com/a/b/c/test.jpg are considered requests sent to retrieve the same resource file. The cache key of the resource file is http://example.com/c/test.jpg. URI

Parameter Actions

In the following figure, requests are destined for http://example.com/a/b/test.jpg?delete_par=1&modify_par=1. The parameter add_par=1 is added to the URL, the parameter delete_par is deleted from the URL, and then the value of the parameter modify_par is changed to 2. The final URL is http://example.com/a/b/test.jpg?modify_par=2&add_par=1.
Important For parameter actions, the priorities of rules applied to the same variable are: Add > Delete > Retain Only > Modify.
Parameter actions

HTTP Headers

In this example, the values of the User-Agent and Accept-Language fields in the HTTP header are included in cache keys. For example, if a request destined for http://example.com/a/b/test.jpg carries User-Agent=Mozilla/5.0 (Linux; X11) and Accept-Language=en in its header, the cache key of the request is http://example.com/a/b/test.jpgMozilla/5.0(Linux;X11)en. HTTP Header

Custom Variables

Example 1:

The name of the variable is language. The source of the variable is Request Header, the source field of the variable is Accept-Language, the match rule is ([%w]+),([%w]+), and the variable expression is $1aa. Custom variables
If a request destined for http://example.com/a/b/test.jpg carries the HTTP header Accept-Language=en,ch , the match rule assigns the value en to $1 in the variable expression. The string aa is also appended to the end of the variable expression. As a result, variable enaa with the alias language is generated. After DCDN appends the variable to the URL, the final cache key is: http://example.com/a/b/test.jpgenaa.
Note The definition of $n in the variable expression refers to the matched content enclosed in the No. n brackets. In Example 1, Accept-Language=en,ch and the match rule is ([%w]+),([%w]+). Therefore, $1=en, and $2=ch.

Example 2:

The name of the custom variable is expired. The source of the variable is Request Cookie, the source field is a, the match rule is [%w]+:(.*), and the variable expression is $1. Custom variables

If a request destined for http://example.com/a/b/test.jpg carries the Cookie a=expired_time:12635187 cookie, the match rule assigns the value 12635187 to $1 in the variable expression. The alias of the variable is expired. The final cache key is http://example.com/a/b/test.jpg12635187.

Example 3:

Set URI rules and custom variables at the same time

URI:

Transform /abc/.*/abc in all request URIs to /abc. Example 3

Custom variable:

The name of the custom variable is testname. The source of the variable is Path, the match rule is /abc/xyz/(.*), and the variable expression is $1. Example 3

If a request is destined for http://example.com/abc/xyz/abc/test.jpg, the URL is changed to http://example.com/abc/test.jpg based on the URI rule. The URL matches /abc/xyz/(.*). In this case, $1 is assigned the value abc and then appended to the cache key. The generated cache key is http://example.com/abc/test.jpgabc. Therefore, two rules are applied at the same time to support more complicated caching logic.