Before one or more custom actions may be applied to CDN traffic, the type of traffic that will be affected must be defined within a rule. Setting this up involves choosing:
- The logic through which requests will be identified.
- The criteria for identifying requests (i.e., match conditions).
Request Matching Logic
The initial step for defining how requests are identified is to choose how matchRules Engine: Defines a prerequisite that must be met before one or more actions (i.e., features) may be applied to a request. conditions will be interpreted.
| Type | Description |
|---|---|
|
Use this type of section (i.e., Select First Match) when a match should only be found when a request satisfies the first match condition out of a set of competing match conditions. A mutually exclusive section that identifies requests by country is illustrated below. This configuration will apply different actions according to the request's origin (i.e., United States or Canada).
As illustrated below, additional competing match conditions may be added by clicking + ELSE IF.
|
|
|
This type of match statement is processed independently from all other statements. As a result, it makes it possible for a request to apply multiple features (i.e., custom actions) based off of various match conditions. Unlike a mutually exclusive match section (aka Select First Match), this type of statement does not have an identifying label. SiblingsIn this context, siblings refers to match conditions at the same level in the rule hierarchy. within an independent statement cannot be set to the same match condition. Set up this type of configuration by using a mutually exclusive statement instead. In the following illustration, notice that the Country match condition is unavailable when configuring the match condition at the bottom of the rule. A rule containing two independent match conditions is illustrated below. In this scenario, a request that is submitted by an Android device from within the United States will satisfy both match conditions. Therefore, the response will contain both the Country and the Android headers.
|
Mutually Exclusive Match Section (Select First Match)
A Select First Match section treats match conditions defined at its root level as mutually exclusive. The following illustration shows two match conditions at the root of a Select First Match section. Only the features associated with the first successful match will be applied to a request. All subsequent match conditions will be ignored.
Independent statements may be added within a mutually exclusive section. This type of setup allows additional features (i.e., custom actions) to be applied to qualifying requests. In the following illustration, notice the following:
- If a request is made from the United States, then a Country response header set to "United States" will be applied to the response.
- Additional features may be applied to request if the request was either made from an Android device or if the referrer is "sales.mydomain.com."
- The last match condition (i.e., Request Method = POST) will be ignored for requests made from the United States, since those requests are handled by the first branch in the Select First Match section.
Key information:
- A "Select First Match" label and a dark blue left border identifies a Select First Match section.
- A rule can only be assigned a single mutually exclusive (aka Select First Match) section.
- Although the set of features that will be applied to a request is limited to the first successful match within a Select First Match section, additional features may be applied to a request as a result of an another rule or an independent match statement located outside of the Select First Match section.
To add a mutually exclusive match statement
- Create or modify a rule.
-
From the desired position in the rule, click
and then select "Select First Match."
A blank Select First Match section will appear. Make sure to define at least one match condition and feature for both the IF and the ELSE IF statements.
Independent Match Statement
Each independent match statement is processed independently from all other match statements. This allows a request to satisfy multiple match statements.
An independent match statement is any IF statement that is not located at the root of a Select First Match section.
Key information:
-
Greedy Matching: A request will try to satisfy as many independent match conditions as it can.
The features associated with all successful match conditions will be applied to the request.
- Nested Match Conditions: Greedy matching also applies to nested match conditions. However, the prerequisite for a successful match is that the request must also satisfy the parent match condition.
View example.
Both of the following scenarios illustrate that match conditions are processed separately. The second scenario also illustrates that a nested match condition is processed independently from other nested match conditions.
Scenario #1:
Sibling match conditions allow multiple actions (i.e., features) to be applied to qualified requests. In this scenario, we will examine how actions are applied to requests for the following rule:
IF Match Condition A
Feature x
IF Match Condition B
Feature z
A request will trigger action(s) by satisfying any of the following match conditions:
| Match Condition(s) | Resulting Action(s) |
|---|---|
|
A |
x |
|
B |
z |
|
A + B |
x + z |
Scenario #2:
Nested match conditions provide more control over when actions (i.e., features) will be applied to requests. In this scenario, we will examine how actions are applied to requests for the following rule:
IF Match Condition A
Feature w
IF Match Condition A1
Feature x
IF Match Condition A2
Feature y
IF Match Condition B
Feature z
A request will trigger action(s) by satisfying any of the following match conditions:
| Match Condition(s) | Resulting Action(s) |
|---|---|
|
A |
w |
|
A + A1 |
w + x |
|
A + A2 |
w + y |
|
B |
z |
Exception:
If the same feature will be applied to the request by multiple match conditions, then precedence will be granted to the last match condition.
View example.
The rule illustrated below shows 3 match conditions that define the same feature (i.e., Modify Client Response Header).
If a request satisfies all 3 match conditions, then only the second and third instances will be applied to the request. Specifically, the Type response header will be set to"Web Site - Sales" and the My-Custom-Field response header will be excluded from the response.
To add an independent match statement
- Create or modify a rule.
-
From the desired position in the rule, click
and then select "Match."
A blank IF statement will appear. Make sure to assign a match condition and at least one feature to it.
Conditional Expressions
A conditional expressionRules Engine: Refers to the logic (i.e., IF and ELSE IF) through which one or more match conditions identify a type of request. identifies the start of a statement that defines a match condition and one or more features.
Valid conditional expressions are defined below.
| Conditional Expression | Description |
|---|---|
|
|
The meaning of an IF conditional expression varies according to whether it is at the root of a Select First Match statement.
An IF statement may be nested under an IF or ELSE IF statement. This type of setup defines an additional match condition that must be met before the set of features associated with that nested match condition may be applied to a request. |
|
|
The ELSE IF conditional expression is only applicable within a Select First Match section.
|
Match Conditions
The purpose of a match condition is to identify a request. A request may be identified by a variety of criteria (e.g., URL, IP address, request metadata, etc.).
A match condition is defined directly after a conditional expression.
Categories
Setting up a match condition involves selecting a category and then the desired match condition. Each available category is described below.
| Category | Description |
|---|---|
|
General |
This category contains the "Always" match condition. Use this match condition to define a default set of actions that will be applied to all requests. |
| This category contains match conditions that identify requests based on its properties (e.g., IP address, cookie, referrer, and header values). | |
|
This category contains match conditions that identify requests that originate from a mobile device. |
|
|
This category contains match conditions that identify requests that originate from a specific network or geographical location as defined by ASN or country. |
|
|
This category contains match conditions that identify requests based on the request URL. |
|
|
This category contains match conditions that identify requests based on the origin server from which content is being requested. |
Default Request Handling
One easy way to ensure that all requests to your assets are granted a default behavior is to create a rule that starts with an IF statement set to the Always match and the type of actions that should take place.
Key information:
-
Override or supplement the default behavior by:
-
Adding sibling match conditions to the same rule.
These additional statements cannot be nested under the Always match condition. This type of setup is illogical, since an Always match condition should be applied by default to all requests.
- Adding another rule.
-
- Multiple Rules: If there are multiple rules, it is recommended that the rule containing the Always match condition be placed at the very top of the list of rules.
It is not recommended to place a rule containing the Always match below a rule with a conflicting feature. This type of configuration will make the conflicting portion of your other rule irrelevant.
Learn more.
Edgecast CDN