Your rule configuration consists of rule sets, each of which can contain one or more rules. Using drop and drag functionality, you can reorder rule sets within your configuration, as well as individual rules within a rule set. You can see your environment’s rule configuration in the Rules tab.

Processing order

A rule configuration works from the top down, with the bottom-most rules taking precedence over the top. It is considered a best practice to build out a rule configuration from more general to more specific, top to bottom.

📘

Plan your configuration ahead of time

Delivery Manager can’t prevent you from defining matches for content that doesn’t exist on your origin, redirecting the wrong content to the wrong origins, or generating other errors. Unless you’re working with a simple setup, it’s recommended to plan and map out your desired rule configuration beforehand, making sure to test it before activating to the production network.

If a request matches more than one rule, there are two resolution strategies that can apply:

Mutually exclusive logic

Rule conflicts are resolved by replacing one behavior logic with another. Behaviors associated with the bottom-most match get applied to the request. For example, consider these two matches:

1. path = /Root/
   Request Cookie exists  
   Feature applied is cache = bypass cache

   
   

2. path = /Root/
   User Location data matches  
   Features applied are change Origin Server, set max-age = 1 hour

If the incoming request matches both rules, the bottom-most match, number 2, wins out.

Complimentary logic

Rule conflicts are resolved by merging one behavior logic with another. In this scenario, logic from all applicable behaviors add up, so you can set them to do different things. For example, you can modify one HTTP header and then another one.

In general, if a rule has more than one match or more than one behavior relating to similar request components, the more specific of the options gets applied.

Nested rules

A rule set can include rules within rules up to three levels deep. This strategy uses a parent/child relationship to determine what gets executed, where the top-level rule is the parent, and the nested rule is the child.

Rule behaviors only execute if the request matches the specified criteria. When you nest a rule within another rule, you are adding a strict dependency. Nested rules follow the following logic:

• Parent first. A child rule is evaluated only if a request matches the parent rule.
• Parent only. If a request matches the parent but not the child, only the parent rule executes. You can’t match a child rule without also matching its parent.
• Both parent and child. If a request matches both the parent and child rules, both behaviors are executed using general logic that also applies to parallel rules. The general mutually exclusive logic–where bottom-most match wins–translates to a child rule winning.

Example

1. You set a parent rule, Rule 1, to match for all content in the directory /images and all of its sub-directories. Using the Caching behavior, you set a max-age of 5 days on the content.
2. You create a child (or nested) rule, Rule 2, for all JPG files in the sub-directory /images/reduced_for_display. You again use the Caching behavior to set a 2 day max-age on that content.
3. When a request comes in, the configuration sees a match on both Rule 1 (parent) and Rule 2 (child). It is determined that the more specific child rule, Rule 2, wins over the parent. The content is given a max-age of 2 days.

Using this example as a best practice template, it is recommended to work from more general to more specific behaviors.