Rules Engine
Scenario
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:
- When the CDN PoP configuration cannot apply to specific resources, for example, when the access control conditions of some resources are different from the global configuration.
Precautions
- To use the rules engine, submit a service ticket.
- You can add up to 10 rules for a domain name.
- 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 contain any value of the condition.
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 |
---|---|---|---|---|---|
Protocol type |
Protocol used by client requests, for example, HTTP or HTTPS |
N/A |
|
|
N/A |
Request method |
Method used by client requests, for example, GET or PUT |
N/A |
|
GET, POST, HEAD, PUT, DELETE, OPTIONS, PATCH, TRACE, and CONNECT |
N/A |
URL path |
Path in client request URLs, excluding request 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 |
Header 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 parameter 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 |
|
.txt, .doc, .html, .jpg, .png, .svg, .zip, and .rar. You can select multiple extensions. |
By default, Case sensitive is enabled. When it is disabled, uppercase and lowercase values are considered equal. |
Client IP address |
Client IP address |
|
|
The value can be an IPv4 address (for example, 0.0.0.0), an IPv6 address (for example, 240e:95c:3004:2:3:0:0:XXX), or a CIDR block (for example, 192.168.XXX.XXX/31). |
N/A |
Client IP version |
IPv4 or IPv6 |
|
|
|
N/A |
Nginx Var |
If all the preceding conditions cannot meet the requirements, you can use these Nginx variables: $protocol, $arg_, $http_, $scheme, $uri, $ssl_protocol, $ssl_server_name, $remote_addr, $http2, and $request_method. |
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 configuration |
The configuration must be the same as that of HTTP Headers for CORS in 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. Origin URLs to rewrite can be matched by All files or Wildcard. |
|
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. |
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 and 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 and 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 and 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 and 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