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.
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 on the Policy Tree, see Understanding rule inheritance.
When a client requests content from an origin 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 is different than the content that the browser has cached, the origin web server sends a fresh copy of the object to the browser. Otherwise, the browser uses the object that is cached locally.
Although faster than serving the entire object each time the browser requests it, conditional GET requests can add up to a significant amount of traffic for your site. When a large number of conditional GET requests occur for sites serving (for example) several images for each page, clients may perceive a slow response time.
To increase the efficiency of the clients web browsers local cache and improve perceived performance, you can use the WebAccelerator systems Intelligent Browser Referencing feature to reduce or eliminate requests to your site for relatively static content, such as images and style sheet (CSS) files. When you set the Enable Intelligent Browser Referencing feature, the WebAccelerator system manages the web browsers cache by:
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, 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.
When you set the Enable Intelligent Browser Referencing feature for an acceleration policy, 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.
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.
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 the existing 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.
4.
On the Policy Tree, click the node for which you want to set the Enable Intelligent Browser Referencing feature.
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 box.
8.
Click the Save button.
The screen refreshes.
Important: If you set the Enable the Intelligent Browser Referencing feature, you must also set the Enable Content Assembly on Proxies feature, as described in Enabling the Content Compression feature.
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 the MultiConnect feature is enabled, it prompts the clients web browser to open additional 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.
If you do not perform these required tasks, the WebAccelerator system does not apply the MultiConnect feature, even if you set the Enable MultiConnect feature for a specific acceleration policy. For information about these required tasks, see the Configuration and Maintenance Tasks chapter in the Configuration Guide for the BIG-IP® WebAcceleratorTM System.
Once you complete the required tasks and set the Enable MultiConnect feature for an acceleration policy, the WebAccelerator system changes the domain on qualifying embedded URLs and links to use the domains you specified. For example:
Important: Some client browsers close HTTPS connections to one domain before opening HTTPS connections to a new domain. This type of browser behavior can decrease the speed of access to applications for which the MultiConnect feature is enabled; therefore, F5 Networks recommends that you do not enable the MultiConnect feature for HTTPS connections.
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 setting the Enable MultiConnect feature for an acceleration policy, you must configure the prefixes for the additional subdomains in your host map. The WebAccelerator system will not apply this feature unless you have assigned the additional subdomain prefixes to the host map. For information about configuring a host map, see the Configuration and Maintenance Tasks chapter in the Configuration Guide for the BIG-IP® WebAcceleratorTM System.

If you are using MultiConnect with HTTPS, you must also construct a trusted SSL certificate that lists the additional subdomains that you created as Subject Alternative Name entries. If you are using MultiConnect for use with only HTTP, this step is not necessary. For more specific information about specifying Subject Alternative Name entries, contact your certificate authority.
1.
In the navigation pane, expand WebAccelerator and click Policies.
The Policies screen opens, displaying the existing 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 box.
7.
Click the Save button.
The screen refreshes.
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 from any screen within the Policy Editor to open the publish screen. We recommend that if you are making a series of changes to an acceleration policy, click the Publish button on the Policy Editor screen only after you make the last change in the series. Alternatively, you can publish an acceleration policy from the Policies screen. See Publishing acceleration policies, for more information.
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 the assembly rules Enable Content Compression feature to identify content that you want the WebAccelerator system to compress using gzip-encoding.
The Enable Compression setting for the responses object type
Note: You can view and modify individual Enable Compression settings for individual object types from the Object Types screen.
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 you select anything other than Policy Controlled for the object types Enable Compression setting (configured from the Object Types screen), it will override the assembly rules Enable Content Compression setting. In other words, regardless of any configured assembly rule settings, if you select none for the Enable Compression setting when you configure an object type, the WebAccelerator system never compresses the response, and if you select Symmetric Deployment Only, the WebAccelerator system compresses the response only if the client is another WebAccelerator system. However, if you select Policy Controlled for the object types Enable Compression setting, the WebAccelerator system uses the assembly rules content compression setting to determine whether to compress the response.
In addition to this setting, 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 not compress the content.
Note: By default, the Enable Compression setting is set to None in the Object Types screen for image object types (such as gif and jpeg), Microsoft® PowerPoint® object types (such as ppt and pps), and Adobe ®PDF object types (pdf), because they do not benefit from compression. This setting will override the Enable Content Compression feature you set in the assembly rule. For information about modifying object type settings, see the Changing Default Settings chapter in the Configuration Guide for the BIG-IP® WebAcceleratorTM System.
1.
In the navigation pane, expand WebAccelerator and click Policies.
The Policies screen opens, displaying the existing 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 box.
Note: If the WebAccelerator system matches a request to an object type for which the Enable Compression option is set to Symmetric Deployment only or None, it will override this Enable Content Compression setting. You can view individual object type settings from the Object Types screen.
7.
Click the Save button.
The screen refreshes.
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 from any screen within the Policy Editor to open the publish screen. We recommend that when you make a series of changes to an acceleration policy, you click the Publish button on the Policy Editor screen only after you make the last change in the series. Alternatively, you can publish an acceleration policy from the Policies screen. See Publishing acceleration policies, for more information.
Important: If you set the Enable Content Compression feature, you must also set the Enable Content Assembly on Proxies feature, as described in the following section.
When the Enable Content Assembly on Proxies feature is set, 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.
The 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 the Enable Content Assembly on Proxies feature is not set, 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 the existing 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.
3.
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 Assembly on Proxies box.
7.
Click the Save button.
The screen refreshes.
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 from any screen within the Policy Editor to open the publish screen. We recommend that when you make a series of changes to an acceleration policy, you click the Publish button on the Policy Editor screen only after you make the last change in the series. Alternatively, you can publish an acceleration policy from the Policies screen. See Publishing acceleration policies, for more information.
Some requested pages include hyperlinks that require that specific information appear in the response. If parameter value substitution is not configured, the WebAccelerator system uses the value that it cached for the original request, for all subsequent requests after the first, even if the subsequent requests have different values that should be used in the response.
<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>
In contrast, if you configure parameter value substitution for an assembly rule, the WebAccelerator system changes the targeted parameters value on the page it serves from its cache, so that the parameter you specify appears on the URL embedded in that page. You can use this option when a query parameter contains identification information for the sites visitors, to prompt the WebAccelerator system to serve different content for each request, based on the specific visitor.
When you use parameter value substitution in assembly rules, you identify the value as a source definition in an HTTP request and specify that when the WebAccelerator system serves the page, it embeds the named value into the appropriate location in the pages URL.
Therefore, in the previous example URL, 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>
When you configure parameter value substitution, you specify a source definition and a target definition. 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 Number randomizer.
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 the sources 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:
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 configured, the assembly rules number randomizer 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.
The WebAccelerator system provides you with the flexibility to override, at the node level, specific system-wide assembly settings. You can use this option to fine-tune how the WebAccelerator system manages certain types of traffic, without changing the system-wide settings for all of your traffic.
To use this feature, you specify advanced assembly option strings in the assembly rule of an acceleration policy. Once configured, the WebAccelerator system uses this setting to manage all requests and responses that match to the 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.
Specify for <module>, the name of an authentication adapter module you want the WebAccelerator system to load and run for requests and 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 that matches to the node.
When set to true, the content-based identity feature is disabled.
The system-wide default is false, which means that if content-based identity is used, it is enabled for the node.
For more information about content-based identity, see the Configuration Guide for the BIG-IP® WebAccelerator System.
1.
In the navigation pane, expand WebAccelerator, and then click Policies.
The Policies screen opens, displaying the existing 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.
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 from any screen within the Policy Editor to open the publish screen. We recommend that when you make a series of changes to an acceleration policy, you click the Publish button on the Policy Editor screen only after you make the last change in the series. Alternatively, you can publish an acceleration policy from the Policies screen. See Publishing acceleration policies, for more information.
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 on 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 Content Compression setting is disabled for image object types, such as gif and jpeg, because they do not benefit from compression. Since content compression is disabled by default for images, you do not have to explicitly set the compress content feature for the Images node in this example. For information about modifying object type settings, see the Changing Default Settings chapter in the Configuration Guide for the BIG-IP® WebAcceleratorTM System.
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 the existing 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.
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 from any screen within the Policy Editor to open the publish screen. We recommend that when you make a series of changes to an acceleration policy, you click the Publish button on the Policy Editor screen only after you make the last change in the series. Alternatively, you can publish an acceleration policy from the Policies screen. See Publishing acceleration policies, for more information.
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)