Combining Matches and Behaviors
1 Rule, 2 Matches, 1 Behavior
Match on URI extension "jpg", "gif" or "png" and request method GET and apply IP whitelist. This will deny all IPs except 198.18.48.211 and 198.18.48.212 access to these objects using the GET method.
{
"rules": [
{
"matches": [
{
"name": "url-extension",
"value": "jpg gif png"
},
{
"name": "http-method",
"value": "GET"
}
],
"behaviors": [
{
"name": "ip-whitelist",
"value": "198.18.48.211 198.18.48.212"
}
]
}
]
}
2 Rules 2 Matches, 2 Behaviors
The following example shows two rules, each with two match conditions and two behaviors. The first rule matches on URI extension "jpg", "gif" or "png" and request method GET and applies both and IP whitelist and a referrer blacklist; only requests from 198.18.48.211 and 198.18.48.212 are allowed, unless they also have a Referer header value containing "abcd.com".
The second rule matches all GET requests for the url scheme "HTTP" and applies both and IP whitelist and a referrer blacklist; only requests from 198.18.48.215 and 198.18.48.216 are allowed, unless they also have a Referer header value containing "www.abc.com".
{
"rules": [
{
"matches": [
{
"name": "url-extension",
"value": "jpg gif png"
},
{
"name": "http-method",
"value": "GET"
}
],
"behaviors": [
{
"name": "ip-whitelist",
"value": "198.18.48.211 198.18.48.212"
},
{
"name": "referer-blacklist",
"value": "*abcd.com*"
}
]
},
{
"matches": [
{
"name": "url-scheme",
"value": "HTTP"
},
{
"name": "http-method",
"value": "GET"
}
],
"behaviors": [
{
"name": "ip-whitelist",
"value": "198.18.48.215 198.18.48.216"
},
{
"name": "referer-blacklist",
"value": "*www.abc.com*"
}
]
}
]
}
Conflicting/Undefined Behaviors)
Match on URI extension "jpg", "gif" or "png" and request method GET and apply both an IP whitelist and IP blacklist. This will deny all IPs except 198.18.48.211 and 198.18.48.212 access to these objects. Because 198.18.48.213 and 198.18.48.214 do not match the white list they are already denied. This creates an undefined behavior.
{
"rules": [
{
"matches": [
{
"name": "url-extension",
"value": "jpg gif png"
},
{
"name": "http-method",
"value": "GET"
}
],
"behaviors": [
{
"name": "ip-whitelist",
"value": "198.18.48.211 198.18.48.212"
},
{
"name": "ip-blacklist",
"value": "198.18.48.213 198.18.48.214"
}
]
}
]
}
A more practical use case might be to match on URI extension "jpg", "gif", or "png" and request method GET and apply a geographic restriction, but where an IP whitelist allows otherwise blocked clients to access the content.
The following example will deny all clients inside the United States, except IPs 198.18.48.211 and 198.18.48.212 have been explicitly granted access to these objects.
{
"rules": [
{
"matches": [
{
"name": "url-extension",
"value": "jpg gif png"
},
{
"name": "http-method",
"value": "GET"
}
],
"behaviors": [
{
"name": "geo-blacklist",
"type": "country",
"value": "US"
},
{
"name": "ip-whitelist",
"value": "198.18.48.211 198.18.48.212"
}
]
}
]
}
Overlapping Behaviors)
Rule order is important because of the possibility of creating overlapping rules. Rule order is most important when the behaviors overlap. Practically, this means that keeping track of the match conditions within a given "rules" collection is required, and the more restrictive a set of match conditions is, the later it should appear in the collection.
For example, if there is a generic match for a "jpg" file extension that defines a TTL of 7 days and another match that includes both a path like "/images/*" and a file extension match for "jpg" that defines a TTL of 1 day that the second rule should appear after the first. Putting the less complex rule later in the list would override all previous matches and the related behaviors. In this example, if the order were reversed the Edge server would use a 7 day TTL, regardless of whether or not the "jpg" object was requested using the "/images/*" path.
Following is an example of a properly-constructed rules collection for the above scenario:
{
"rules": [
{
"matches": [
{
"name": "url-extension",
"value": "jpg"
}
],
"behaviors": [
{
"name": "caching",
"type": "fixed",
"value": "7d"
}
]
},
{
"matches": [
{
"name": "url-extension",
"value": "jpg"
},
{
"name": "url-wildcard",
"value": "/images/*"
}
],
"behaviors": [
{
"name": "caching",
"type": "fixed",
"value": "1d"
}
]
}
]
}
If, on the other hand, there is no overlap in behavior, then the order is irrelevant. Consider the case where the "/images/*" path and "jpg" file extension match are used to define a TTL, but another rule has a match for "jpg" that applies a geographic blacklist behavior for, say, North Korea. Because the two rules do not share behaviors, the less restrictive rule is safe to place later in the list.
Here is an example where the rule order does not matter because there is no overlap in behavior:
{
"rules": [
{
"matches": [
{
"name": "url-extension",
"value": "jpg"
}
],
"behaviors": [
{
"name": "geo-blacklist",
"type": "country",
"value": "KP"
}
]
},
{
"matches": [
{
"name": "url-extension",
"value": "jpg"
},
{
"name": "url-wildcard",
"value": "/images/*"
}
],
"behaviors": [
{
"name": "caching",
"type": "fixed",
"value": "1d"
}
]
}
]
}