Property Configuration logic

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: "The Default Rule"

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.

Default settings apply to everything

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

​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.

More specific wins over less specific

Simply put, "child settings win over parent settings."

Let's imagine you did the following:

  1. 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.

  2. 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.

Last match wins

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:

  1. Match:

    
    path = /Root/
    
    Request Cookie exists
    
    Feature applied is cache = bypass cache
    
    
  2. Match:

    
    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.

Good practice

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.

Plan your configuration ahead of time

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.

Errors, warnings, and informational messages

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.