Set optional conditions based on which the accompanying behaviors execute.
Matches available for your property depend on your product and additional modules.
Rules may specify an optional set of matches that are the IFs in your configuration. They impose certain conditions on the incoming client requests, or in some cases on the responses from the origin. If these conditions are met, the behaviors within the same rule execute. To add matches within your rule, in the Configuration panel click Add Match.
Matches help you narrow down the cases when certain behaviors should apply. Maybe you'd like to deny access to certain end users based on their IPs? Or filter requests from mobile devices to serve alternate content? In such situations, matches come in handy.
The stage is the point in the processing that the match applies to. For example, when the request comes in from the end user client, that is a request stage. When the response comes back from the origin, that is a response stage.
Some behaviors don't work with certain matches because of the potential stage incompatibility. For example, you can't set an origin (to which edge servers will send this request) based on a response code already received from an origin.
Each match includes a true/false operator to identify particular types of requests of responses. You can also invert the result, so that the criteria succeeds if specified values don't match.
Matches may also consist of additional operators that filter other types of data, such as the request protocol or query string parameter.
When you build a rule, you can use a single match or a combination of matches to create different logic. For example, your rule can read: "all requests must match" (A and B and C and D), or "any request must match" (A or B or C or D).
For some matches, when you specify a value, you can configure case sensitivity options and boost match flexibility with wildcards. Use
?to replace a single character and
*for multiple characters.
Updated 6 months ago