Applies To:

Show Versions Show Versions

Manual Chapter: Policy Management Guide for the BIG-IP WebAccelerator Module: 6 - Configuring Matching Rules
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


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.

For specific information about how to create nodes on the Request Type Hierarchy tree, see Configuring a Request Type Hierarchy tree example , located in Chapter 4.

To create matching rules, you perform the following tasks:

  • 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:

  • absent
    The parameter does not appear in the request.
  • empty
    The parameter appears in the request, but has no value set for it.
  • appears with a specified value
    The 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.

Note

For 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 1
    Contains matching rules based on three query parameters.
  • Node 2
    Contains 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 1
    Contains three matching rules based on three query parameters.
  • Node 2
    Contains 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.

For more information about ambiguous parameters, see Ambiguous query parameters , located in Chapter 7. For information about how to modify node priority, see To change the priority of a node on the Request Type Hierarchy tree , located in Chapter 4.

Additional application matching considerations

In addition to the precedence rules, the WebAccelerator system also considers the following when performing application matching.

  • Matching based on the Path parameter takes priority over other matches, and an exact path match is always chosen before other path matches.
  • An exact path match is one where the value set for the Path parameter includes the question mark.

    For example, if you have a rule with the following Path parameter value:

    apps/srch.jsp?

    The WebAccelerator system considers the following request an exact match.

    http://www.siterequest.com/apps/srch.jsp?value=computers

    For more information about paths, see Paths as prefixes .

  • 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:

  • Home
    Specifies the rules related to the home page.
  • Applications
    Specifies the rules related to the applications for the site, with child nodes, such as:
    • Default
      Specifies the rules related to non-search related applications.
    • Search
      Specifies the rules related to your site's search application.
  • Images
    Specifies the rules related to graphics images.
Note

See, To create the Home, Application, and Images nodes for the example Request Type Hierarchy tree , located in Chapter 4, for specific instructions about how to create the Request Type Hierarchy tree.

You configure matching rules for this example, on the Request Type Hierarchy tree nodes, as described in Table 6.3 .

Table 6.3 Application matching rules example configuration
Node
Application matching parameter
Home
Create a rule based on the Path data type. Provide the following two two values for the Path parameters:
/index.jsp
/?
Default
Create a rule based on the Path data type. Provide the following value for the Path parameter:
/apps
Search
Create a rule based on the Path data type. Provide the following value for the Path parameter:
/srch
Images
Create a rule based on the Path data type. Provide the following value for the Path parameter:
/images

To create the example matching rules

  1. On the Main tab of the navigation pane, click Policies.
    The Policies screen opens, displaying a list of acceleration policies.
  2. Click Edit next to the acceleration policy example you created for, To create the Home, Application, and Images nodes for the example Request Type Hierarchy tree , located in Chapter 4.
    The Policy Editor screen opens.
  3. From the Request Type Hierarchy tree, click the Home node.
  4. On the acceleration policy menu bar, click Matching.
    The Matching rules screen opens.
  5. From the Add Parameter list, select Path, and click the Add button.
    The path parameter screen opens.
  6. In the Value(s) box, type the values on which you want to base application matching.
  7. For this example, type the following:
    /index.jsp
    /?

  8. Click the Save button.
    The path parameter screen refreshes with the new parameter.
  9. From the Request Type Hierarchy tree, click the Default node.
  10. On the acceleration policy menu bar, click Matching.
    The Matching rules screen opens.
  11. From the Add Parameter list, select Path, and click the Add button.
    The path parameter screen opens.
  12. In the Value(s) box, type the values on which you want to base application matching.
  13. For this example, type the following:

    /apps

  14. Click the Save button.
    The path parameter screen refreshes with the new parameter.
  15. From the Request Type Hierarchy tree, click the Search node.
  16. On the acceleration policy menu bar, click Matching.
    The Matching rules screen opens.
  17. From the Add Parameter list, select Path, and click the Add button.
    The path parameter screen opens.
  18. In the Value(s) box, type the values on which you want to base application matching.
  19. For this example, type the following:

    /srch

  20. Click the Save button.
    The path parameter screen refreshes with the new parameter.
  21. From the Request Type Hierarchy tree, click the Images node.
  22. From the acceleration policy menu bar, click Matching.
    The Matching rules screen opens.
  23. From the Add Parameter list, select Path, and click the Add button.
    The path parameter screen opens.
  24. In the Value(s) box, type the values on which you want to base application matching.
  25. For this example, type the following:
    /images

  26. Click the Save button.
    The path parameter screen refreshes with the new parameter.

For a new or modified acceleration policy to be in effect for your site, you must publish it. See Publishing acceleration policies , located in Chapter 3, for more information.




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)