system provides the flexibility needed to accelerate Web applications by processing and caching specific HTTP requests and responses. WebAccelerator policies determine how the WebAcclerator system handles and matches each request and response. A Policy Tree, configurable in the Policy Editor screen, contains branch nodes and leaf nodes that comprise a WebAccelerator policy.
Leaf nodes include all of the settings (such as cache lifetime settings or
proxy settings) and matching rules that determine how similar requests are processed. Additionally, grouping multiple leaf nodes under a branch node enables them to inherit the branch node settings.
When a request is received, the type of requested content typically
determines the settings needed to process the request. Because Content-Type
headers only become available when the WebAccelerator system receives a response, the WebAccelerator system provides a matching abstraction for requests called content type
to determine, based on the requests URL and available headers, the probable or actual content type, as well as to simplify the matching rules. For example, by default, requests with an extension of .gif
are given an object type of images
that is used in the abstract content type, which is more convenient to use in matching rules. The mapping for each abstract content type is configured as an Identifier in the Object Types screen.
The predefined content types consist of a descriptive group name (such as documents
) and an object type name (such as msword
). Matching rules can require either or both parts to match, as desired. Many of the default policies have a node for matching documents. Some use the object type abstraction and some use the URL extension.
You configure matching rules from the Matching Rules screen, and
configure Acceleration Rules by choosing Acceleration Rules from the Matching Rules menu.
Matching rules for leaf nodes determine the nodes to which requests and
responses apply. All matching rules for a node must match before it can be considered to be a candidate for a best match. If more than one candidate exists, resolution rules, based upon priority and precedence, determine the single best match.
Sometimes, both precedence and priority can produce a match. When
multiple nodes produce a match, the WebAccelerator system 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.
An exact path match is one where the value set for the path parameter ends
with a question mark. For example, if you have a rule with the following path parameter value:
It is important to note that a path of /
are two different things. A path that includes a ?
indicates that an exact match is required.
By default, a path that you provide for a policy is a prefix. For example, if
you give a parameter the path, /a/b
, the WebAccelerator system considers both of the following requests a match:
If you add a question mark to the parameter so that it is, /a/b?
, the WebAccelerator system considers only the following a match, because the question mark indicates that an exact match is required.
If no single exact path matches, but only one node matches the extension,
the WebAccelerator system considers the request to be an exact extension match, or best match.
For example, if you have a request matching rule that specifies an extension
of jpg, the WebAccelerator system considers the following request an exact extension match, and matches the request to the leaf node to which the rule belongs.
If no single node matches an exact path or exact extension, but only one
node matches a path segment, the WebAccelerator system considers the request to be an exact path segment match, or best match.
Matching rules based on a path segment (the text between two slash marks)
have third priority over other parameter matches. If a single path segment matches a path segment within the path, the WebAccelerator system matches the request to the leaf node to which the rule belongs.
For example, if you have a rule that specifies a path segment of a, the
WebAccelerator system considers the following request an exact match, and matches the request to the leaf node to which the rule belongs.
If the request does not match a single path node, a single extension node, or
a single path segment node, but multiple extension nodes match, the WebAccelerator system applies specific matching rules to determine the best match.
Matching rules based on multiple extension matches have a fourth priority
over other parameter matches. If multiple extension matches occur, only the following rules apply:
| || |
| || |For example, if you have a rule that specifies an
extension of jpg
, the rule matches request with the longest path, specifically Node 1 of the following:
| |Node that matches the
most conditions, if multiple matching nodes have the same path length
| |For example, if you have two rules that specify the
same path, but the second rule also specifies a matching path segment, then the second rule matches the request to the leaf node to which the rule belongs. In this example, Node 1 in the following is matched:
| |Node with the lowest
ordinal number, if multiple matching nodes have the same path length and number of conditions
| |For example, if you have two rules that specify the
same path and include the same number of conditions, then the node with the lowest ordinal number from the policy is matched. In this example, Node 2 in the following is matched:
If a request does not match a leaf node in the Policy Tree, there is an
unmatched node in the Policy Tree, and the WebAccelerator system 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 WebAccelerator system 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 WebAccelerator system does not consider it a match, and processes it as an unmatched request.
This section of the chapter provides information about how to configure an
example matching rule. For this example site, you have three top-level nodes on the Policy Tree as follows: