Rules Engine
Scenarios
The rules engine allows you to configure rules in graphical mode, which is more flexible and fine-grained. By restricting trigger conditions, you can control the resource range for the configuration to take effect, meeting requirements in various scenarios, such as:
- The global CDN PoP configuration, for example, access control conditions, cannot meet your requirements for specific resources.
Precautions
- To use the rules engine, submit a service ticket.
- You can add up to 10 rules for a domain name.
- Domain names whose Service Type is Whole site do not support rules engines.
- You cannot configure the rules engine for domain names with special configurations.
- The rules engine configuration takes precedence over settings under other tabs.
- By default, the newest rule is displayed at the top. When multiple rules exist, those listed higher have a higher priority than those listed lower. That is, if multiple rules are matched, the rule with the highest priority takes effect.
- A trigger condition supports up to three levels of nesting. The logical operator of all rules at the deepest level must be either AND or OR.
Procedure
-
Log in to Huawei Cloud console. Choose .
The CDN console is displayed.
- In the navigation pane, choose .
- In the domain list, click the target domain name or click Configure in the Operation column.
- Click the Rules Engine tab and click Create Rule.
- Set Rule Name, configure the rule based on Trigger Conditions and Actions, and click OK.
- Rule Name: Enter 1 to 50 characters.
- Priority: Enter a number ranging from 1 to 100. A larger number indicates a higher priority.
Figure 1 Creating a rule
Trigger Conditions
Each trigger condition consists of a logical operator and a condition rule.
Logical operator: AND and OR are used to judge the logic of condition rules (including nested rules) at the same level.
- AND: triggers actions only when all conditions of the current level are met.
- OR: triggers actions when a condition of the current level is met.
Condition rule: consists of a condition, operator, and value. The condition and value define requests to comply with the rule. The operator defines the use cases of the rule.
- Include any value: The condition is met when user requests include any value of the condition.
- Exclude any value: The condition is met when user requests do not include any value of the condition.
- Exist: The condition is met when parameters configured in the condition (regardless of the value) exist in user requests.
- Do not exist: The condition is met when parameters configured in the condition (regardless of the value) do not exist in user requests.
Trigger condition parameters
When a user request matches a trigger condition, the specified actions are performed. Table 1 lists the trigger condition parameters.
Condition |
Condition Description |
Name |
Operator |
Value |
Case Sensitive (Value) |
---|---|---|---|---|---|
Protocol type |
Protocols used by client requests, for example, HTTP or HTTPS |
N/A |
|
|
N/A |
Request method |
Methods used by client requests, for example, GET or PUT |
N/A |
|
GET, POST, HEAD, PUT, DELETE, OPTIONS, PATCH, TRACE, and CONNECT |
N/A |
URI path |
Paths in client request URLs, excluding query parameters, for example, /favicon.ico |
N/A |
|
|
By default, Case sensitive is enabled. When it is disabled, uppercase and lowercase values are considered equal. |
HTTP request header |
Headers carried in user requests |
Request header name.
|
|
|
By default, Case sensitive is enabled. When it is disabled, uppercase and lowercase values are considered equal. |
Query parameter |
Query parameters carried in user request URLs |
Query parameter name
|
|
|
By default, Case sensitive is enabled. When it is disabled, uppercase and lowercase values are considered equal. |
File name |
Names of files requested by clients, for example, name1. |
N/A |
|
Set one or more file names. |
By default, Case sensitive is enabled. When it is disabled, uppercase and lowercase values are considered equal. |
File name extension |
Types of files requested by clients. CDN scans a file name from right to left until it encounters the first period (.) to identify the file name extension, for example, .txt. |
N/A |
|
Select or enter suffixes, such as .txt, .doc, .html, .jpg, .png, .svg, .zip, and .rar. |
By default, Case sensitive is enabled. When it is disabled, uppercase and lowercase values are considered equal. |
Client IP address |
Client IP addresses |
|
|
Enter IPv4 addresses (for example, 0.0.0.0) and IPv6 addresses (for example, 240e:95c:3004:2:3:0:0:XXX). Enter CIDR blocks (for example, 192.168.XXX.XXX/31). The prefix length ranges from 1 to 32 bits for IPv4 and 1 to 128 bits for IPv6. |
N/A |
Client IP version |
IPv4 or IPv6 |
|
|
|
N/A |
Nginx Var |
If all the preceding conditions cannot meet your requirements, you can use these Nginx variables: $protocol, $arg_, $http_, $scheme, $uri, $ssl_protocol, $ssl_server_name, $remote_addr, $http2, $sent_http_, and $request_method.
CAUTION:
After selecting the $sent_http_ variable, you can only set Actions to HTTP response headers. Conversely, you can select $sent_http_ only when you set Actions to HTTP response headers. |
Nginx variable name
|
|
|
By default, Case sensitive is enabled. When it is disabled, uppercase and lowercase values are considered equal. |
User-Agent |
User-Agent header in requests |
N/A |
|
|
By default, Case sensitive is enabled. When it is disabled, uppercase and lowercase values are considered equal. |
Actions
When a client request matches a rule, the related actions are executed. Table 2 lists the actions supported by the rules engine.
Category |
Name |
Description |
---|---|---|
Basic settings |
The configuration must be the same as that of HTTP Headers for CORS on the Advanced Settings tab, but their effective scopes are different.
|
|
Client requests that match the conditions in a rule must comply with the advanced origin configuration of this rule. |
||
Client requests that match the conditions in a rule must comply with the origin request header configuration of this rule. |
||
Higher access security |
Client requests that match the conditions in a rule must comply with the access control configuration of this rule. The action can be Permit or Reject.
|
|
Higher hit ratio |
Client requests that match the conditions in a rule must comply with the origin URL rewrite configuration of this rule. Rewrite Method: defines how to obtain the content to be rewritten. Select Exact or Capturing. Exact matches content whose Match Mode is set to All files or Path under the Origin Settings tab, while Capturing matches content whose Match Mode is set to Wildcard under that tab. |
|
Client requests that match the conditions in a rule must comply with the cache rule configuration of this rule. |
||
Client requests that match the conditions in a rule must comply with the access URL rewrite configuration of this rule. |
||
Cache settings |
Client requests that match the conditions in a rule must comply with the status code cache TTL configuration of this rule. |
|
Client requests that match the conditions in a rule must comply with the browser cache TTL configuration of this rule. |
IP Address Verification Modes
The rules engine has two IP address verification modes, affecting how CDN PoPs determine client IP addresses.
- Connecting IP: This mode matches the IP address used for connecting clients to CDN PoPs. If a proxy server is used, its IP address is the connecting IP address.
- X-Forwarded-For header: This mode matches the first IP address on the left carried in the X-Forwarded-For header of user requests. This IP address is the real IP address of clients, regardless of whether a proxy server is used between the clients and CDN PoPs.
Example: Assume that the real IP address of a client is 10.10.10.10 and the IP address of a proxy server is 192.168.0.1.
- If the proxy server is not used:
- Value of X-Forwarded-For in the user request = 10.10.10.10
- Real IP address of the client (the first IP address on the left carried in the X-Forwarded-For header) = IP address for connecting the client to CDN PoPs = 10.10.10.10
- If the proxy server is used:
- Value of X-Forwarded-For in the user request = 10.10.10.10,192.168.0.1
- Real IP address of the client (the first IP address on the left carried in the X-Forwarded-For header) = 10.10.10.10
- IP address for connecting the client to CDN PoPs = IP address of the proxy server = 192.168.0.1
- Real IP address of the client (the first IP address on the left carried in the X-Forwarded-For header) ≠ IP address for connecting the client to CDN PoPs
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot