F5 Logo MyF5
Search
  1. MyF5 Home
  2. Knowledge Centers
  3. BIG-IP AAM
  4. BIG-IP Acceleration: Implementations
  5. Differentiating Requests and Responses with Variation Rules
Manual Chapter : Differentiating Requests and Responses with Variation Rules

Applies To:

Show Versions Show Versions

BIG-IP AAM

  • 12.1.5, 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0, 11.6.5, 11.6.4, 11.6.3, 11.6.2, 11.6.1
Manual Chapter
Table of Contents | << Previous Chapter | Next Chapter >>

Differentiating Requests and Responses with Variation Rules

Overview: Variation rules

When the BIG-IP® system caches responses from the origin web server, it uses certain HTTP request parameters to create a Unique Content Identifier (UCI). The BIG-IP system stores the UCI in the form of a compiled response, and uses the UCI to easily match future requests to the correct content in the module's cache.

You can configure variation rules to add or modify the parameters on which the BIG-IP system bases its caching process. If the BIG-IP system receives two requests that are identical except for the value of a query parameter defined in the variation rule, it creates a different UCI for each, and caches each response under its unique UCI.

Consider a site that receives requests from customers and partners, and wants to serve different content to each. For this site, you could create a variation rule in which you specify that when a request contains a version cookie set to a value of 1, the BIG-IP system serves a page specifically for customers, and when the version cookie is set to a value of 2, it serves a page specifically for partners. For this rule, the BIG-IP system caches the following three compiled responses.

  • For content produced for Cookie: version=1.
  • For content produced for Cookie: version=2.
  • For content produced when the version cookie does not appear in the request.
Note: When configuring this variation rule, you must specify a value for the version cookie parameter. If you do not, the BIG-IP system ignores the cookie's value and produces, at most, two compiled responses: one for requests that contain the cookie, and one for requests that do not contain the cookie. The BIG-IP system then serves the first response it caches to any subsequent requests that contain that cookie.

Configuring variation rule settings

You can configure variation rules to add or modify the parameters on which the BIG-IP system bases its caching process. If the BIG-IP system receives two requests that are identical except for the value of a variation rule parameter, it creates a different UCI for each, and caches each response under its unique UCI.
  1. On the Main tab, click Acceleration > Web Application > 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 Variation.
  6. Define the parameters that the BIG-IP system must match in a request.
The BIG-IP system creates a unique UCI for requests with different variation rule parameter values, and caches each response under its unique UCI.

Configuring ambiguous query parameters as unnamed

By default the BIG-IP system treats all ambiguous query parameters as a named query parameter without a value. You can, however, override this default behavior.
  1. On the Main tab, click Acceleration > Web Application > 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 Variation.
  6. Click All Query Parameters.
  7. Select the Treat ambiguous parameters as unnamed check box.
  8. Click Save.
The BIG-IP system treats all ambiguous query parameters as unnamed query parameters.

Variation rule example

This example shows a variation rule for a user-defined acceleration policy. For this example site, you have three top-level nodes on the Policy Tree.

  • Home. This branch node specifies the rules related to the home page.
  • Applications. This branch node specifies the rules related to the applications for the site, with the following leaf nodes.
    • Default. This leaf node specifies the rules related to non-search related applications.
    • Search. This leaf node specifies the rules related to your site’s search application.
  • Images. This branch node specifies the rules related to graphics images.

This site also has the following two considerations.

  • It needs to provide different branding information if the REFERER request header begins with, http://www.siterequest.com. Any other value for the REFERER request header does not affect the content served by your site.
  • It uses a query parameter called sessionID to track site users. This query parameter does not affect page content, and is used for tracking purposes only.

For this example, you create the following two variation rules.

  • REFERRER rule. You base this rule on the REFERER data type, and set it on the Applications node.
  • Query Parameter rule. You base this rule on the Query Parameter data type, and set on the Search node.

Creating an example Referrer rule

This example provides steps to configure a Referrer rule.
  1. On the Main tab, click Acceleration > Web Application > Policies .
    The Policies screen displays a list of existing acceleration policies.
  2. Click the name of a user-defined acceleration policy.
  3. Click the Applications node.
  4. From the Matching Rules list, select Acceleration Rules.
  5. Click Variation.
  6. Click Referrer.
  7. In the Value Groups area, click Add.
  8. Select the Values matches check box, and in the adjacent box, type the regular expression that matches the value you expect on the REFERER request header, as follows: http://www\.siterequest\.com.*.
  9. From the Values Define list, select Different Content, to prompt the BIG-IP system to provide a unique page to matched requests.
  10. Click Save.
  11. Publish the acceleration policy.
    1. Click Publish.
    2. In the Comment field, type a description.
    3. Click Publish Now.
The example Referrer variation rule is configured.

Creating an example Query Parameter rule

The example provides steps to configure a Query Parameter rule.
  1. On the Main tab, click Acceleration > Web Application > Policies .
    The Policies screen displays a list of existing acceleration policies.
  2. Click the name of a user-defined acceleration policy.
  3. Click the Search node.
  4. From the Matching Rules list, select Acceleration Rules.
  5. Click Variation.
  6. From the Add Parameter list, select Query Parameter and click the Add button.
  7. In the Name box, type sessionID.
  8. In the Values Groups area, click the Add button.
  9. Select the Values matches check box, and in the adjacent box, type the following regular expression, to indicate that the query parameter can have any value: .*.
  10. Select the Value is an empty string check box.
  11. From the Values Define list, select Same Content, to indicate that page content is not affected by this parameter.
  12. Click Save.
The example Query Parameter variation rule is configured.
Table of Contents | << Previous Chapter | Next Chapter >>
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5 Networks, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information