Applies To:Show Versions
- 12.1.5, 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0
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.
Cache efficiency improvement
By default, the BIG-IP includes the following HTTP request parameters in the UCI.
- Query Parameter
- Path Segment
If the content that your application serves is not dependent on the presence or value of these parameters in an HTTP request, you should create a rule so that when the BIG-IP assembles a UCI, it does not include those parameters.
Effective variation rules can result in a significant resource savings. For example, if your site uses a query parameter that provides session tracking information, and your site's pages are not affected by the value set for the session tracking query parameter, you can configure a variation rule to identify the session tracking query parameter as not significant for content. This way, the BIG-IP caches one version of the page for any value of the session tracking query parameter. Without a variation rule, the BIG-IP creates one unique compiled response for every page that every user views. This results in an unnecessarily large cache.
By default, the BIG-IP does not include the following HTTP request elements in the UCI.
- User Agent
- Client IP
You must create a variation rule if the content you want to serve is dependent on one of these elements. That is, configure a variation rule if you want to serve different content based on.
- The method that a request uses
- The state of a cookie contained in a request
- The connecting client’s IP address
- The state of the HTTP USER_AGENT, REFERER, or other request headers
If you do not create a variation rule in these situations, the BIG-IP might not provide the content you want when servicing a request.
Definition of variation rules parameters
When you define a variation rule, you specify one of the following behaviors for a parameter.
- HTTP request elements that match the variation rule result in unique page content. The BIG-IP uses the specified parameter and its value in the UCI it creates for the request.
- HTTP request elements that match the variation rule do not result in unique page content. The BIG-IP ignores the value set for the specified parameter, which means that the parameter and its value are not included in the UCI that the BIG-IP creates for the request.
Variation rules affect the UCI independently of whether the response was cached. Therefore, the BIG-IP applies variation rules to all requests after it matches the request to a node, even when it sends the request to the origin server for fresh content.
A value group is a collection of values for a variation rule parameter, enabling you to define several different parameter values for the same variation rule. Each value can prompt a different behavior by the BIG-IP system.
For example, a matching rule based on cookie A can only specify a single set of values for the cookie, depending on a match or a no match. For more flexibility, you could use a variation rule with a value group for cookie A, consisting of several rules such as these examples.
- When cookie A begins with aa, the page content is the same. This rule indicates that the BIG-IP system matches all requests to the same page if the request contains a cookie called A with a value that begins with aa.
- When cookie A begins with bb, the page content is the same. This rule indicates that the BIG-IP system matches all requests to the same page if the request contains a cookie called A with a value that begins with bb. However, the page it matches is different from the page for cookie A with a value of aa.
- For all other cookie A values, page content is unique. This rule indicates that the BIG-IP system matches all requests that contain a cookie called A with any value that does not begin with aa or bb, to a unique page specified for each cookie value. That is, if there were three requests with three different values for cookie A (such as ca233, ca234, ba234), the BIG-IP system would match the requests to three different pages.
Management of conflicting rules parameters
If a request matches two or more variation rule parameters, and the parameters define conflicting behavior (one parameter indicates that the value is significant for content and the other does not), the BIG-IP considers the parameter significant for content. This means that the BIG-IP compiles a separate response for the conflicting parameter value in the request.
If a request element matches a variation rule that contains conflicting named and unnamed query parameter values, the BIG-IP considers the query parameter ambiguous because it is not clear which value the BIG-IP should use when processing the request. For example, consider a variation rule with the parameters configured as outlined in the following table.
|Parameter||Value Match||Content to Serve|
|All other query parameters||All values||different content|
|Unnamed query parameter in ordinal 1||All values||same content|
When applying this variation rule to the request for http://www.siterequest.com/show.jsp?computer&vendor=whiteBox, the BIG-IP could interpret computer as either of the following.
- A query parameter named computer that has no value set for it.
- An unnamed query parameter in ordinal 1, for which the value is set to computer.
In this example, it is unclear whether the BIG-IP should use computer in the UCI, and whether the result is a unique page. Therefore, the BIG-IP determines that the query is ambiguous, and matches the request to the node with the highest priority on the Policy Tree.
By default the BIG-IP treats all ambiguous query parameters as a named query parameter without a value. You can, however, override this default behavior.