3. Match Rules

Match rules are the core of the service image. They provide the criteria for evaluating requests and responses and when matched, specify one or more actions (e.g., setting cache expiration, calling geo definitions, content/header processing modes, etc.) for the system to take.

Match rules are grouped within match groups. After a request matches a match rule within a match group, all further match rule processing stops. (Requests cannot be evaluated against multiple match groups or match rules at this time.)

There are currently two types of match groups:

  • Match groups with “ID:” 0 contain a series of match rules matching on “expression”: “$id.minor == <OriginID>”, which contain only features that apply to all requests to hosts within the OriginID.
  • Match groups whose numeric IDs are OriginIDs (e.g., “ID:” 1234), which contain match rules matching on “expression”: “<URIpathRE>” where <URIpathRE> can be a regex.

There should be one match group per OriginID plus one match group 0 for all OriginID rules. This restriction is temporary as the Caching Nodes only understand per-property configurations. This representation allows the platform config generation process to create per-OriginID platform configuration files for consumption by the Cache Nodes.

Each match rule within a match group is expected to have a match rule ID that can be used to order rules. Match rules within a given match group have a first-match-wins semantic. match groups cannot be ‘chained’ together at this time given the one-match-group-per-property restriction.

In order for the match rule to be ‘matched’, the expression has to evaluate to true in the “expression”: element. At this time, the only supported expression is implied and performed against the received URI. The URI contains the requested path without query strings. Operators within the expression are:

== - Equality test
%= - Equality test (case insensitive)
*= - Glob test
%* - Glob test (case insensitive)

Note: All operators may be inverted by prepending “!” (not); for convenience, “!=” is a synonym for “!==”.

Each match rule may specify one or more settings (e.g., setting cache expiration, cache key manipulation, content/header processing modes) directly – the set of flagNames and their associated values are described in their respective sections.

These relationships are illustrated in the following figure:

../_images/MR-EntityDiagram.png

Changed in version 19.1: Updates to use OriginID instead of ReportingID for Match Rule definitions.