Custom Cache Key

Last updated: 2023-09-07 15:03:19

Overview

When you need to direct requests from the same path URL to different files based on request parameters, cookies, or HTTP request headers, or when you want to direct requests from URLs with different parameters to the same file, the custom Cache Key allows you to customize the Cache Key identifier for resources cached within the node. This includes concatenating query strings, HTTP headers, or Cookie information, so that the request URL can correctly obtain the corresponding cached resources according to different scenarios. You can learn about what a Cache Key is through the Cache Key Introduction.

Use Cases

Scenario I: The file paths accessed by the user are identical, but there will be version distinctions based on the carried query strings, HTTP request headers, and Cookie content. The cache key for this type of file can be adjusted through customizing the Cache Key to differentiate file caching.
Scenario II: The content of the query string in the URL accessed by the user does not affect the file content at all. The files corresponding to the above requests are consistent and do not affect the file version. The cache key for this type of file can be adjusted through customizing the Cache Key to make requests hit the same file cache.

Instructions

Scenario 1: Configuring Custom Cache Key for All Domain Names of the Site

To configure a custom Cache Key for all domain names used to access a site, or as a fallback configuration at the site level, refer to the following steps:
1. Log in to the EdgeOne console. In the left-hand menu, click on Site List. Within the site list, click on the site that needs to be configured.
2. On the site details page, click Site Acceleration > Cache Configuration, find the Query String card, and click on the global site settings to configure.
Note:
Global configuration only allows for the configuration of Query String and Case Ignoring. For more extensive custom Cache Key configuration options, please refer to the configuration steps in Scenario II's rule engine.

The default configuration is to retain all, that is, to keep all query parameters of the original request URL as the Cache Key. Other options are supported: a. Ignore all: Ignore the entire query string; b. Retain specified parameters: Only retain the specified parameters in the query string; c. Ignore specified parameters: Only ignore the specified parameters in the query string.

By default, case sensitivity is not ignored. Even if the URL content is the same, different letter cases are considered as different Cache Keys. When case insensitivity is enabled, different letter cases will be considered as the same Cache Key.

Scenario 2: Configuring Custom Cache Key for Specific Domain Names, Paths, or File Extensions Request Granularity

If you need to configure a custom Cache Key rule for the domain www.example.com under the site example.com to ignore all query strings, and use the HTTP request header My-Client-Header and the parameters name1, name2 in the Cookie as the Cache Key, you can refer to the following steps for configuration:

Instructions

1. Log in to the EdgeOne console. In the left-hand menu, click on Site List. Within the site list, click on the site that needs to be configured.
2. On the site details page, click Rule Engine.
3. On the rule engine management page, click Create rule to access the new rule editing page. On the rule editing page, select Host as the matching type and configure it as www.example.com.
4. Click Operation, and in the pop-up operation list, select Customize Cache Key.
5. Click Add below the type to add a custom Cache Key type. In this example scenario, add query strings, HTTP request headers, and Cookies, and fill in the corresponding content. The complete rule configuration is as follows:

6. Click Save and publish to complete the rule configuration.

Effective Examples

Upon configuration completion, the Cache Key is composed of URL+My-Client-Header+Cookie: all query strings are ignored, and the My-Client-Header and the Cookie after retaining specified parameters are concatenated.
Request A from the client:
URL:https://www.example.com/path/demo.jpg?key1=value1&key2=value2
HTTP Request Header: Includes My-Client-Header:fruit.
Cookie:name1=yummy;name2=tasty;name3=strawberry。
Request B from the client:
URL:http://www.example.com/path/demo.JPG?key1=value1&key2=value2&key3=value3
HTTP Request Header: Includes My-Client-Header:fruit.
Cookie:name1=yummy;name2=tasty;name3=blueberry。
Request C from the client:
URL:http://www.example.com/path/demo.JPG?key1=value1&key2=value2&key3=value3&key4=value4
HTTP Request Header: Includes My-Client-Header:sea.
Cookie:name1=yummy;name2=tasty;name3=fish。
Requests A and B will hit the same cached resource, and request C will hit another.