Property configuration is the heart of your deployment. At this stage, you decide all the details of your content delivery, build-up, and dependencies between them. Explore best practices that may come in handy when you dive deeper into the configuration settings.
Default settings are those that are already present when you first create a configuration, many of which you can modify for all content to which the configuration applies. Obligatory default settings include CP codes and origin behaviors.
Other default settings depend on your product. For example, for one property, the features might include the use of persistent connections, TCP optimizations, and tiered distribution. You would be required to set certain origin options, and it would be strongly recommended that you at least review the default cache instructions for objects fetched from the site.
Property default settings and Akamai network defaults apply to everything served from the origin through Akamai unless you explicitly override the setting in your configuration.
Akamai network defaults are automatically applied, may not show up as default settings, and you may sometimes override them in your configuration.
For example, by default Akamai doesn't honor HTTP Cache-Control headers in determining the caching in its platform servers. But you can use the Caching feature to change that default for particular content.
Simply put, "child settings win over parent settings."
Let's imagine you did the following:
Set a parent rule number 1 to match for all content in the directory,
/images, and all its sub-directories. Using the Caching behavior, you set a max-age of 5 days on this content.
Create a child rule number 2 for all JPG files in the directory, "/images/reduced_for_display". You use the Caching behavior to set a 48-hour max-age on that content.
When a request comes in, the configuration sees a match on both rule 1 and rule 2. Which one does the Akamai server apply? The more-specific child rule wins over the parent. The content is given a max-age of 48 hours.
When working with nested rules, work from more general to more specific behaviors.
When incoming requests match more than one rule (and its not a case of parent-child matches but is simply two parallel settings), the last match in the structure wins.
In other words, when there are multiple matches, the behaviors associated with the bottom-most match apply to the request.
Take a look at these two cases:
path = /Root/ Request Cookie exists Feature applied is cache = bypass cache
path = /Root/ User Location data matches Features applied are change Origin Server, set max-age = 1 hour
If the incoming request matches both these rules, the bottom-most match, which is 2, wins.
You need to pay attention to the order of the rules you set. You can easily drag a rule to a new place, or make a child of another rule. But if you drag a rule to be under an existing rule, remember that the request must match the parent or it will not be evaluated against the child.
The editor 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 your setup is very simple, it's a best practice to plan and map out your desired configuration, set it up in Property Manager, and test it in Test Center or locally with Sandbox.
These three kinds of notifications draw your attention to potential configuration issues:
Errors are screen messages with regard to rules or settings that must be changed, or else you won't be able to activate your property.
Warnings call your attention to settings or rules that may create problems but are not critical for activation. It's best to examine and modify the elements that trigger them.
Informational messages point out possible logic problems. For example, setting one feature may automatically turn on or off another feature, and the informational message lets you know that.
Updated about 1 year ago