Let our Rules Engine do the work for you...
• Specify precise "origin pull" update intervals for each URL or object and reduce bandwidth costs.
• Offload your existing rules to our processing engine and this way reduce load on your origin servers.
• Simplify CDN and web host migrations with portable rules and edge configurations.
• Block hotlinking and other inline leeching and improve content security.
• Completely bypass caching for certain CNAMES or directories and simplify testing and staging.

CONTENT DELIVERY BASED ON RULES ENGINE

You have more precise contol over if, when and how your content is served with our new HTTP Rules Engine. You have literally endless possibilities and still in the end you have more control over cost and security of the delivery of your content. And this precise control over your content delivery on our HTTP Large Object and HTTP Small Object platforms you get witth such a powerful tool as our HTTP Rules Engine. All custom rules that specify how exactly our servers cache and deliver your content you can create from our web-based Media Control Center. As an example, you can see a weather widget: suppose that the weather forecast changes only once per hour. Then you can specify the rule to load the widget from our servers between forecast updates, and only load from origin when the forecast changes. This way origin pulls, server load, and bandwidth costs will be significantly reduced. The same concepts apply to files, folders, extensions, query strings, etc. So reducing the amount of work your origin servers do, you have efficiency and end user response times improved. Also you save your time and money by reducing the burden on your network management personnel. Thus, our HTTP Rules Engine allows to customize your delivery to your exact specifications.

Though the customer is provided with a big variety of options in Media Control Center (MCC) to configure how his assets are handled by our CDN, but still his unique working environment may require an additional customization. For this purpose the costumer is provided also with an interface – Rules Engine - through which he can create custom rules that will override his MCC configuration and the default behavior of our edge servers. These custom rules can be created to handle how our edge servers cache and grant access to large and small assets. In other words, a rule defines the criteria that a request has to meet before one or more features can take effect.



It’s necessary to remember, that if the customer has multiple rules, then a subsequent rule can override the actions specified by a previous rule.

There are three main types of conditional expressions that determine how a set of criteria will be applied to a rule. These conditional expressions are following:



Actions take place as a set of criteria is met. Once a set of criteria has been satisfied, then no additional attempts to match other criteria in the current rule will take place.

If necessary, multiple rules can be created. The major benefit of such multiple rules is a possibility to exercise both coarse and granular control over how requests for your assets are handled. This way the customer can create, for example, a rule that determines the default manner through which all requests are handled. And then a set of rules that determine how certain types of requests are handled for a particular location can be created. But the customer must pay attention to the order in which these rules are listed.

Rules with general criteria should be placed closer to the top of the list, while more detailed criteria should be placed closer to the bottom. This type of configuration allows the customer catch-all rules to assign default handling behavior for his assets without interfering with the manner in which specific types of assets are handled.

HTTP Rules Engine is a very powerful tool that can tailor CDN capabilities to meet specific needs. However, if this tool is improperly applied, then it may not deliver the desired customized capabilities or it might negatively impact data delivery performance for the desired web site. A safeguard to prevent this scenario is an internal review process that is triggered by any of the following actions:

• Creating a rule
• Modifying a rule
• Enabling a rule

Once a rule has been reviewed, it will either be:

• Approved: An approved rule will undergo activation.
• Denied: Contact technical support for the following information:
  • An explanation of why the rule was not approved.
  • Any changes required to make the submitted rule compliant with our standards.
  • Tips and tricks on how to improve the rule to achieve its original intent.

The process of creating a rule through an interface is simple. The first thing that the customer needs to do is decide whether he would like to customize how HTTP Large, HTTP Small, or ADN requests are handled. It’s made by selecting the tab that corresponds to the desired platform and navigate to the Rules Engine tab. The Rules Engine page will display options for creating a rule.



For example, a rule that will override the internal and external max-age settings assigned to assets by the origin server can be created.



The default behavior that ‘s been configured works well for most of the customer’s assets. However, he also has XML and XLS assets that are updated constantly. In order to account for this scenario, the customer will have to create another rule. This new rule will need to provide criteria that will allow our edge servers to identify or match the customer’s XML and XLS assets.



This configuration will cause our edge servers to only check for a new version of an asset from the origin server if five minutes have passed since the asset was originally requested.

And finally another added feature will determine how much time must pass before an HTTP client (e.g., browser) can check for a new version of an XML or XLS asset from an edge server.

Complete created Internal and External Max-age Rules will look like:



HTTP Rules Engine can be used to customize the actions that will take place when content is requested on the customer’s account. For example, he can create a rule that prevents users from a particular country or region from requesting content from a customer origin. Only requests that originate from the specified countries will satisfy this condition. A country can be specified through its country code.

Another feature provided in this tool is "Deny Access (403)." This feature will return a 403 Forbidden status code to the HTTP client whenever a user-defined set of conditions are met.



HTTP Rules Engine can leverage a client's user agent to identify requests that originate from a mobile device. It is able to do so by looking up the client's user agent in the WURFL database. This database contains extensive descriptive information on user agents. This information can be accessed through "capabilities."

Bandwidth Throttling feature of HTTP Rules Engine throttles the bandwidth for the response provided by our edge servers. Both of the following options must be defined to properly set up bandwidth throttling.





Bypass Cache feature determines whether the request can leverage our caching technology.



This feature can be useful for setting up staging directories where content is always fetched from the origin server.

Compress File Types feature defines the file formats that will be compressed on the server. A file format can be specified using its Internet media type (i.e., Content-Type). Internet media type is platform-independent metadata that allows our servers to identify the file format of a particular asset. A list of common Internet media types is provided below.



Edge Optimizer feature determines whether Edge Optimizer can be applied to a request. If this feature has been enabled, then the following criteria must also be met before the request will be processed by Edge Optimizer:

• The requested content must use an edge CNAME URL.
• The edge CNAME referenced in the URL must correspond to a site whose configuration has been activated in a rule.

Follow Redirects feature determines whether requests can be redirected to the domain defined in the Location header returned by a customer origin server.



H.264 Support (HTTP Progressive Download) determines the types of H.264 file formats that may be used to stream content.

• The customer defines a space-delimited set of allowed H.264 filename extensions in the File Extensions option.
• The customer must make sure to include a period when specifying each filename extension (e.g., .mp4 .f4v).

Progressive Download supports MP4 and F4V media by default.

Honor No-Cache Request determines whether an HTTP client's no-cache requests will be forwarded to the origin server. A no-cache request occurs when the HTTP client sends a Cache-Control:no-cache and/or Pragma:no-cache header in the HTTP request.



Though for all production traffic, it is highly recommended to leave this feature in its default disabled state. Otherwise, origin servers will not be shielded from end-users who may inadvertently trigger many no-cache requests when refreshing web pages, or from the many popular media players that are coded to send a no-cache header with every video request. Nevertheless, this feature can be useful to apply to certain non-production staging or testing directories, in order to allow fresh content to be pulled on-demand from the origin server.

Maximum Keep-Alive Requests feature defines the maximum number of requests for a Keep-Alive connection before it is closed. Setting the maximum number of requests to a low value is strongly discouraged and may result in performance degradation. Default Value: 10,000 requests

Partial Cache Sharing feature determines whether a request can generate partially cached content. This partial cache may then be used to fulfill new requests for that content until the requested content is fully cached.



Prevalidate Cached Content determines whether cached content will be eligible for early revalidation before its TTL expires. It's used to define the amount of time prior to the expiration of the requested content's TTL during which it will be eligible for early revalidation.

Set Client IP Custom Header feature allows the IP address of the requesting client to be added to the request as a custom request header. The name of the request header in which the IP address will be saved is determined by the value assigned to the Header name option. If a header name value is not specified, then this value will be stored in a request header called "True-Client-IP."

This feature allows a customer origin server to find out client IP addresses through a custom request header. If the request is served from cache, then the origin server will not be informed of the client's IP address. Therefore, it is recommended that this feature be used with ADN or assets that will not be cached.

Stale Content Delivery on Error feature determines whether expired cached content will be delivered when an error occurs during cache revalidation or when retrieving the requested content from the customer origin server.



Stale While Revalidate feature allows our edge servers to serve stale client to the requester while revalidation takes place. The purpose of this feature is to improve performance.

Token Auth determines whether Token-Based Authentication will be applied to a request. If Token-Based Authentication is enabled, then only requests that provide an encrypted token and comply to the requirements specified by that token will be honored.



Also Rules Engine allows the customer to override an existing CDN configuration. For example, a rule that disables Token-Based Authentication for all HTML assets can be created. This type of rule would bypass the check for Token-Based Authentication even when the requested HTML assets are in a secured directory.



URL Redirect redirects requests via the Location header.

• The configuration of this feature requires setting the following options:
  
  Option

  Description

  Code

  The customer selects the response code that will be returned to the requester.

  Source & Pattern

  The customer defines the source path that must be matched. This configuration consists of:
  1. Selecting a domain or customer origin.
  2. Defining a regular expression pattern that identifies requests by URL. This regular expression pattern can either define a relative path or the full request URI.

  Destination

  The customer defines the URL to which the above requests will be redirected. This URL can be dynamically constructed through the use of HTTP variables.
  
  

URL Rewrite rewrites the request URL.

• The configuration of this feature requires setting the following options:
  
  Option

  Description

  Source & Pattern

  The customer define the source path that must be matched. This configuration consists of:
  1. Selecting a domain or customer origin.
  2. Defining a regular expression pattern that identifies requests by URL. This regular expression pattern can either define a relative path or the full request URI.

  Destination

  The customer defines the URL to which the above requests will be rewritten. This URL can be dynamically constructed through the use of HTTP variables.
  
  
• The customer must make sure that the request path defined in the Source option doesn't conflict with the match options that have been defined in the current rule.
• This feature allows our edge servers to rewrite the URL without performing a traditional redirect. This means that the requester will receive the same response code as if the rewritten URL had been requested.