Applies To:

Show Versions Show Versions

Manual Chapter: Using Acceleration Policies to Manage and Respond to HTTP Requests
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Overview: WebAccelerator policies options

You can use acceleration policies to speed up the access to your web applications. When configuring policies in a WebAccelerator™ application, you can do one or more of the following:

Predefined Policies

  • Use a predefined policy. Predefined policies are available when you configure a WebAccelerator application. You do not need to create them.

User-Defined Policies

  • Create and use a user-defined policy by copying a predefined policy.
  • Create and use a new user-defined policy

Task summary for using acceleration policies to manage and respond to HTTP requests

Perform these tasks to use policies to manage and respond to HTTP requests.

Accessing the Policy Viewer screen

The Policy Viewer displays the matching rules and acceleration rules for predefined acceleration policies.
  1. On the Main tab, click WebAccelerator > Policies. The Policies screen displays a list of existing acceleration policies.
  2. Click the name of a predefined policy.
The Policy Viewer screen appears for the predefined acceleration policy.
Note: You cannot edit the settings for a predefined policy.

Copying an acceleration policy

Create a user-defined acceleration policy most efficiently by copying an existing acceleration policy and modifying its rules to meet your unique requirements.
  1. On the Main tab, click WebAccelerator > Policies. The Policies screen displays a list of existing acceleration policies.
  2. In the Tools column, click Copy for the acceleration policy you want to copy.
  3. Name the policy.
  4. In the Description field, type a description.
  5. Click Copy.
The acceleration policy appears in the Policy column.

Creating a user-defined acceleration policy from a predefined acceleration policy

You can copy a predefined acceleration policy, and modify applicable nodes, matching rules, and acceleration rules, to create a user-defined acceleration policy.
  1. On the Main tab, click WebAccelerator > Policies. The Policies screen displays a list of existing acceleration policies.
  2. In the Tools column, click Copy for the predefined acceleration policy you want to copy.
  3. Name the policy.
  4. In the Description field, type a description.
  5. Click Copy.
  6. Click the name of the new user-defined acceleration policy.
  7. Create, delete, or modify nodes, matching rules, and acceleration rules, as necessary.
  8. Publish the policy.
    1. Click Publish.
    2. In the Comment field, type a description.
    3. Click Publish Now.
The user-defined acceleration policy appears in the Policy column.

Creating a new user-defined acceleration policy

You can create a new user-defined acceleration policy and define each matching rule and acceleration rule individually.
  1. On the Main tab, click WebAccelerator > Policies. The Policies screen displays a list of existing acceleration policies.
  2. Click Create.
  3. Name the policy.
  4. In the Description field, type a description.
  5. Click Create.
  6. Click the name of the new user-defined acceleration policy.
  7. Create the Policy Tree by defining branch nodes for groups of content, and leaf nodes for specific content.
  8. Specify the matching and acceleration rules for each node.
  9. Click Exit Policy Editor.
The acceleration policy appears in the Policy column.

Importing an acceleration policy

An acceleration policy must have been saved.
You can import a saved acceleration policy file, as necessary.
  1. On the Main tab, click WebAccelerator > Policies. The Policies screen displays a list of existing acceleration policies.
  2. Click Import.
  3. Click Browse, and browse to the location of the XML file that you want to import.
  4. Do one of the following:
    • Select the Overwrite existing policy of the same name check box to replace an existing acceleration policy with the imported acceleration policy with the same name.
    • Clear the Overwrite existing policy of the same name check box to replace the existing acceleration policy.
  5. Click Import.
The acceleration policy appears in the Policy column.

Publishing a user-defined acceleration policy

When you create a new acceleration policy, you must publish it before you can assign it to an application. The WebAccelerator system uses a modified acceleration policy to manage traffic only after you publish it.
  1. On the Main tab, click WebAccelerator > Policies. The Policies screen displays a list of existing acceleration policies.
  2. In the Tools column, click Publish for the user-defined acceleration policy you want to publish.
  3. Click Publish Now.
The user-defined acceleration policy is published.

Modifying an acceleration policy's rules

You can modify the acceleration rules for a user-defined acceleration policy to meet your unique requirements.
  1. On the Main tab, click WebAccelerator > Policies. The Policies screen displays a list of existing acceleration policies.
  2. Click the name of a user-defined acceleration policy.
  3. Click a node in the Policy Tree.
  4. From the Matching Rules menu, choose Acceleration Rules.
  5. Click an item on the Acceleration Rules menu to view the rules for that item.
  6. Edit the settings, as necessary.
  7. Click Save.
The modified rules appear for the acceleration rules menu item.

Viewing rules for an acceleration policy

You can view the acceleration rules for an acceleration policy and determine what rules apply to each node.
  1. On the Main tab, click WebAccelerator > Policies. The Policies screen displays a list of existing acceleration policies.
  2. Do one of the following:
    • Click the name of a user-defined acceleration policy.
    • Click the name of a predefined acceleration policy.
  3. Click a node in the Policy Tree.
  4. From the Matching Rules menu, choose Acceleration Rules.
  5. Click an item on the Acceleration Rules menu to view the rules for that item.
The acceleration rules for the selected item appear for the node.

Saving an acceleration policy to an XML file

When you change an acceleration policy, you can export it to an XML file so that you always have a copy of the most recent acceleration policy.
  1. On the Main tab, click WebAccelerator > Policies. The Policies screen displays a list of existing acceleration policies.
  2. Click Export.
  3. In the Export list, select one of the following:
    Item Description
    Published Policy Exports an acceleration policy that an application is currently using. If the acceleration policy has not been published, this option does not display.
    Development Policy Exports an unpublished acceleration policy.
  4. Click Export.
  5. Click Save.
  6. Navigate to the location where you want to save the file.
  7. Click Save.
The acceleration policy is exported as an XML file.

Deleting a user-defined acceleration policy

You can delete a user-defined policy, as necessary.
  1. On the Main tab, click WebAccelerator > Policies. The Policies screen displays a list of existing acceleration policies.
  2. Select the check box for the applicable policy.
  3. Click Delete.
The policy is deleted.

Task summary for using the Policy Editor

Perform these tasks to use the Policy Editor.

Accessing the Policy Editor screen

The Policy Editor displays the matching rules and acceleration rules for user-defined acceleration policies, and enables you to modify user-defined acceleration policies.
  1. On the Main tab, click WebAccelerator > Policies. The Policies screen displays a list of existing acceleration policies.
  2. Click the name of a user-defined acceleration policy.
The Policy Editor screen appears for the user-defined acceleration policy.

Viewing the Policy Tree for an acceleration policy

Matching rules and acceleration rules for acceleration policies are organized on the Policy Tree, which you access from the Policy Editor screen.
  1. On the Main tab, click WebAccelerator > Policies. The Policies screen displays a list of existing acceleration policies.
  2. Do one of the following:
    • Click the name of a user-defined acceleration policy.
    • Click the name of a predefined acceleration policy.
The Policy Tree appears on the left side of the Policy Editor screen.

About the HTTP request process

When a WebAccelerator™ system receives an HTTP request that meets the required conditions, the WebAccelerator system processes the request in accordance with this sequence.

  1. The WebAccelerator system performs policy matching against the request and retrieves the associated acceleration rules.
  2. The WebAccelerator system evaluates the policy matching to a proxying rule, as follows:
    Condition Process
    Request is matched to a proxying rule The WebAccelerator system sends the request to the origin web servers as required by the rule.
    Request is not matched to a proxying rule The WebAccelerator system attempts to retrieve the appropriate compiled response from cache.
  3. The WebAccelerator system processes the attempt to retrieve the appropriate compiled response from cache, as follows:
    Condition Process
    No compiled response resides in cache The WebAccelerator system sends the request to the origin web servers for content.
    Compiled response resides in cache The WebAccelerator system searches for an associated content invalidations rule for the compiled response.
  4. The WebAccelerator system 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 WebAccelerator system compares the rule’s effective time against the compiled response’s last refreshed time.
    A content invalidations rule is not triggered The WebAccelerator system examines the compiled response’s TTL value to see if the compiled response has expired.
  5. The WebAccelerator system 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 WebAccelerator system 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 WebAccelerator system examines the compiled response’s TTL value to see if the compiled response has expired.
  6. The WebAccelerator system processes the compiled response’s TTL value, as follows:
    Condition Process
    The compiled response has expired The WebAccelerator system sends the request to the origin web servers.
    The compiled response has not expired The WebAccelerator system services the request using the cached compiled response.

About the HTTP responses process

When the WebAccelerator™ system receives a response from the origin web server, the WebAccelerator system:

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

Reference summary for HTTP data

These topics provide HTTP reference data, including request data type paramenters, response status codes, S code definitions.

HTTP request data type parameters

This table describes the HTTP request data type parameters and respective rules.

Parameter Matching Rules Variation Rules Assembly Rules Proxying Rules Invalidations Rules
Host x x   x x
Path x       x
Extension x       x
Query parameter x x x x x
Unnamed query parameter x x x x x
Path segment x x x x x
Cookie x x   x x
User Agent x x   x x
Referrer x x   x x
Protocol x x   x x
Method x x   x x
Header x x   x x
Client IP x x   x x
Content Type x        

Response status codes

This table describes HTTP response codes that you can add in addition to the default 200, 201, 203, or 207 response codes.

Response code Definition
200 OK. The request is satisfactory.
201 Created. The requested resource (server object) was created.
203 Non-Authoritative Information. The transaction was satisfactory; however, the information in the entity headers came from a copy of the resource, instead of an origin web server.
207 Multi-Status (WebDAV). The subsequent XML message might contain separate response codes, depending on the number of subrequests.
300 Multiple Choices. The requested resource has multiple possibilities, each with different locations.
301 Moved Permanently. The requested content has been permanently assigned a new URI. The origin web server is responding with a redirect to the new location for the content.
302 Found. The requested content temporarily resides under a different URI. The redirect to the new location may change.
307 Temporary Redirect. The requested content temporarily resides under a different URI. The redirect to the new location may change.
410 Gone. The requested content is no longer available and a redirect is not available.

S code definitions

This table describes the S codes, the first field of the X-WA-Info response header, which indicates whether the object in the HTTP response was served from the system's cache, or was sent to the original web server for content.

Code Definition Description
SO Response was served from an unknown source. Indicates that the WebAccelerator™ system was unable to determine if a response was served from cache or sent to the origin web server for content.
S10101 Response was served from memory. Indicates that the response was served from memory.
S10201 Response was served from the origin web server, because the request was for new content. When the WebAccelerator system receives a request for new content, it sends the request to the origin web server and caches the content before responding to the request. Future requests for this content are served from cache.
S10202 Response was served from the origin web server, because the cached content had expired. When the WebAccelerator system receives a request for cached content that exceeds a lifetime rule’s Maximum Age setting, it revalidates the content with the origin web server (which responds with a 200 (OK) status code). After revalidating the content, the WebAccelerator system serves requests from cache, until the Maximum Age setting is once again exceeded.
S10203 Response was served from the origin web server, as dictated by an acceleration policy rule. When the WebAccelerator system matches a request to a node with a proxying rule set to Always proxy requests for this node, the WebAccelerator system sends that request to the origin web server, rather than serving content from cache.
S10204 Response was served from the origin web server, because of specific HTTP or web service methods. If the WebAccelerator system receives a request that contains an HTTP no-cache directive, the WebAccelerator system sends the request to the origin server and does not cache the response. In addition, the WebAccelerator system does not currently support some vendor-specific HTTP methods (such as OPTIONS) and some web services methods (such as SOAP). The WebAccelerator system sends requests containing those methods to the origin web server for content.
S10205 Response was served from the origin web server because the cached content was invalidated. You can perform a cache invalidation manually, through direct XML messaging over HTTPS on port 8443, or with an acceleration rule setting. After the WebAccelerator system invalidates cache and retrieves new content from the origin web server, it stores the response and serves future requests from cache.
S10206 Response was served from the origin web server, because the content cannot be cached. If a response cannot be cached, for example, because the content is private or the header is marked as no-store, the WebAccelerator system includes this code in the response to the client.
S10232 Response was served from cache, because the expired content is still valid. If an acceleration rule prompts the WebAccelerator system to expire content, it sends the next request to the origin web server. If the origin web server indicates that the cached content has not changed (responding with a 304 (Not Modified) status code), the WebAccelerator system includes this code in the response to the client.
S10233 Response was served from cache, because the cached content is still valid. If an acceleration proxy rule prompts the WebAccelerator system to proxy content, it sends that request to the origin web server. If the origin web server indicates that the cached content has not changed, the WebAccelerator system includes this code in the response to the client.
S10301 Response was served from the origin web server, because the response contained large multimedia objects. Large multimedia objects often cannot be optimized because they are typically composed of files that are already compressed and too large to cache. You can create a proxying rule to recognize requests for these types of objects and prompt the WebAccelerator system to send those requests directly to the origin web server for content. Further, you can specify a responses-cached rule directing the WebAccelerator system to not cache that content.
S10413 Response bypassed the WebAccelerator system.

When a request includes an Expect: 100-continue header, that request and its response bypass the WebAccelerator system, which responds with an X-WA-Info header that includes an S10413 field code.

S10414 Request and response bypassed the WebAccelerator system. When the WebAccelerator system's license has expired, it does not match and apply acceleration policies to requests or responses.
S11101 Response was served from cache. This response was served from memory without requiring specific assembly processing by the WebAccelerator system. This is the most efficient and fastest response method.

HTTP data types for regular expression strings

This table describes the HTTP data types that are supported by the WebAccelerator™ system for regular expression strings.

HTTP data type Definition Example
host The value set for the HTTP Host request header HOST: www.siterequest.com

The WebAccelerator system matches the example HTTP Host request header to the string www.siterequest.com.

path The value set for the path portion of the URI, http://www.siterequest.com/apps/search.jsp?value=computer

For the example URI, the WebAccelerator system matches the string /apps/search.

extension The value set for the extension portion of the URI, http://www.siterequest.com/apps/search.jsp?value=computer

For the example URI, the WebAccelerator system matches the string jsp.

query parameter The value set for the identified query parameter, http://www.siterequest.com?action=display&PDA

The WebAccelerator system matches the example value set for the action query parameter to the string display.

A query parameter is matched against the requested URL, or a Content-Type header's URL encoded string in the body of a POST method. If the specified query parameter appears one or more times in the request, all instances will be matched.

unnamed query parameter The value set for the identified query parameter, http://www.siterequest.com?action=display&PDA

If the value set for the unnamed query parameter in ordinal 2 is this URI, the WebAccelerator system matches the string PDA.

An unnamed query parameter is matched against the requested URL, or a Content-Type header's URL encoded string in the body of a POST method. The ordinal specifies the left-to-right position of the parameter to match.

path segment The name of the segment key or the value set for the segment parameter, depending on what you identify for the match, http://www.siterequest.com/apps;AAY34/search.jsp? value=computer

If you identify the path segment in ordinal 1 for the full path (counted from left-to-right), then you have identified the segment key in the URL, and the WebAccelerator system matches the string apps.

Path segments are matched against the ordered segments, separated by a virgule (/) and terminated by the first question mark (?) or octothorpe (#) in the URL

cookie The value set for the identified cookie, COOKIE: SESSIONID=TN2MM1QQL

The WebAccelerator system matches the string TN2MM1QQL.

user agent The value set for the HTTP USER_AGENT request header, USER_AGENT: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)

The WebAccelerator system matches the string Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0).

referrer The value set for the HTTP REFERER request header REFERER: http://www.siterequest.com?action=display

The WebAccelerator system matches the string http://www.siterequest.com?action=display.

header The value set for the identified header. Accept-Encoding: gzip

The WebAccelerator system matches the string gzip

.

Max age value for compiled responses

This table describes the max age values for compiled responses.

Priority Directive Description
1 Cache-Control: s-maxage The WebAccelerator™ system bases the TTL on the current time, plus the value specified for the HTTP Cache-Control header’s s-maxage directive. Values for this directive are expressed in seconds.
2 Cache-Control: max-age The WebAccelerator system bases the TTL on the current time, plus the value specified for the HTTP Cache-Control header’s max-age directive. Values for this directive are expressed in seconds.
3 Expires The WebAccelerator system uses the TTL provided for HTTP Cache-Control header’s entity-header field. Values for this field are expressed in Coordinated Universal Time (UTC time). To avoid caching issues, the WebAccelerator system must be properly synchronized with the origin web server. For this reason, F5 Networks® recommends that you configure a Network Time Protocol (NTP) server.
4 Last-Modified The WebAccelerator system bases this TTL by using the formula TTL = curr_time + ( curr_time - last_mod_ time ) * last_mod_factor.
In this formula, the variables are defined as follows:
  • curr_time is the time that the response is received by the WebAccelerator system.
  • last_mod_ time is the time specified by this directive.
  • last_mod_factor is a percentage value used to weight the TTL you set it with a lifetime rule.

Meta characters

This table describes the meta characters that are supported by the WebAccelerator™ system for pattern matching.

Meta character Description Example
. Matches any single character.  
^ Matches the beginning of the line in a regular expression. The WebAccelerator system assumes that the beginning and end of line meta characters exist for every regular expression it sees.  
$ Matches the end of the line. The WebAccelerator system assumes that the beginning and end of line meta characters exist for every regular expression it sees.
The expression G.*P.* matches:
  • GrandPlan
  • GreenPeace
  • GParse
  • GP
A pattern starting with the * character is the same as using .* For example, the WebAccelerator system interprets the following two expressions as identical.
  • *Plan
  • .*Plan
* Matches zero or more of the patterns that precede it.  
+ Matches one or more of the patterns that precede it.
The expression G.+P.* matches:
  • GrandPlan
  • GreenPeace

Do not begin a pattern with the + character. For example, do not use +Plan. Instead, use .+Plan.

? Matches none, or one of the patterns that precede it.
The expression G.?P.* matches:
  • GParse
  • GP

Do not begin a pattern with the ? character. For example, do not use ?Plan. Instead, use .?Plan.

[...] Matches a set of characters. You can list the characters in the set using a string made of the characters to match. The expression C[AHR] matches:
  • CAT
  • CHARISMA
  • CRY
You can also provide a range of characters by using a dash. For example, the expression AA[0-9]+ matches:
  • AA269812209
  • AA2

It does not, however, match AAB2.

To match any alphanumeric character, both upper-case and lower-case, use the expression [a-zA-Z0-9].

[^...] Matches any character not in the set. Just as with the character, [...], you can specify the individual characters, or a range of characters by using a dash (-).
The expression C[^AHR].* matches:
  • CLEAR
  • CORY
  • CURRENT
The expression C[^AHR].*, however, does not match:
  • CAT
  • CHARISMA
  • CRY
(...) Matches the regular expression contained inside the parenthesis, as a group. The expression AA(12)+CV matches:
  • AA12CV
  • AA121212CV
exp1 exp2 Matches either exp1 or exp2, where exp1 and exp2 are regular expressions. The expression AA([de]12|[zy]13)CV matches:
  • AAd12CV
  • AAe12CV
  • AAz12CV
  • AAy13CV

Advanced Debug settings for General Options

For the General Options list, this table describes Advanced controls for Debug Options.

Advanced control Default Description
X-WA-Info Header None This setting is used for troubleshooting purposes. You should not change this setting unless instructed to do so by an F5 Network Technical Support Engineer.
  • None. Disables Debug Options functionality.
  • Standard. Enables the WebAccelerator™ system to insert an X-WA-Info response header, which includes specific codes that describe the properties and history of objects.
  • Debug. Includes advanced troubleshooting parameters.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)