Contact Us Anytime: +357 25104256
Rules Engine
illustration
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.

RULES ENGINE IN-DEPTH

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.

rules engine

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:

Conditional Expression
Description
IF
An IF expression is always a part of the first statement in a rule. It determines the first condition that has to be met. If the specified match condition is not met, then no features defined in this rule will be applied to the request.
AND IF
An AND IF expression can only appear after an IF or another AND IF expression. It indicates that there is another condition that must be met for the initial IF statement.
ELSE IF
An ELSE IF expression specifies an alternative condition that must be met before a set of actions (i.e., features) specific to this ELSE IF statement takes place. The presence of an ELSE IF statement indicates the end of the previous statement.
The only conditional expression that can be placed after an ELSE IF statement is another ELSE IF statement. This means that an ELSE IF statement can only be used to specify a single additional condition that has to be met.


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:



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



rules engine

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.

rules engine

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

rules engine

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.

rules engine

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:

rules engine

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.

Value
Result
Enabled
When enabled, this option causes all requests that satisfy the matching criteria to be rejected with a "403 Forbidden" response.
Disabled
When disabled, this option restores the default behavior. The default behavior is to allow the origin server to determine the type of response that will be returned.


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.

Option
Description
Kbytes per second
The customer sets this option to the maximum bandwidth (Kb per second) that may be used to deliver the response.
Prebuf seconds
The customer sets this option to the number of seconds that our edge servers will wait until throttling bandwidth. The purpose of this time period of unrestricted bandwidth is to prevent a media player from experiencing stuttering or buffering issues due to bandwidth throttling.


rules engine

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

Value
Result
Enabled
When enabled, this causes all requests to fall through to the origin server, even if the content was previously cached on edge servers.
Disabled
When disabled, this option restores the default behavior. By default, edge servers cache assets according to origin response header information.


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.

Internet Media Type
Description
text/plain
Plain text files
text/html
HTML files
text/css
Cascading Style Sheets (CSS)
application/x-javascript
Javascript
application/javascript
Javascript


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:



Value
Result
Enabled
When enabled, this option indicates that the request is eligible for Edge Optimizer processing.
Disabled
When disabled, this option restores the default behavior. The default behavior is to deliver content over the ADN platform without any additional processing.


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

Value
Result
Enabled
Requests can be redirected.
Disabled
Requests will not be redirected.


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


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.

Value
Result
Enabled
Allows an HTTP client's no-cache requests to be forwarded to the origin server, and the origin server will return the response headers and the body through the edge server back to the HTTP client.
Disabled
Restores the default behavior. The default behavior is to prevent no-cache requests from being forwarded to the origin server.


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.

Value
Result
Enabled
Requests can generate partially cached content.
Disabled
Requests can only generate a fully cached version of the requested content.


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.

Value
Result
Enabled
Stale content will be served to the requester when an error occurs during a connection to an origin server.
Disabled
The origin server's error will be forwarded to the requester.


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.

Value
Result
Enabled
When enabled, this option will protect the requested content with Token-Based Authentication. Only requests from clients that provide a valid token and meet its requirements will be honored. FTP transactions are excluded from Token-Based Authentication.
Disabled
When disabled, this option restores the default behavior. The default behavior is to honor all requests.


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.

Rules Engine

URL Redirect redirects requests via the Location header.



URL Rewrite rewrites the request URL.

Try our features with a no commitment test account
OTHER SERVICES
Application Delivery Accelerate delivery of web applications and non-static content.
Caching Our delivery and acceleration services will lead you to the world's digital threshold, from complete websites to mobile.
Analytics Full and instant visibility into performance of the content and the user experience.
Download Manager Your files are delivered globally with super-fast speed, intelligence and flexibility.
Security Protect your applications and content from unauthorized use with the powerful security tools.
Edge Optimizer Powered by Google PageSpeed, Edge Optimizer keeps your application's data and logic off of your network.
Streaming We will deliver better than anyone else your Flash, Silverlight, or HTTP – live or on-demand.
Storage It is more than just CDN storage. Security, replication, and caching infrastructures really mean massive scale at ultra-fast rates of speed.
Rules Engine With our powerful tool you have the whole control over when, how and if the content is served and delivered.
Piranha Purge Better caching flexibility, efficiency, and performance with Piranha Purge.

High-performance CDN solutions are costly?NOT ANYMORE!

Unprecedented INXY promo will get
you Premium-class CDN
from

for as low as $10/TB!contact us now