How to structure a rule

A policy takes the form of rules composed of matches and applicable behaviors. The match criteria must be set first, followed by the desired behaviors to apply. You need to know how to properly format a rule.

Once the criteria set in a match is met, associated behaviors are applied to a request. You can nest matches in an individual rule, and you can have multiple behaviors in a single rule. You can also include multiple rules—match and behavior combinations—in a single policy.

The format for an individual rule in a policy follows a specific format:

{
    "rules" : [
        "matches" : [
            { 
                <match criteria>
            }
         ]
         "behaviors" : [
             {
                 <behaviors>
             }
         ]
    ]
}

Example rule

This policy contains a single rule set, that denies access to all .jpg, .gif, and .png files requested from any IP address other than 198.18.48.211.

{
    "rules" : [
        {
            "matches" : [
                {
                    "name" : "url-extension",
                    "value" : "jpg gif png"
                }
            ],
            "behaviors" : [
                {
                    "name" : "ip-whitelist",
                    "value" : "198.18.48.211"
                }
            ]
        }
    ]
}

You can negate match conditions

All matches can be negated (inverting from “must match” to “must not match”) by adding a "negated": true attribute to the match condition.

The "negated": element is available with each match condition. It is optional, and its default setting is false. So, you don't need to include “negated”: false in your matches.

For example, if you want to apply behaviors to all paths that are not in either /path1/* or /path2/* then you could use the following negated match condition:

"matches" : [ 
    {
        "name" : "url-path",
        "value" : "path1 path2",
        "negated" : true
    }
]

Rule application and precedence

Rules are applied from the top down. The more precise the match criteria, the more important it is to ensure that subsequent rules do not alter the behavior in unexpected ways. Therefore, the more specific the criteria, the farther down in the list of rules it should be placed.

For example, let's assume you have a caching match/behavior combination that exists at the top of your rules listing that does the following:

  • Match criteria: It matches on a "/static/*" URL wildcard and on URL extensions (for example “png gif jpg)
  • Behavior: A caching TTL is set for this content of one day (1d).

If you were to add a separate caching match/behavior combination farther down in the JSON, that uses the same “/static/*” URL wildcard pattern, and set a caching TTL of one hour (1h), then the first combination would never be applied, because this second combination is a more generic set of match conditions, and would take precedence.