Rule characteristics-Edge Security Acceleration(ESA)-阿里云帮助中心

Rule-based features differ in three characteristics: the priority of rule settings and global settings, reentrancy, and the granularity of rule settings. This topic explains each characteristic and specifies which characteristics apply to each rule-based feature.

Priority of rule settings and global settings

Rule configurations take precedence over global settings: For the same feature, rule settings override global settings. Apply general configurations globally and use rules to customize behavior for specific requests.
For example, if you set edge TTL to 12 hours in Global Configuration – Edge Cache TTL and set the TTL for /content resources to 30 days in Rules – Configure Edge Cache TTL, the edge node caches /content resources for 30 days. Resources not under /content use the 12-hour global TTL.

Rules higher in the list have higher priority: For the same rule type, ESA executes rules from top to bottom. If a request matches multiple rules, drag the button to reorder rules by priority.

Note

Available features and rule quotas vary by plan. Rule and plan quotas.

For example, suppose you have two cache rules:

Rule 1: Resources under the /content path expire after 30 days.

Rule 2: Files with the .jpg suffix are cached for 60 days.

When Rule 1 is above Rule 2, Edge node cache TTLs:

Sample URL	Under `/content` path	`.jpg` suffix	Cache expiration time
https://example.com/content/static/pic.jpg	Supported	Supported	30 days
https://example.com/content/static/book.txt	Supported	Not supported	30 days
https://example.com/static/pic.jpg	Not supported	Supported	60 days
https://example.com/static/res/book.text	Not supported	Not supported	Do not cache

When Rule 2 is above Rule 1, Edge node cache TTLs:

Sample URI	Under `/content` path	`.jpg` suffix	Cache expiration time
https://example.com/content/static/pic.jpg	Supported	Supported	60 days
https://example.com/content/static/book.txt	Supported	Not supported	30 days
https://example.com/static/pic.jpg	Not supported	Supported	60 days
https://example.com/static/res/book.text	Not supported	Not supported	Do not cache

Reentrancy of rule-based features

The reentrancy of a feature module determines whether the feature module can be called more than once while a single request is processed. Calls to a reentrant feature module do not interfere with each other, and the result of every call takes effect.

Reentrant features

During the processing of a request, a reentrant feature can be called multiple times. The calls do not interfere with each other, and the result of every call takes effect. For example, the Modify outbound request header feature is reentrant. If a client request matches multiple rule conditions, the rule setting of each matched condition is executed.

Example 1: Modify outbound request header

If a user request matches both Condition B and Condition C, both Rule setting 2 and Rule setting 3 are executed. The global settings are also executed, but they have no effect because no action is configured in them. As a result, the following two request headers are added to the user request:

animal: cat
fruit: apple

Sequence number	Rule setting	Rule condition	Feature setting	Executed
1	Rule setting 1	Condition A (not matched)	Add a request header whose name is `food` and whose value is `rice`.	No
2	Rule setting 2	Condition B	Add a request header whose name is `animal` and whose value is `cat`.	Yes
3	Rule setting 3	Condition C	Add a request header whose name is `fruit` and whose value is `apple`.	Yes
Global settings	None	None	Yes

Non-reentrant features

During the processing of a request, a non-reentrant feature can be called only once, and the corresponding feature module is exited after the call ends. If a client request matches multiple rule conditions, only the first matched rule setting is executed.

Example 2: Rewrite URL

If a user request matches both Condition B and Condition C, only Rule setting 2 is executed. Rule setting 2 has a smaller sequence number, so it matches Condition B first. As a result, the path of the user request URL is rewritten to /animal:

Original request: http://example.com/test
Rewritten request: http://example.com/animal

Sequence number	Rule setting	Rule condition	Feature setting	Executed
1	Rule setting 1	Condition A (not matched)	Rewrite the path of the user request URL to `/food`.	No
2	Rule setting 2	Condition B	Rewrite the path of the user request URL to `/animal`.	Yes
3	Rule setting 3	Condition C	Rewrite the path of the user request URL to `/fruit`.	No
Global settings	None	None	No

Granularity of rule settings

The granularity of rule settings includes the feature dimension and the sub-feature dimension. The two dimensions differ in how a sub-feature module behaves when its settings are left empty.

Feature dimension

At the feature dimension, an empty sub-feature setting is not resolved by any other rule: when a user request matches a rule condition, a sub-feature module whose settings are empty is executed as if no settings were added. The rule applies to the entire feature module, and the settings take effect for the entire feature module.

Example 3: SSL/TLS rule (a non-reentrant feature whose rule settings take effect at the feature dimension)

Assume that a user request matches both Condition B and Condition C. Rule setting 2 has a smaller sequence number, so it matches Condition B first and only Rule setting 2 is executed. Settings that are shown as - in Rule setting 2, such as the TLS cipher suite, take effect based on the default settings.

Sequence number	Rule setting	Rule condition	SSL/TLS encryption	TLS cipher suite and protocol version settings	OCSP Stapling	HTTP/2	HTTP/3 (QUIC)	Executed
1	Rule setting 1	Condition A (not matched)	Enabled	-	Disabled	Disabled	Disabled	No
2	Rule setting 2	Condition B	Enabled	-	Disabled	Disabled	Disabled	Yes
3	Rule setting 3	Condition C	Enabled	-	Enabled	Enabled	Enabled	No
Global settings	None	Disabled	-	Disabled	Enabled	Enabled	No

Sub-feature dimension

At the sub-feature dimension, an empty sub-feature setting is resolved by later rules: when a user request matches a rule condition, a sub-feature module whose settings are empty continues to match subsequent rule conditions until it matches a rule condition whose sub-feature settings are not empty. The rule applies to a sub-feature module, and the settings take effect for that sub-feature module.

Example 4: Cache rule (a non-reentrant feature whose rule settings take effect at the sub-feature dimension)

The following example shows cache rule settings and extends the rule list to five rule settings, with Condition A to Condition E. Assume that a user request matches Condition B, Condition C, and Condition D. Rule conditions are matched in ascending order of sequence number, and configuration items that are not set are executed based on the global default settings. Each sub-feature occupies a separate column in the following table and takes its value independently, as shown in the Final effective settings row.

Sequence number	Rule setting	Rule condition	Cache eligibility	Browser cache time-to-live (TTL)	Edge caching time-to-live (TTL)	Custom CacheKey	Port cache	Cache expired responses	Cache Reserve
1	Rule setting 1	Condition A (not matched)	Eligible for cache	-	Honor the origin server cache policy (if any). Otherwise, do not cache.	-	-	Disabled	-
2	Rule setting 2	Condition B	Eligible for cache	-	Honor the origin server cache policy (if any). Otherwise, do not cache.	-	-	Disabled	-
3	Rule setting 3	Condition C	Bypass cache	Do not cache	-	-	-	-	-
4	Rule setting 4	Condition D	Eligible for cache	-	Ignore the origin server cache policy and use a custom cache TTL of 1 hour.	Ignore query strings	-	Disabled	-
5	Rule setting 5	Condition E	Eligible for cache	-	-	-	-	Disabled	-
Global settings	None	-	-	-	-	Disabled by default	-	Disabled by default
Final effective settings	Eligible for cache	Do not cache	Honor the origin server cache policy (if any). Otherwise, do not cache.	Ignore query strings	Disabled	Disabled	Disabled

Characteristics of different features

The following table lists the reentrancy, granularity, and priority of the rule settings of each rule-based feature, grouped by feature category.

Feature category	Rule-based feature	Reentrancy	Granularity of rule settings	Priority of rule settings
SSL/TLS	SSL/TLS rules	Non-reentrant	Feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.
HTTPS rules	Non-reentrant	Sub-feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.
Transform rules	Rewrite URL	Non-reentrant	Feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.
Modify outgoing request headers	Reentrant	Sub-feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.
Modify outbound response headers	Reentrant	Sub-feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.
Redirection	Request redirects	Non-reentrant	Feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.
Caching	Cache rules	Non-reentrant	Sub-feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.
Content optimization	File compression	Non-reentrant	Sub-feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.
Image optimization	Non-reentrant	Sub-feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.
Video processing	Non-reentrant	Sub-feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.
Network optimization	Network optimization rules	Non-reentrant	Sub-feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.
Back-to-origin	Origin rules	Non-reentrant	Sub-feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.
Configuration management	Version management	Non-reentrant	Feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.
Traffic	Waiting Room rule	Non-reentrant	Feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.
Load balancing rule	Non-reentrant	Feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority. The result also depends on whether the End action is set: if the End action is set, matching ends after the first matched rule is executed and no further matching is performed; if the End action is not set and multiple rule conditions are matched, the feature setting of the last matched rule takes effect.
Security protection	Security rules	Non-reentrant	Feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.
Custom rules	Non-reentrant	Feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.
Rate limiting rules	Non-reentrant	Feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.
Managed rules	Non-reentrant	Feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.
Scan protection rules	Non-reentrant	Feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.
Whitelist rules	Non-reentrant	Feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.
Bots rule	Non-reentrant	Feature	Based on the sequence numbers in the rule list. A smaller sequence number indicates a higher priority.