6

Configuring Matching Rules

Matching requests to nodes

To match HTTP requests to associated acceleration policies, the WebAccelerator system analyzes the information in the HTTP request and uses the matching rules to group the requests. Once matched to an acceleration policy, the WebAccelerator system applies the associated caching rules to each group of HTTP requests. The matching and caching rules that the WebAccelerator system uses to perform application matching are organized in a Request Type Hierarchy tree, with each node in the Request Type Hierarchy consisting of matching rules and associated caching rules.

For example, for images files you might define a matching rule based on common image extensions found in HTTP requests. In this case, you could define an Image node in the Request Type Hierarchy tree with a matching rule for requests that contain an extension of gif, GIF, jpg, JPG, jpeg, or JPEG. When the WebAccelerator system matches a request to the Image node, it applies the associated caching rules to properly handle image files for your site.

The WebAccelerator system performs application matching only against leaf nodes in the Request Type Hierarchy tree. Each leaf node has its own matching rule, with one or more defined parameters. For an HTTP request or response to match to a specific leaf node, it must match all the matching rules defined for the leaf node.

On the Request Type Hierarchy tree, create a leaf node for the matching rule. To inherit rules from an existing rule, add it as a leaf node under a parent node.

Define matching rules that identify the requests that you want to handle in a particular way.

Create a set of caching rules to handle requests that match to the node you created.

Specifying matching parameters

For the WebAccelerator system to match a parameter in an HTTP request to a parameter in a matching rule, the parameter in the HTTP request must be in the same state as it is in the defined rule.

For example, if you create a matching rule based on a Cookie parameter named sessionID, you specify that the sessionID cookie must be in one of the following states:

absentThe parameter does not appear in the request.

emptyThe parameter appears in the request, but has no value set for it.

appears with a specified valueThe parameter appears in the request and matches a value that you specify. For example, its value must begin with a number.

If the WebAccelerator system receives an HTTP request with a sessionID Cookie parameter that is in the same state that you specified in the matching rule, the WebAccelerator system matches the request to that rule. If the request also matches all of the other rules for the node, the WebAccelerator system considers it a match for the node and assigns the HTTP request to the matched node. The WebAccelerator system then applies all of the associated cache rules for the matched node, such as variation and lifetime, to the HTTP request.

NoteFor some parameters, you can specify that the parameter name is case-sensitive, by enabling the Values are case sensitive setting when configuring the parameter options. For additional information about defining parameters, see
Specifying HTTP request data type parameters
, located in Chapter 5.

Matching precedence rules

When performing application matching, the WebAccelerator system chooses:

The most specific match, over a more general match.

A superset over a subset.

Nodes based on priority.

For example, if two nodes have matching rules based on a Path parameter, and a request matches both, then the WebAccelerator system matches to the node with the rule that specifies the longest (most specific) Path parameter.

Or, if you have two nodes defined as follows:

Node 1Contains matching rules based on three query parameters.

Node 2Contains matching rules based on two of the same three query parameters as Node 1.

The WebAccelerator system considers a request that matches all three query parameters as a match. However, the WebAccelerator system matches the request to Node 1, because that node is a superset and is the best match.

Conversely, if you have two nodes defined as follows:

Node 1Contains three matching rules based on three query parameters.

Node 2Contains two matching rules based on two query parameters.

The WebAccelerator system considers the query ambiguous, because the matching rules do not dictate that one node is a better match than another node. For ambiguous queries, the WebAccelerator system chooses between the nodes based on priority.

Matching rules based on the Extension parameter have the next highest priority. If the extension on a request matches the extension parameter specified by an matching rule, the WebAccelerator system matches the request to the node to which the rule belongs.

Paths as prefixes

It is important to note that a path of / and /? 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:

http://www.siterequest.com/a/b?treat=bone

http://www.siterequest.com/a/b/c?toy=ball

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.

http://www.siterequest.com/a/b?treat=bone

Processing unmatched requests

If a request does not match any leaf nodes in the Request Type Hierarchy, the WebAccelerator system either uses a pre-defined accelerator policy that manages unmatched requests and responses, or sends the request to the origin server.

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

Configuring an application matching example

This section of the chapter provides information about how to configure an application matching rule. For this example site, you have three top-level nodes in the Request Type Hierarchy tree as follows:

HomeSpecifies the rules related to the home page.

ApplicationsSpecifies the rules related to the applications for the site, with child nodes, such as: