• Edge Application
• Rules Engine

Rules Engine is an Edge Application feature that handles the conditional execution of behaviors through logical operators. By using Rules Engine, you can build an architecture that provides better performance to your users while consuming fewer resources by processing at the edge.

Each request made to an application built with Azion Real-Time Manager (RTM) is processed in a fixed sequence of two phases:

1. Request Phase: takes place when a user submits a request to the edge application.
2. Response Phase: occurs when a user receives a response from the edge application.

At each processing phase, you can define a set of rules to handle the request according to the needs of your application. Once you’ve selected in which of the two phases your rule will be executed, you’ll be able to create a new rule.

Rules are designed to follow a conditional if-then logic. Every rule is composed of Criteria (if) that will define the set of conditions that must be met for the execution of Behaviors (then).

To trigger the intended behaviors for your application, you may employ variables, comparison operators, and logical operators. If the given conditions are met, the behaviors associated with each rule are executed sequentially until all the rules have been processed.

When creating a rule, you’ll be prompted to select one of the two available processing phases: Request Phase or Response Phase.

During the Request Phase, the edge handles end-user requests. For Request Phase rules, any variables associated with the data provided by the user in the request can be utilized. However, variables related to the content that will be delivered to the user in this phase aren’t accessible, as the response hasn’t been processed by the application yet.

Additionally, it’s in the Request Phase that you determine how your application will cache the content. If your application doesn’t permit any form of caching, you have the option to define the conditions under which caching should be disregarded.

During the Response Phase, your application delivers data to end-users. All handling processes in this phase are dynamic, and each user’s delivery is performed independently based on their specific requirements.

Aside from the name of the rule, you can add a description to your rule using the Description field. Your description will be visible from the rule list and can be used to help you identify what the rule does.

The Criteria section of Rules Engine is where you define the conditions for executing the rule. Criteria are composed of:

• variables
• comparison operators
• arguments, when applicable

The inclusion of arguments in a criteria depends on the comparison operators chosen. The format of the arguments is described in the variables and comparison operators sections below. You can also add logical operators to increase the amount of comparisons that the rule will execute.

For example, this criteria identifies whether a user is accessing your application via a desktop web browser using a regular expression as an argument:

Check the full list of variables available and their processing phase:

Add these variables inside the Rules Engine of your edge application to configure Mutual Transport Layer Security (mTLS). mTLS variables are only available for the Request Phase.

For behaviors that require an argument, you can use the same variables available for the processing phase in which they’re available. This way, you can, for example, compose cookies or HTTP headers using data collected during the request phase, such as the user’s device group or their geolocation.

For example, for the following rule in the Response Phase:

If ${host} is equal myhost.com Then Add Response Cookie cookie-host-value=${host}

When this rule is active, if the request is made from the host determined in the criteria, the response will return the following header: Set-Cookie: cookie-host-value=myhost.com.

Azion also provides special variables that act as functions and take arguments. The following variables can be used to compose Behavior arguments:

Multiple criteria can be defined using the logical operators AND and OR. Each rule can have up to 10 criteria.

The operator AND has implicit precedence over the operator OR. If explicit precedence is required, you can add more criteria groups using the AND operator only.

In the Behaviors section of the Rules Engine, you must add the behaviors you want your rule to perform if the conditions defined in the criteria are met.

For example, this behavior redirects the user to an English version of an FAQ location:

Each rule can perform up to 10 behaviors.

Request Phase Response Phase Requires Application Acceleration

Allows you to add a cookie in the Set-Cookie HTTP header. The cookie must be inputted as an argument in the format cookie-name=cookie-value. You may use a variable as a cookie value in the format cookie-name=${arg_cookie}.

For cookies in the Response Phase, the following Set-Cookie policies can be added to the argument, after the cookie value and separated by a semicolon (;):

• Expires=date (EEE, d MMM yyyy HH:mm
  Z)
• Domain=domain-value
• Path=path-value
• Max-age=number (TTL in seconds, takes precedence over Expires)
• SameSite=value; Secure
• HttpOnly

Multiple policies for the same cookie can be separated by semicolons (;). For example: cookie-name=cookie-value; Domain=domain-value; Path=path-value; SameSite=value.

You may also use variables as a cookie or policy value, for example: Path=${uri}; Domain=${host}.

Adds a header field to the request that will be sent to the origin or to the response that will be sent to the user.

The header field must be informed as an argument in the format Field: value.

Request Phase Requires Application Acceleration

Defines that Azion shouldn’t cache the response from its origin. The execution of this rule has no impact on the cache in the users’ browser, which must be defined using the Set Cache Policy behavior.

By using Bypass Cache, you’ll configure Azion’s service to forward all requests to a path directly to their origin. However, you’ll count on important protocol optimizations to speed up your application and a keepalive connection between Azion edge nodes and their origin whenever possible.

See the guide on How to configure cache policies for Edge Application for more information on Bypass Cache.

While both the Bypass Cache behavior and Maximum TTL at zero seconds allow you to optimize content delivery and reduce load times at the origin, their effects are a bit different.

By using the Bypass Cache behavior, all HTTP and HTTPS requests received by Azion’s edge nodes will be sent to the origin, without caching any content. Use Bypass Cache if you want to deliver different content for each user request.

However, when setting TTL to 0 (zero) seconds, multiple requests in parallel to Azion’s edge nodes will be sent as a single request to their origin. In this case, Azion’s edge nodes also validate changes to the content with its origin by using the If-Modified-Since parameter. If the object hasn’t changed since the last request, the content won’t need to be transferred again, which could result in a much faster 304 Not Modified response. Also, setting maximum cache TTL to 0 will still generate a cache object that lives for 999 milliseconds.

Request Phase Requires Application Acceleration

Support behavior for handling strings. Stores in a temporary variable the result of capturing correspondence groups defined by a regex applied to one of the available HTTP request fields. This temporary variable can be referenced later in the behavior Rewrite Request to assemble the rewrite string.

This behavior requires three arguments:

• captured array name: the name you want to give to the temporary variable where the array of captured strings will be stored.
• subject: the HTTP request field where you want to capture a string.
• regex: the regular expression used to capture the strings. Each captured group must be represented in parentheses.

For example, to capture the path and name of a file in an HTTP request, you could use:

• captured array name: capture
• subject: ${uri}
• regex: ^(./)([^/])$

You may reference the capture variable as an array by using the notation %{variable[index]}. Because it’s a local variable, you can only use it within the same rule you are setting up. In this example, if the URI is /path/image.jpg, the capture variable will have the following values:

• %{capture[0]} = "/path/image.jpg"
• %{capture[1]} = "/path/"
• %{capture[2]} = "image.jpg"

You can also name the indexes to reference them using names instead of a numeric index. To do so, use the ?<name> notation as in the example:

• captured array name: capture
• subject: ${uri}
• regex: ^(?<path>.*/)(?<filename>[^/]*)$

Finishes processing the request and delivers the content to the user, without executing any of the rules added later. You’re forcing the processing to end immediately.

Delivers a 403 Forbidden page to the user. Ends the request processing.

Enables Gzip data compression, if supported by the user’s browser. See the guide on How to enable gzip compression for more information.

Request Phase Requires Edge Caching

Enables segmentation of large objects into 1MB slices, if their origin supports HTTP range requests. You can use this behavior to optimize the performance of your website or application. If you deliver media larger than 1MB sliced through Azion, the content reaches users before the edge has received the entire object from its origin.

When activating this functionality, Azion will request the objects for their origin via range requests and they’ll be cached in Azion with Advanced Cache Key.

If your origin doesn’t support range requests, Azion will only be able to start delivering your content to its users after your origin has finished the complete sending of the object.

This behavior is automatically included by Azion every time you select a Live Ingest source. Two actions are performed in this situation: the bypass of all your Cache Phase rules and the imposition of the cache policy defined by Azion for live transmissions in HLS.

Azion’s cache policy for live HLS streams is 5 seconds of cache for playlists (.m3u8) and 60 seconds of cache for chunks (.ts).

Request Phase Response Phase Requires Application Acceleration

Removes a cookie from the request header that would be sent to the origin or from the response header that would be sent to the user. As an argument, add the name of the cookie you want to remove as cookie-name.

To remove only specific values, you must inform the name and value of the cookie as cookie-name=cookie-value.

Removes a request header that would be sent to the origin or a response header that would be sent to the user. The name of the header field must be entered as an argument, for example: Header-Name.

Finishes the request phase. Any behavior or other rules under this behavior won’t be executed.

Request Phase Requires Application Acceleration

By using the Forward Cookies behavior, you’re determining that Azion forwards to its users the Set-Cookie header received from its origin, even when cached content is identified (HIT).

To prevent a user from receiving the Set-Cookie header from another user’s session, see the guide on cache policies.

An alternative to sending the response header Set-Cookie is to create cookies using JavaScript, which allows you to create, read, and expire cookies through the document.cookie property.

A JavaScript cookie should have the following format:

document.cookie = "username=John Doe; expires=Thu, 18 Dec 2020 12:00:00 UTC; path=/";

By default, Azion won’t filter the request header Cookie regardless of its Forward Cookies configuration and therefore JavaScript Cookies may be sent to the origin to enable the management of your application.

Returns a 204 code when accessing the edge application instead of the code received from the origin.

Request Phase Requires Image Processor

Enables Image Processor.

Request Phase Requires HTTPS application

Redirects the HTTP request to HTTPS. If the request is already made through HTTPS, the behavior isn’t executed.

Redirect to (301 Moved Permanently) and Redirect To (302 Found) redirect the user to the URL or URI entered as an argument, returning the corresponding status code.

It’s recommended using these behaviors for path changes; 301 Moved Permanently for permanent changes and 302 Found for temporary changes.

Both behaviors end the request processing phase.

Request Phase Requires Application Acceleration

Modifies the resource path that will be requested for the origin. You can rewrite the resource path using:

• A string.
• The requisition variables (which can also be used in Criteria).
• The local variables, in the format %{name [index]}, with the result of capturing strings, when using the auxiliary behavior Capture Match Groups.

For example, to rewrite a user request for the /original/image.jpg resource to be sent to its origin as /new/image.jpg:

1. Use the Capture Match Groups behavior with the arguments:

• captured array name: capture
• subject: ${uri}
• regex: /original/(.)

2. Use the Rewrite Request behavior with the argument /new/%{capture[1]}.

Request Phase Response Phase Requires Application Acceleration Requires Edge Functions

Runs a function created using Edge Functions and instantiated in the Edge Functions tab for the edge application. See the guide on How to run serverless functions for more information.

Assigns the cache policy that should be used for the request. You must first set up the cache policies in Cache Settings.

You can set up the time that an object will be stored in cache and the rules for the variation of objects in cache with the Advanced Cache Key.

Assigns an origin that must be consulted by the edge node for the request.

Before configuring this behavior, you must set up your origins using Origins.

You can debug rules created with Rules Engine created in Rules Engine for Edge Application through the GraphQL API, Data Streaming, or Real-Time Events.

Contributors