Applies To:

Show Versions Show Versions

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

The WebAccelerator system manages content in the form of compiled responses in its cache, which contain applets that the WebAccelerator system uses to assemble pages. The WebAccelerator determines how to assemble content, using:
How to change parameter values for embedded URLs by substituting values from the request, or by randomly generated values
Page assembly instructions for optional Edge-Side Include (ESI) markup tags to specify HTML fragments to include in the page, as described in Appendix C, Assembling Content with Edge Side Includes.
Since the WebAccelerator system performs content assembly after it matches the response to a node, it always uses the matched response nodes assembly rules, which it caches as part of the original compiled response. If the response matches to a different node than the request, the WebAccelerator system considers the assembly rules associated with the requests node as irrelevant.
The parameter value substitutions that you define for a leaf node are a combination of the rules defined locally at the node, and the rules inherited from the nodes ancestors. For information about inheritance support in the Policy Tree, see Understanding rule inheritance within the Policy Tree.
When a client requests content from a web server, the clients browser places the content it receives into its local cache. If the cached content does not contain an expiration time, the browser makes subsequent requests for that content using a conditional GET request. This conditional GET request takes the form of an extra request header field such as If-Modified-Since. If the requested object appears to be different from the content the browser has cached, the web server sends a fresh copy of the object to the browser. Otherwise, the browser uses the object that is cached on its local disk.
Although faster than serving the entire object each time the browser requests it, the conditional GET requests can add up to a significant amount of traffic for your site. When a large number of conditional GETS occur for sites serving (for example) several images for each page, clients may perceive a slow response time.
The WebAccelerator systems Intelligent Browser Referencing feature increases the efficiency of the clients web browsers local cache by reducing or eliminating requests to your site for relatively static content, such as images and style sheet (CSS) files. The WebAccelerator system does this by managing the web browsers cache, as follows:
Serving qualifying content with the expiration time set long enough (180 days) that it is unlikely that the browser re-requests the content in the near future.
Using a pv tag to append a unique value to qualifying links or URLs embedded in your web pages. This value is a hash of the object and as such is guaranteed to uniquely identify the corresponding content stored in the WebAccelerator systems cache.
Image tags
For example: <img src="...">
Script tags
For example: <script src="...">
Link tags
For example: <link href="...">
Forms, for which the input type is an image:
For example: <form><input type="mage" src="...."></form>
For the WebAccelerator system to apply the Intelligent Browser Referencing feature to these tags, the following conditions must be true:
There are no variation rules defined for the link.
For example, if the link matches to a variation rule that identifies a cookie as being significant for content, the WebAccelerator system cannot apply the Intelligent Browser Referencing feature.
This section of the chapter provides information about how to configure an example scenario that uses the Intelligent Browser Referencing feature. For this example, your site serves a simple page that consists of two image files that appear as follows:
<html>
<head><title>example page</title></head>
<body>
<p>The images that your site serves:</p>
<p><img src=myImages/image1.jpeg></p>
<p><img src=myImages/image2.jpeg></p>
</body>
</html>
<html>
<head><title>example page</title></head>
<body>
<p>The images that your site serves:</p>
<p><img src=myImages/image1.jpeg;pvRG2076ND></p>
<p><img src=myImages/image2.jpeg;pv7YW905BV></p>
</body>
</html>
The pv tag that the WebAccelerator system appends to each image source URL, a hash of the image that the WebAccelerator system has stored in its cache. In addition, the browser receives a long expiration time for each of the image files.
If an image on the page is modified, the WebAccelerator system changes the pv tag for the image and informs the client of the change. When the client performs a subsequent conditional GET request for the base page and receives the refreshed page, it compares the image and notes the difference between image1.jpeg;pv4RR87M90 and image1.jpeg;pvRG2076ND. This difference prompts the client to re-request the image from the WebAccelerator system.
When the Intelligent Browser Referencing feature is enabled, the WebAccelerator system ignores browser cache minimum age settings that apply to objects affected by the Intelligent Browser Referencing feature. However the HTML page, into which those objects are loaded, honors all browser cache minimum age settings. For more information about browser age settings, see Configuring a lifetime rule example.
1.
On the Main tab of the navigation pane, expand WebAccelerator and click Applications.
The Applications screen opens in a new window.
2.
On the Main tab of the navigation pane in the new window, click Policies.
The Policies screen opens, displaying a table of user-defined and pre-defined acceleration policies.
3.
On the User-defined Acceleration Policies table, click the name of the acceleration policy that you want to edit.
The Policy Editor screen opens.
5.
From the Matching Rules list on the Policy Editor menu bar, select Acceleration Rules.
The acceleration rules display on the Policy Editor menu bar.
6.
On the Policy Editor menu bar, click Assembly.
The Assembly rule screen opens.
7.
Check the Enable Intelligent Browser Referencing check box.
8.
Click the Save button.
The screen refreshes.
Important: If you enable the Intelligent Browser Referencing feature, you must also enable the Perform content assembly on proxies setting, as described in Setting the Enable Content Compression option.
Most web browsers create a limited number of persistent TCP connections when requesting data. You can achieve faster data downloads by using the WebAccelerator systems MultiConnect feature, which modifies embedded URLs with unique subdomains, prompting the browser to open more persistent TCP connections (up to two per subdomain generated by the WebAccelerator system).
When MultiConnect is enabled, it prompts the clients web browser to open up to four persistent connections to the WebAccelerator system for each subdomain when requesting pages over the HTTP protocol. The origin web servers never get a request from these additional subdomains; the additional subdomains are used exclusively on embedded URLs or links that request images or scripts are only for requests and/or responses between the client and the WebAccelerator system. If the WebAccelerator system needs to send a request to the origin server, it automatically removes the subdomain prefixes before sending the request.
The MultiConnect feature is best suited for sites that have a high number of first-time visitors who are downloading a large number of images or scripts. F5 Networks recommends that you use this feature only if you have low-latency, high-bandwidth links, because the additional TCP connections also increase the amount of traffic your site has to handle.
Image tags:
<img src="...">
Script tags:
<script src="...">
Forms whose input type is an image:
<form><input type="image src="..."></form>
Assign specific prefixes to the additional subdomains. For example, if the requested host for the mapping is www.siterequest.com and you request two additional subdomains for the HTTP protocol, you assign a subdomain prefix of wa.
Unless you perform these required tasks, the WebAccelerator system does not apply the MultiConnect feature, even if you enable the feature for a specific acceleration policy. For information about these required tasks, see the Configuration and Maintenance chapter in the Administrator Guide for the BIG-IP® WebAccelerator System.
Once configured, the WebAccelerator system changes the domain on qualifying embedded URLs and links to use the domains you specified. For example:
This section of the chapter provides an example scenario for the MultiConnect feature. For this example, your site serves a simple page (http://www.siterequest.com/index.htm) that consists of several image files. The page that your site serves appears as follows:
<html>
<head><title>example page</title></head>
<body>
<p>The images that your site serves:</p>
<p><img src=myImages/image1.jpeg></p>
<p><img src=myImages/image2.jpeg></p>
<p><img src=myImages/image3.jpeg></p>
<p><img src=myImages/image4.jpeg></p>
</body>
</html>
An additional subdomain prefix of wa is configured for the host map and the MultiConnect feature enabled, so the WebAccelerator system modifies the page and serves it as follows:
<html>
<head><title>example page</title></head>
<body>
<p>The images that your site serves:</p>
<p><img src=http://wa1.www.siterequest.com/myImages/image1.jpeg></p>
<p><img src=http://wa2.www.siterequest.com/myImages/image2.jpeg></p>
<p><img src=http://wa2.www.siterequest.com/myImages/image3.jpeg></p>
<p><img src=http://wa1.www.siterequest.com/myImages/image4.jpeg></p>
</body>
Important: Before enabling the MultiConnect feature for an acceleration policy, you must configure the additional subdomains prefixes in the host map. The WebAccelerator system does not apply this feature, unless the additional subdomains prefixes have been assigned. For information about configuring a host map, see the Configuration and Maintenance chapter in the Administrator Guide for the BIG-IP® WebAccelerator System.
1.
In the navigation pane, expand WebAccelerator and click Policies.
The Policies screen opens, displaying a table of user-defined and pre-defined acceleration policies.
2.
On the User-defined Acceleration Policies table, click the name of the acceleration policy that you want to edit.
The Policy Editor screen opens.
4.
From the Matching Rules list on the Policy Editor menu bar, select Acceleration Rules.
The acceleration rules display on the Policy Editor menu bar.
5.
On the Policy Editor menu bar, click Assembly.
The Assembly rules screen opens.
6.
Check the Enable MultiConnect check box.
7.
Click the Save button.
The screen refreshes.
Content compression can improve the perceived performance of your site and reduce your sites bandwidth costs by reducing the size of the data that the WebAccelerator system serves. You can use assembly rules to identify content that you want the WebAccelerator system to compress using gzip-encoding.
The compressToClient value (set in the global configuration fragment globalfragment.xml file) for the responses object type
Whether the Enable Content Compression feature is set on the node for the assembly rule, to which the request and response are matched
It is important to keep in mind that, if set to anything other than policyControlled, the compressToClient value in the globalfragment.xml overrides the Enable Content Compression setting for the assembly rule. Therefore, if the compressToClient value is set to none, the WebAccelerator system never compresses the response. If the compressToClient value is set to wa, the WebAccelerator system compresses the response only if the client is another WebAccelerator system. However, if the compressToClient value is set to policyControlled, the WebAccelerator system uses the content compression setting for the assembly rule to determine whether to compress the response.
In addition, the client must indicate whether it can accept gzip-encoded content by specifying the appropriate values on the Accept-Encoding HTTP request header. If the client does not indicate that it can accept gzip-encoded content, the WebAccelerator system does compress the content.
Note: In general, F5 Networks recommends that you do not enable the Enable Content Compression setting for content that does not benefit from compression, such as image object types like gif and jpeg. By default, the compressToClient value for image object types is set to none, so compression is disabled for those objects. For information about modifying objects in the globalfragment.xml file, see the Changing Configuration Options chapter in the Administrator Guide for the BIG-IP® WebAccelerator System.
1.
In the navigation pane, expand WebAccelerator and click Policies.
The Policies screen opens, displaying a table of user-defined and pre-defined acceleration policies.
2.
On the User-defined Acceleration Policies table, click the name of the acceleration policy that you want to edit.
The Policy Editor screen opens.
4.
From the Matching Rules list on the Policy Editor menu bar, select Acceleration Rules.
The acceleration rules display on the Policy Editor menu bar.
5.
On the Policy Editor menu bar, click Assembly.
The Assembly Rules screen opens.
6.
Check the Enable Content Compression check box.
7.
Click the Save button.
The screen refreshes.
Important: If you enable the content compression feature, you must also enable the perform content assembly on proxies feature, as described in the following section.
When the Content Assembly on Proxies feature is enabled, the WebAccelerator system applies assembly rules to a response after forwarding a request to the origin server, and before sending the response to the client. This primary purpose of this feature is to allow the WebAccelerator system to compress content as required, and to manage content using the Intelligent Browser Referencing feature, even if the content is not served from the WebAccelerator systems cache. Therefore, check the box for Enable Content Assembly on Proxies whenever you check the box for Enable Content Compression or Enable Intelligent Browser Referencing.
When this feature is not enabled, the WebAccelerator system does not modify responses that it receives from the origin web servers before it forwards the responses to the client.
Note: Regardless of the value selected for this option, the WebAccelerator system always applies assembly rules to content if the response from the origin web servers indicates that the response contains ESI assembly instructions.
1.
In the navigation pane, expand WebAccelerator, and then click Policies.
The Policies screen opens, displaying a table of user-defined and pre-defined acceleration policies.
2.
On the User-defined Acceleration Policies table, click the name of the acceleration policy that you want to edit.
The Policy Editor screen opens.
4.
From the Matching Rules list on the Policy Editor menu bar, select Acceleration Rules.
The acceleration rules display on the Policy Editor menu bar.
5.
On the Policy Editor menu bar, click Assembly.
The Assembly Rules screen opens.
6.
Check the box for Enable Content Assembly on Proxies.
7.
Click the Save button.
The screen refreshes.
When you configure parameter value substitution for an assembly rule, the WebAccelerator system changes the targeted parameters value on a specific page it serves from its cache, so that the parameter you specify appears on the URL embedded in the page. You can use this option when a query parameter contains identification information for the sites visitors.
For example, some pages served include hyperlinks that require that specific information appears on the pages. By using parameter value substitution in assembly rules to identify these situations, the WebAccelerator system can take the value presented for an identified source on an HTTP request, and embed that value in the appropriate locations in the pages URL, when it serves the page.
Without parameter value substitution, the WebAccelerator system uses (for all subsequent requests) the value that it cached for the original request even if the subsequent requests have different values that should be used in response. For example, if the original request that generated the cached page contained the following URL:
<a href=http://www.siterequest.com/apps/shoppingCart.jsp?shopper=AAnb35vnM09&....>link</a>
<a href=http://www.siterequest.com/apps/shoppingCart.jsp?shopper=AAnb35vnM09&....>link</a>
If you create an appropriate parameter value substitution, the WebAccelerator substitutes the original cached value for shopper, replacing it with the value in the request as follows:
<a href=http://www.siterequest.com/apps/shoppingCart.jsp?shopper=SNkj90qcL47&....>link</a>
If the source you specify for the substitution does not appear on the request, the WebAccelerator system removes the parameter in its entirely from the qualifying embedded URLs. In the previous example, if a subsequent request were simply:
The WebAccelerator system only performs parameter value substitution for pages that it serves from cache. The WebAccelerator system does not perform substitution for responses to requests for which it has just received fresh content from the origin server.
When you configure parameter value substitution parameters, you define a source and a target type. You also have the option to provide a URL prefix for the target, to limit the URLs to which the WebAccelerator system performs the substitution.
A source definition contains the value that the WebAccelerator system embeds in the URL, in place of the cached (target) value. Typically, the source is a specific request element, such as a particular query parameter, and the WebAccelerator system replaces that value during substitution. However, you can specify another source type, such as a random number, as described in Random value substitution.
When you define the source, you identify the parameter by data type and name or location in the request. For example, if the source is a query parameter, you specify its name. If the source is an unnamed query parameter, you specify its ordinal, which defines its location in the request URL.
If you use the request URL as the source, the WebAccelerator system uses the entire request URL as the value to substitute.
then the target for the substitution is the url query parameter in the embedded URL of the cached page. After substitution, the embedded URL, as served by the WebAccelerator system, appears as follows:
<a href=http://www.siterequest.com/anotherthing.jsp?
url=http%3A%2F%2Fwww.siterequest.com%2Fapps%2Fsomething.jsp?
entity=orange&....>
A target definition contains the value from the source definition in the embedded URL. The target is always a specific request element, such as a particular query parameter, and the WebAccelerator system replaces its value during substitution.
When you define the target, you identify the parameter by data type and name or location in the request. For example, if the target is a query parameter, you specify its name. If the target is an unnamed query parameter, you specify its ordinal, which defines its location in the embedded URL.
Although you can specify the same request element for both the source and the target, the parameter specified for the source is located in the request URL and the parameter specified for the target is located in the embedded URL in the cached page.
By default, the WebAccelerator system performs substitution on all embedded URLs in which the identified target appears. You have the option to limit which URLs embedded in a page are targeted for substitution by specifying a prefix that an embedded URL must match before the WebAccelerator system performs substitution.
For example, if you identify the target of the substitution as the entity query parameter, and you limit the substitution to embedded URLs that match the following:
When configured, the assembly rules random value substitution setting generates a random number and places that number on a targeted location in an embedded URL. When the WebAccelerator system compiles the page into a response, it examines the target location to see the length of the string used for the value. On subsequent page requests, the WebAccelerator system replaces that value with a random number of the same length.
This feature is generally used for sites that make use of an internet advertisement agency. They require random numbers to be placed on URLs that request ads as a way to interrupt traditional caches. By requiring a random number, these internet advertisement agencies force all such traffic to their site. For example, if a cached page includes the embedded URL as follows:
You can configure random value substitution so that the WebAccelerator system sets random values set for the entity query parameter for subsequent pages as follows:
Important: The WebAccelerator system ignores parameter value substitution (including random value substitution) if it conflicts with ESI markup.
You can specify advanced assembly option strings to override system settings for a specific node. These strings enable features for the specified node that are currently disabled for the system. You can enable these features for any request or response that matches the matched node.
Note: Because the system-wide default for most of these features is set to false, you need to set these features to false only if you are overriding an inherited true setting from a parent node.
Where module is the name of an authentication adapter module you want the WebAccelerator system to load and run for requests/responses that match this node.
When set to true, the WebAccelerator system internally follows redirects unless certain conditions, such as protocol or domain changes, are met.
When set to true, the WebAccelerator system attempts to generate a Last-Modified header for the response.
When set to true, this disables the content-based identity feature for the node.
The system-wide default is false, which means that if content-based identity is in effect, it is not disabled for the node.
For more information about content-based identity, see the Administrator Guide for the BIG-IP® WebAcceleratorTM System.
1.
In the navigation pane, expand WebAccelerator, and then click Policies.
The Policies screen opens, displaying a table of user-defined and pre-defined acceleration policies.
2.
On the User-defined Acceleration Policies table, click the name of the acceleration policy that you want to edit.
The Policy Editor screen opens.
4.
From the Matching Rules list on the Policy Editor menu bar, select Acceleration Rules.
The acceleration rules display on the Policy Editor menu bar.
5.
On the Policy Editor menu bar, click Assembly.
The Assembly Rules screen opens.
6.
From the Content Assembly Options list box, select Advanced.
The screen refreshes, displaying the Advanced Assembly box.
7.
In the Advanced Assembly box, type the node string options as described in Table 8.1.
8.
Click the Save button.
This section of the chapter provides information about how to configure an example assembly rule. For this example site, you have three top-level nodes in the Policy Tree as follows:
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.
For this example, the applications are all requested with a query parameter named sessionID. This means that you must use the requestss value sessionID for the sessionID query parameter in the URLs that are embedded in your sites web pages.
Enable the compress content feature for pages that benefit from compression. That is, for requests that matches to your Home node and any node under your Applications node. Do not enable compression for the Images node, because graphics do not benefit from compression.
Configure a parameter value substitution rule based on the sessionID query parameter for the Home and Applications nodes.
Note: By default, the compressToClient value for image object types is set to none in the globalfragments.xml file, so content compression is disabled for those objects. Since content compression is disabled by default for images, you do not have to explicitly set the compress content feature for the Images node.
1.
On the Main tab of the navigation pane, expand WebAccelerator and click Applications.
The Applications screen opens in a new window.
2.
On the Main tab of the navigation pane in the new window, click Policies.
The Policies screen opens, displaying a table of user-defined and pre-defined acceleration policies.
3.
On the User-defined Acceleration Policies table, click the name of the acceleration policy that you want to edit.
The Policy Editor screen opens.
5.
From the Matching Rules list on the Policy Editor menu bar, select Acceleration Rules.
The acceleration rules display on the Policy Editor menu bar.
6.
On the Policy Editor menu bar, click Assembly.
The Assembly Rules screen opens.
7.
In the Parameter Value Substitution section, click the Create button.
The Parameter Value Substitution screen opens.
8.
In the Source Definition section, from the Type list, select Query Parameter.
The screen refreshes and displays the Name box.
9.
In the Name box, type sessionID.
10.
In the Target Definition section, from the Type list, select Query Parameter.
The screen refreshes and displays the Name box and Target URLs options.
11.
In the Name box, type sessionID.
13.
Click the Save button.
The Assembly Rules screen opens and the parameter value substitution table displays the new source and target parameters that you specified.
14.
Verify that the Enable Content Compression check box is checked.
15.
Click the Save button.
The screen refreshes.
16.

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)