In June, Limelight expanded self-service configuration for customers using Website and Application Acceleration to include the ability to apply Rules at the Edge to configurations. Customers can now benefit both from the speed of self-service and the customized power of using rules to accomplish specialized actions at the network edge.
Limelight supports a large number of standard configurations for website and app acceleration content, and this allows customers to tailor the delivery of content to their specific needs. But sometimes more powerful and customer-specific logic is needed to be successful.
At Limelight, this is accomplished via what we refer to as Rules at the Edge. Rules at the Edge are customer-specific and often content-specific rules that are executed in real time as content is requested by users.
How Rules Work
Rules can be triggered when a request or response meets pre-defined conditions, such as a pattern match with:
- The URL, file name or query term
- The IP address
- The value of a specified HTTP header
- A cookie
- The geographic location of a request (using the IP address)
Customers can also control when rules are executed and have 4 distinct choices of where in the flow of requests and responses a rule is applied:
- Rule on Edge Request
- Rule on Origin Request
- Rule on Origin Response
- Rule on Client Response
In summary, think of rules as a series of if-this-then-that type logic that:
- Has as its input all of the information contained in the request header or cookies.
- Can further lookup or transform information- e.g. convert an IP address into the country or state or even zip code that it represents.
- Can write back changes to the header such as appending text to the path of the object requested or directing the request to a different origin server, or writing a value into a cookie.
Can do one thing or a combination of these things and more based on the business needs.
Some Examples of Using Rules
All of this sounds pretty theoretical, so let's review some real-world examples of how rules are put to use.
- Doing GEO lookups and using the results: Through basic configuration and a feature we call IP Access Control, customers can whitelist or blacklist requests based on the geography of the requester. However, sometimes, a customer wants to use the GEO information to accomplish more than simply allowing or blocking requests and this is where rules can be helpful. For example, say you had a global logistics company that had different content to display based on the country of the requester. Rather than directing the user to some landing page and requiring them to choose a country first, rules can be used to look up the country of the requester and return content specific to that country.
- Working with Cross Origin Resource Sharing (CORS) headers: CORS headers are used to manage and control what content can be sourced cross-origin. Rules at the edge can view the origin specified in a request and, for example, look this up dynamically against a list of ‘approved’ origins. If allowed, the response can contain a allow_origin value of that origin and if not on the approved list it can allow it but redirect the allow_origin header value to a different destination. All of this means rules at the edge can provide custom logic run at the edge to set allow or deny values in CORS headers.
- Manipulating cache keys to optimize content delivery: Using rules to manipulate cache keys can reduce the number of copies of content the edge may need to hold, at the same time increasing cache efficiency, reducing storage requirements, and reducing the amount of traffic back to a customer’s origin. For example, let’s say a family of e-commerce sites are all selling the same item with associated photo and video content. Rules at the edge can be used to translate a series of requests, say for mystore.com/object and thestore.com/object bigstore.com/object, making these requests all point to the same single object regardless of which of many domains are requested.
- Setting content expiration: Sometimes rules are used to assist a customer with managing the expiration times of content. Rules can be used by the edge server to insert a content Time to Live (TTL) value for the content so that this does not have to be managed by the customer or at origin.
- Controlling whether or not cached content should be returned: An example of this would be using rules to override the fact that normally if cookies are associated with a request you might assume the content was dynamic and needed to come from origin. But in some cases you wish to pull the object from cache regardless of the presence of a cookie.
These are just a few of the many possible uses for rules. With the use of a lightweight and efficient scripting language deployed on edge servers, many things are possible. If you think you may benefit from Rules at the Edge, or want more information on types of rules that can be created, please contact your Limelight Account Manager or Solutions Engineer.