Applies To:

Show Versions Show Versions

Manual Chapter: Configuring Variation Rules
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

10 
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 systems 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:
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
Important: When configuring this variation rule, you must specify a value for the version cookie parameter. If you do not, the WebAccelerator system ignores the cookies 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 WebAccelerator system then serves the first response it caches to any subsequent requests that contain that cookie.
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 sites 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.
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 state of the HTTP USER_AGENT, REFERER, or other request headers
If you do not create a variation rule in these situations, the WebAccelerator system may not provide the content you want when servicing a request.
HTTP request elements that match the variation rule result in unique page content.
The WebAccelerator system 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 WebAccelerator system ignores the value set for the specified parameter, which means that the parameter and its value are not included in the UCI that the WebAccelerator system creates for the request.
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:
When cookie A begins with aa, the page content is the same.
This rule indicates that the WebAccelerator 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 WebAccelerator 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 WebAccelerator system matches all requests that contain a cookie called A with any value that does not begin with 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 WebAccelerator system would match the requests to three different pages.
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 Table 10.1.
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:
A query parameter named computer that has no value set for it
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 override this default behavior by performing the steps in the following procedure.
This section of the chapter provides information about how to configure an example 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 sites search application.
Images
This branch node specifies the rules related to graphics images.
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.
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.
1.
In the navigation pane, expand WebAccelerator and click Policies.
The Policies screen displays a list of existing acceleration policies.
3.
Click the Applications node.
4.
From the Matching Rules list, choose 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:
Note: For more information about regular expressions, see Using regular expressions and meta tags for rules.
9.
From the Values Define list, select Different Content, to prompt the WebAccelerator system to provide a unique page to matched requests.
10.
Click the Save button.
For a new or modified acceleration policy to be in effect for your site, you must publish it. One way to do this is to click the Publish button.
1.
In the navigation pane, expand WebAccelerator and click Policies.
The Policies screen displays a list of existing acceleration policies.
3.
Click the Search node.
4.
From the Matching Rules list, choose 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 the Save button.
For a new or modified acceleration policy to be in effect for your site, you must publish it. One way to do this is to click the Publish button.
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)