Using Acceleration Policies to Manage and Respond to HTTP Requests

The Policies screen displays all of the acceleration policies available for assignment to your applications. From the Policies screen, you can access additional screens, from which you can perform additional tasks.

Example Policies screen

There are two types of acceleration policies that you can use to speed up the access to your web applications.

When configuring policies in a BIG-IP acceleration application, you can do one or more of the following tasks.

You can select a predefined acceleration policy that is associated with your specific application publisher or you can use one of the predefined generic acceleration policies. Both work well for most sites that use Java 2 Platform Enterprise Edition (J2EE) applications.

If you have a unique application for which you cannot use a predefined acceleration policy, you can create a new, user-defined acceleration policy.

Before you can create a new acceleration policy, you need to analyze the type of traffic that your site's applications receive, and decide how you want the BIG-IP to manage those HTTP requests and responses. To help you do that, consider questions similar to the following.

• Which responses do I want the BIG-IP to cache?
• Are there responses for static documents that can remain in the system's cache for several days before being refreshed?
• Which responses are dynamic documents that the BIG-IP should refresh hourly?
• Are there responses that the BIG-IP should never cache?

After you decide how you want the BIG-IP to handle certain requests for your site, you can identify the HTTP data parameters that the BIG-IP uses to match requests and responses to the appropriate acceleration policies.

For example, the path found on requests for static documents might be different than the path for dynamic documents. Or the paths might be similar, but the static documents are in PDF format and the dynamic documents are Word documents or Excel spreadsheets. These differences help you specify matching rules that prompt the BIG-IP to match the HTTP request to the acceleration policy that will handle the request and the response most expeditiously.

You can create a user-defined acceleration policy most efficiently by copying an existing acceleration policy and modifying its rules to meet your unique requirements. Alternatively, you can create a new user-defined acceleration policy and define each matching rule and acceleration rule individually.

When you copy or create an acceleration policy, the BIG-IP maintains that acceleration policy as a development copy until you publish it, at which time the BIG-IP creates a production copy. Only a production (published) copy of an acceleration policy is available for you to assign to an application. You can make as many changes as you like to the development copy of an acceleration policy without affecting current traffic to your applications.

When you modify rules for a user-defined acceleration policy that is currently assigned to an application, the BIG-IP creates a development copy and continues to use the currently published (production) copy to manage requests. The BIG-IP acceleration manager uses the modified acceleration policy to manage traffic only after you publish it.

If you create a new acceleration policy, you must publish it before you can assign it to an application.

You can use the Acceleration Policy Editor role to manage and customize acceleration policies for the BIG-IP^®. This role provides full access to acceleration features and functionality, and read-only access to all other BIG-IP features and functionality.

You can use the export feature to save an acceleration policy to an XML file. F5 Networks^® recommends that you use the export feature every time you change a user-defined acceleration policy, so that you always have a copy of the most recent acceleration policy. You can use this file for back up and archival purposes, or to provide to the F5 Networks^® Technical Support team for troubleshooting issues.

Sometimes, both precedence and priority can produce a match. When multiple nodes produce a match, the BIG-IP must determine the best match. In some instances, priority determines the best match, in others, precedence determines the best match, and in still others, both precedence and priority together determine the best match.

If a request does not match a leaf node in the Policy Tree, there is an unmatched node in the Policy Tree, and the BIG-IP either uses a predefined accelerator policy that manages unmatched requests and responses, or sends the request to the origin web server for content.

It is important to keep in mind that for the BIG-IP to consider a request a match, the request must match all the matching rules configured for a leaf node. If a request matches all the rules for a leaf node, except for one, the BIG-IP does not consider it a match, and processes it as an unmatched request.

There are three main parts to the Policy Editor screen.

Matching rules displayed from the Policy Editor

When you select Acceleration Rules, the acceleration rules menu bar appears.

Policy Editor menu bar displaying acceleration rules options

Matching rules and acceleration rules for acceleration policies are organized on the Policy Tree, which you access from the Policy Editor screen.

A Policy Tree example

The structure of the Policy Tree supports a parent-child relationship. This allows you to easily randomize rules. That is, because a leaf node in a Policy Tree inherits all the rules from its root node and branch node, you can quickly create multiple leaf nodes that contain the same rule parameters by creating a branch with multiple leaf nodes. If you override or create new rules at the branch node level, the BIG-IP reproduces those changes to the associated leaf nodes.

Rule inheritance on a Policy Tree

Nodes are defined as follows.

When you create a user-defined acceleration policy by copying an existing acceleration policy, you must determine from which branch node the acceleration policy is inheriting specific rules, and decide whether you want to change the rules at the leaf node or change the rules at the branch node. To determine inheritance for a rule parameter, view the rule parameter’s inheritance icon.

The following example figure illustrates matching rules for the Path and Header rule parameters for a particular leaf node.

Inheritance example for Path and Header parameters

The arrow icon in the Inheritance column next to the Path parameter indicates this rule was inherited from the parent branch node. The inheritance icon next to the Header parameter does not have an arrow, indicating that the rule was not inherited; it was created locally at the leaf node.

Because the Header parameter rule is not inherited, you can delete the rule at the leaf node level. However, you cannot delete the Path parameter because it was inherited from the branch node. To delete the Path parameter rule, you must delete from its parent branch node.

For inherited rule parameters, you can determine the ancestor branch node by hovering the cursor over the inheritance icon. When placing the cursor on the inheritance icon next to Path, the branch node Home displays as the ancestor node, as illustrated in the following example figure.

Inheritance example for Path parameter

When you override an inherited setting for a rule, an override icon displays (the inheritance icon with a red X) next to the rule setting. To see the node where the option was overridden, place your cursor over the override icon.

For example, for the content assembly rule in the following example figure, all of the options are inherited from the branch node, except for the Enable Intelligent Browser Referencing To option. For this node, the rule was disabled at the leaf node. When hovering the cursor over the override icon, a message displays next to the Content Assembly Options menu.

Inheritance example with overridden rule option

To see if the current leaf node inherited this overridden option, click the parent branch node and view its rules. In the following example figure, you see that there were no rule settings overridden at the parent branch, indicating the rule was inherited from the branch node, Home, and overridden at the leaf node.

Parent of leaf node example

When you follow this rule back to its grandparent, you see the rule options are not inherited from any other node; they are set at the grandparent node and they are all enabled, as indicated in the following example figure.

Grandparent of leaf node example

If you want to enable the content compression feature at the leaf node, you can use one of the following options.

• Override the inherited setting at the leaf node and select the Enable Content Compression check box.
• Cancel the override setting at the parent, so that the parent inherits the Enable Content Compression setting of the grandparent, and passes that setting to the leaf node.

Keep in mind that if you cancel the override setting at the grandparent branch node, you change the settings for all of the child leaf nodes, not just the leaf node you want to change.

To customize a user-defined acceleration policy, you can modify matching rules and acceleration rules for the branch and leaf nodes. Or, you can add new branch and leaf nodes and associated matching and acceleration rules to the Policy Tree.

To maintain high performance, the BIG-IP^® does not service an HTTP request unless the request meets the following conditions.

• The request includes an HTTP request header that is no larger than 8192 bytes, and in the first line, identifies its method, URI, and protocol.
• The method for the HTTP request header is a GET, HEAD, or POST method.
• The protocol for the HTTP request header is a HTTP/0.9, HTTP/1.0, or HTTP/1.1.
• The HTTP post data on the request is no larger than 32768 bytes.
• If the request provides the Expect request header, the value is 100-continue.
• If the request provides the Content-Type request header, the value is application/x-www-form-urlencoded.
• The request includes a Host request header identifying a targeted host that is mapped to an origin server at your site.

If the HTTP Host request header is missing or does not have a value, the BIG-IP responds to the requesting client with a 400-series error message. If the request violates any of the other conditions, the BIG-IP redirects the request to the origin web servers for content.

When a BIG-IP^® device receives an HTTP request that meets the required conditions, the BIG-IP processes the request in accordance with this sequence.

1. The BIG-IP performs policy matching against the request and retrieves the associated acceleration rules.
2. The BIG-IP evaluates the policy matching to a proxying rule, as follows:

   Condition	Process
   Request is matched to a proxying rule	The BIG-IP sends the request to the origin web servers as required by the rule.
   Request is not matched to a proxying rule	The BIG-IP attempts to retrieve the appropriate compiled response from cache.

3. The BIG-IP processes the attempt to retrieve the appropriate compiled response from cache, as follows:

   Condition	Process
   No compiled response resides in cache	The BIG-IP sends the request to the origin web servers for content.
   Compiled response resides in cache	The BIG-IP searches for an associated content invalidations rule for the compiled response.

4. The BIG-IP processes the resultant content invalidations rule for the compiled response, as follows:

   Condition	Process
   A content invalidations rule is triggered for the compiled response	The BIG-IP compares the rule’s effective time against the compiled response’s last refreshed time.
   A content invalidations rule is not triggered	The BIG-IP examines the compiled response’s TTL value to see if the compiled response has expired.

5. The BIG-IP processes the compiled response's last refresh time, as follows:

   Condition	Process
   The compiled response’s last refreshed time is before the content invalidations rule’s triggered time	The BIG-IP sends the request to the origin web servers for content.
   The compiled response’s last refreshed time is after the content invalidations rule’s triggered time	The BIG-IP examines the compiled response’s TTL value to see if the compiled response has expired.

6. The BIG-IP processes the compiled response’s TTL value, as follows:

   Condition	Process
   The compiled response has expired	The BIG-IP sends the request to the origin web servers.
   The compiled response has not expired	The BIG-IP services the request using the cached compiled response.

When the BIG-IP^® device receives a response from the origin web server, it inspects the HTTP response headers, applies the acceleration rules to the response, and sends the content to the client. To ensure the most effective performance, the BIG-IP does not cache a response from the origin server, or forward it to the originating requestor, unless it meets the following conditions.

• The request does not match to a do-not-cache proxying rule.
• The first line of the response identifies the protocol, a response code that is an integer value, and a response text. For example: HTTP/1.1 200 (OK).
• If the Transfer-Encoding response header is used on the response, the value is chunked.
• The response is complete, based on the method and type of data contained within the response, as follows.
  • HTML tags. By default, the BIG-IP considers a response in the form of an HTML page complete only if it contains both beginning and ending HTML tags.
  • Content-Length response header. If a response is anything other than an HTML page, or if you have overridden the default behavior described in the previous bullet point, the BIG-IP considers content complete only if the response body size matches the value specified on the Content-Length response header.
  • Chunked transfer coding. The BIG-IP accepts chunked responses that omit the final zero-length chunk. For information about chunked transfer coding, see section 3.6 in the HTTP/1.1 specification http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.

If the BIG-IP receives a response from the origin server that does not conform to these conditions, it does not cache the response before sending it to the client.

When the BIG-IP receives a response from the origin web server, the BIG-IP performs the following actions.

1. Inspects the HTTP response headers.
2. Applies the acceleration rules to the response.
3. Sends the content to the client.

In most cases, the default values for the predefined acceleration policies are sufficient, but you can fine-tune the BIG-IP^® device's behavior by creating a user-defined acceleration policy and modifying the HTTP request data type parameters. When you specify or modify an HTTP data type parameter for an acceleration policy rule, you define specific HTTP data type parameter criteria that the BIG-IP uses to manage HTTP requests. When specifying parameter criteria, you designate the following information within a rule.

• Parameter identity. This can include one or more of the following criteria.
  • Parameter type
  • Parameter name
  • Parameter location within the HTTP request
• Parameter value or state. This can include one or more of the following parameter state and value.
  • Parameter is present in the HTTP request and matches the defined value provided in the form of a regular expression.
  • Parameter is present in the HTTP request and does not match the specified value provided in the form of a regular expression.
  • Parameter is present in the HTTP request, but has no value (is an empty string).
  • Parameter is not present in the HTTP request
• BIG-IP action. Where you specify the following criteria.
  • Whether the BIG-IP performs an action on a match or a no match.
  • The action that the BIG-IP performs, which is dictated by the rules in the associated acceleration policy.

For example, if you specify a rule that the BIG-IP performs an action when a request does not match a configured parameter, the rule triggers if the parameter in the request is a different value than you specified, or if the value is empty (null). The BIG-IP does not perform the specified action if the parameter does not appear in the request.

After the BIG-IP^® receives a response from the origin web server, it performs the following processes.

• Classifies the response
• Applies associated acceleration policy rules
• Assembles the response

Response headers have no effect on application matching, variation, or invalidations rules. The BIG-IP evaluates response headers associated with caching after it compiles, but before it caches, the response. Once the BIG-IP begins the compilation and assembly process, it then examines existing response headers that influence assembly.

You can configure assembly, proxying, lifetime, or responses cached rules based on response headers.

When the BIG-IP^® performs pattern matching based on regular expressions, it assumes all regular expressions are in the form of ^expression$, even if you do not explicitly set the beginning of line (^) and end of line ($) indicators. For substring searches, you enter *expression.* as a regular expression.

The string that the BIG-IP matches is dependent on the HTTP data type for which you are providing the regular expression. Before the BIG-IP attempts to match information in an HTTP request to the HTTP request data type parameters, it translates any escaped characters (such as %2F or %2E) back to their regular form, such as (/ or .,).

The HTTP Cache-Control version 1.1 header specification identifies general-header field directives for all caching mechanisms along the request/response chain, and is used to prevent caching behavior from adversely interfering with the request or the response. (For additional information, see sections 13 and 14 of the HTTP/1.1 specification at http://www.w3.org/Protocols/rfc2616/rfc2616.html.)

Directives can appear in response or request headers, and certain directives can appear in either type of header. The HTTP Cache-Control general-header field directives typically override any default caching algorithms.

The origin web server’s cache response directives are organized in two groups: no-cache and max-age.

Before sending a response to a client, the BIG-IP can optionally insert an X-WA-Info response header that includes specific codes describing the properties and history of the object. The X-WA-Info response header is for informational purposes only and provides a way for you to assess the effectiveness of your acceleration policy rules.

Following is an example of an X-WA-Info header.

X-WA-Info: [V2.S11101.A13925.P76511.N13710.RN0.U3756337437].[OT/images.OG/images]

The code is divided into fields by the period ( . ) delimiter. Each field begins with a letter code, followed by one or more letters or numbers. The object type and group under which the response is classified are also included in the X-WA-Info response header.

The object type is preceded by OT and the group is preceded by OG, as in the following example.

[OT/msword.OG/documents]

When you enable the X-WA-Info Header setting for an application, the following tasks describe how to view X-WA-Info response headers.

• Perform a packet capture of the page.
• Using an HTTP viewer utility like HttpWatch, HTTP Analyzer, or Live Headers.
• Using the Request Logging profile.