When the WebAccelerator™ system caches responses from the origin web server, it uses certain HTTP request parameters to create a Unique Content Identifier (UCI). The WebAccelerator 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 system's cache.
You can configure variation rules to add or modify the parameters on which the WebAccelerator system bases its caching process. If the WebAccelerator 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 WebAccelerator 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 WebAccelerator system caches the following three compiled responses.
By default, the WebAccelerator™ system includes the following HTTP request parameters in the UCI.
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 WebAccelerator system 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 WebAccelerator system caches one version of the page for any value of the session tracking query parameter. Without a variation rule, the WebAccelerator system creates one unique compiled response for every page that every user views. This results in an unnecessarily large cache.
By default, the WebAccelerator™ system does not include the following HTTP request elements in the UCI.
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.
If you do not create a variation rule in these situations, the WebAccelerator system might not provide the content you want when servicing a request.
When you define a variation rule, you specify one of the following behaviors for a parameter.
Variation rules affect the UCI independently of whether the response was cached. Therefore, the WebAccelerator system 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 WebAccelerator™ 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.
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 WebAccelerator™ system considers the parameter significant for content. This means that the WebAccelerator system 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 WebAccelerator system considers the query parameter ambiguous because it is not clear which value the WebAccelerator system 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 WebAccelerator system could interpret computer as either of the following.
In this example, it is unclear whether the WebAccelerator system should use computer in the UCI, and whether the result is a unique page. Therefore, the WebAccelerator system determines that the query is ambiguous, and matches the request to the node with the highest priority on the Policy Tree.
By default the WebAccelerator system treats all ambiguous query parameters as a named query parameter without a value. You can, however, override this default behavior.