Applies To:

Show Versions Show Versions

Manual Chapter: Policy Management Guide for the BIG-IP WebAccelerator Module: 8 - Configuring Assembly Rules
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


8

Configuring Assembly Rules


Using assembly rules

The WebAccelerator system manages content in the form of compiled responses in its cache. Compiled responses contain applets you can run that the WebAccelerator system uses to assemble pages, in conjunction with the following information.

  • Assembly rules, which identify:
    • How to change parameter values for embedded URLs by substituting values from the request, or by randomly generated values.
    • Various content assembly options, such as compression.
  • Page assembly instructions
    Optional Edge-Side Include (ESI) markup tags to specify HTML fragments to include in the page, as described in Appendix D, Assembling Content with Edge Side Includes .

Since the WebAccelerator system performs content assembly after it matches the response to a node, it uses the matched response node's assembly rules. If the response matches to a different node than the request, the WebAccelerator system considers the assembly rules associated with the request's node as irrelevant. The WebAccelerator system always uses the instructions from the response node's assembly rules, which it caches as part of the original compiled response.

Organizing assembly rules in the Request Type Hierarchy tree

You organize assembly rules in the Request Type Hierarchy tree, with any associated assembly rules assigned to the leaf node. You can use assembly rules to:

  • Specify content assembly options, using:
    • Express Loader
    • Express Connect
    • Compress contents
    • Content assembly on proxies
  • Overwrite system settings for a node, using:
    • Advanced assembly options
  • Define imbedded URL values, using:
    • Parameter value substitution requirements
    • Random value substitution requirements

The parameter value substitutions defined for a leaf node are a combination of the rules defined locally at the node, and the rules inherited from the node's ancestors. For information about inheritance support in the Request Type Hierarchy, see Understanding hierarchy inheritance , located in Chapter 4.

Specifying content assembly options

You can specify how the WebAccelerator system assembles content for your site, using the following features:

  • Express Loader
  • Express Connect
  • Compress contents
  • Content assembly on proxies

Configuring the Express Loader feature

When a browser requests content from a web server, the 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. This conditional GET 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 GETS 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 can perceive a slow response time, especially over dial-up connections.

The WebAccelerator system's Express Loader feature increases the efficiency of the web browser's 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 browser's 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 system's cache.

The WebAccelerator system applies the Express Loader feature only to the following types of tags:

  • 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="image" src="...."></form>

For the WebAccelerator system to apply the Express Loader to these tags, the following conditions must be true:

  • The link does not contain any query parameters.
    Even if there is just a trailing question mark (?) in the link, the WebAccelerator system cannot apply the Express Loader feature.
  • There are no Content 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 Express Loader feature.
  • There are no proxy rules defined for the link.
Important

Do not disable the Express Loader feature, unless instructed to do so by an F5 Networks Technical Support representative.

If you are using the Express Loader feature, you must also enable the perform content assembly on proxies feature, as described in Enabling content assembly on proxies .

Note

When the Express Loader feature is enabled, the WebAccelerator system ignores any browser cache minimum age settings that might apply to express loaded objects. However, the HTML page into which those objects are being loaded honors all browser cache minimum age settings. For more information about browser age settings, see Specifying the stand-in period , located in Chapter 10.

Express Loader example

This section of the chapter provides information about how to configure an example scenario that uses the Express Loader 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>

The WebAccelerator system modifies the page as follows, using the Express Loader feature.

<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 src URL is 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.

As a result, the browser conducts subsequent requests for the page by:

  • Performing a conditional GET for the base page.
  • Obtaining the embedded images directly from its cache, if the pv tag matches.
  • Requesting new images from the WebAccelerator system.

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 for the base page and receives the refreshed page, it compares the image and notes the difference. For example, image1.jpeg;pv4RR87M90 instead of image1.jpeg;pvRG2076ND. This prompts the client to re-request the image from the WebAccelerator system.

To enable the Express Loader feature

  1. On the Main tab of the navigation pane, expand WebAccelerator, and then click Policies.
    The Policies screen opens, displaying a list of acceleration policies.
  2. Click Edit next to the acceleration policy you want to edit.
    The Policy Editor screen opens.
  3. On the acceleration policy menu bar, click Assembly.
    The Assembly rule screen opens.
  4. From the Request Type Hierarchy tree, click the node for which you want to enable the Express Loader feature.
  5. Check the Express Loader check box.
  6. Click the Save button.
    The screen refreshes.
Important

If you enable the Express Loader feature, you must also enable the Perform content assembly on proxies feature, as described in Configuring content compression options .

Configuring the Express Connect feature

Most browsers create a limited number of persistent TCP connections for each domain from which they are requesting data. With the Express Connect feature, the WebAccelerator system modifies embedded URLs with unique subdomains that prompt the browser to open more persistent connections (up to two per subdomain generated by the WebAccelerator system) for each supported protocol (HTTP or HTTPS). The WebAccelerator system uses these additional subdomains only for embedded URLs or links that request images or scripts. This results in a browser opening a total of four connections to the WebAccelerator system when requesting pages over the HTTP protocol for one subdomain. These additional connections result in faster data downloads.

To qualify for Express Connect management, the domain for a URL must have Express Connect options specified in its host map and you must 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 and assign a subdomain prefix of wa., the WebAccelerator system changes the domain on qualifying embedded URLs and links to use the following domains:

  • wa1.www.siterequest.com
  • wa2.www.siterequest.com

Unlike making changes in client browsers, you can manage the Express Connect feature from a single point of control and employ it selectively, based on the Request Host and protocol.

The WebAccelerator system applies the Express Connect feature only to the following types of links.

  • Image tags:
    <img src="...">
  • Script tags:
    <script src="...">
  • Forms whose input type is an image:
    <form><input type="image" src="..."></form>

The Express Connect feature is disabled in the host maps by default. To use this option, you must configure DNS with the additional domains and map those domains to the same IP address as the base origin server (www.siterequest.com in this example). These domains are used only for requests and/or responses between the client and the WebAccelerator system. The origin servers never get a requests that use these additional domains.

Express Connect example

This section of the chapter provides information about how to configure an example scenario that uses the Express Connect 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>

The Request Host map for www.siterequest.com has Express Connect options set to use a subdomain prefix of wa. The maximum number of Express Connect subdomains is set to 2. In this case, 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>

</html>

If the WebAccelerator system needs to send a request to the origin server, it automatically removes the subdomain prefixes before sending the request.

Important

To use the Express Connect feature, you must configure it in the host map. Even if the Enable Express Connect check box is checked in the content assembly options for a caching policy, you must also configure the Express Connect feature in the host map before you can use it. For information about configuring a host map, see Chapter 3, Configuration and Maintenance, in the Administrator Guide for the BIG-IP® WebAcceleratorTM Module.

To configure the Express Connect feature

  1. On the Main tab of the navigation pane, expand WebAccelerator, and then click Applications.
    The Applications screen opens.
  2. Click Edit next to the application for which you want to configure the Express Connect options.
    The Edit Applications screen opens.
  3. In the Hosts area at the bottom of the screen, click Options next to the Requested Host box.
    The screen refreshes and displays the Express Connect Options.
  4. From the HTTP subdomains and HTTPS subdomains lists, select a number of subdomains that you want the WebAccelerator system to generate for each protocol.
  5. In the Subdomain Prefix box, type a prefix, or leave it at the default of wa.
  6. Click the Save button.

For a new or modified acceleration policy to be in effect for your site, you must publish it. See Publishing acceleration policies , located in Chapter 3, for more information.

Configuring content compression options

Compression can improve the perceived performance of your site, especially over dial-up connections. Compressed content can also reduce your site's bandwidth costs by reducing the size of the data that it serves. You can use assembly rules to identify content that you want the WebAccelerator system to compress using gzip-encoding.

The WebAccelerator system uses the following criteria to determine if it can compress a response:

  • The compressToClient value (set in the global configuration fragment globalfragment.xml file) for the object type that the response was classified under
  • The Compress Contents setting on the node for the assembly rule, to which the request and response is matched
  • The ability of the client to accept gzip-encoded content

If set to anything other than policyControlled, the compressToClient value overrides the Compress Contents 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 Compress Contents setting for the assembly rule to determine whether to compress the response.

In addition, the client must indicate if 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 compression 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 Chapter 5, Changing Configuration Options, in the Administrator Guide for the BIG-IP® WebAcceleratorTM Module.

To enable the compress content feature

  1. On the Main tab of the navigation pane, expand WebAccelerator, and then click Policies.
    The Policies screen opens, displaying a list of acceleration policies.
  2. Click Edit next to the policy you want to edit.
    The Policy Editor screen opens.
  3. On the acceleration policy menu bar, click Assembly.
    The Assembly rules screen opens.
  4. From the Request Type Hierarchy tree, click the node for which you want to enable the compress content feature.
  5. Check the Compress content check box.
  6. 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. See Publishing acceleration policies , located in Chapter 3, for more information.

Important

If you enable the compress content feature, you must also enable the perform content assembly on proxies feature, as described in the following section.

Enabling content assembly on proxies

When the feature, perform content assembly on proxies, is enabled, the WebAccelerator system applies assembly rules to a response after forwarding a request to the origin servers, 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 Express Loader feature, even if the content is not served from the WebAccelerator system's cache. Therefore, you must enable the feature, perform content assembly on proxies, whenever you are using the compress content or Express Loader features.

When the feature, perform content assembly on proxies, is not enabled, the WebAccelerator system does not modify responses that it receives from the origin 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 servers indicates that the response contains ESI assembly instructions. For more information about ESI-encoded responses, see Using Edge Side Include (ESI)

To enable the perform content assembly on proxies feature

  1. On the Main tab of the navigation pane, expand WebAccelerator, and then click Policies.
    The Policies screen opens, displaying a list of acceleration policies.
  2. Click Edit next to the policy you want to edit.
    The Policy Editor screen opens.
  3. On the acceleration policy menu bar, click Assembly.
    The Assembly rules screen opens.
  4. From the Request Type Hierarchy tree, click the node for which you want to enable the perform content assembly on proxies feature.
  5. Check the box for Perform content assembly on proxies.
  6. Click the Save button.
    The screen refreshes.

yepper For a new or modified acceleration policy to be in effect for your site, you must publish it. See Publishing acceleration policies , located in Chapter 3, for more information.

Specifying advanced assembly options

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 only need to set these features to false if you are overriding an inherited true setting from a parent node.

The advanced assembly option strings that you can specify are.

Table 8.5 Node string options
Valid Strings
Description
authAdapter=module
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.
The default is that no module is specified.
followRedirects=true
followRedirects=false
When set to true, the WebAccelerator system internally follows redirects unless certain conditions, such as protocol or domain changes, are met.
The system-wide default is false.
forceLastMod=true
forceLastMod=false
When set to true, the WebAccelerator system attempts to generate a Last-Modified header for the response.
The system-wide default is false.
disableContentBasedIdentity=true
disableContentBasedIdentity=false
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 Administration Guide for the BIG-IP® WebAccelerator Module.

 

To configure advanced assembly options

  1. On the Main tab of the navigation pane, expand WebAccelerator, and then click Policies.
    The Policies screen opens, displaying a list of acceleration policies.
  2. Click Edit next to the policy you want to edit.
    The Policy Editor screen opens.
  3. From the Request Type Hierarchy tree, click the node for which you want to configure advanced assembly option
  4. On the acceleration policy menu bar, click Assembly.
    The Assembly rules screen opens.
  5. In the Advanced Assembly box, type the node string options as described in Table 8.5 .
  6. Click the Save button.

For a new or modified acceleration policy to be in effect for your site, you must publish it. See Publishing acceleration policies , located in Chapter 3, for more information.

Using parameter value substitution

When you configure parameter value substitution for assembly, the WebAccelerator system changes the targeted parameter's value on a specific page it serves from its cache, so that the parameter you specified appears on the URL embedded in the page. You can use this option when a query parameter contains identification information for the site's visitors.

For example, some pages served include hyperlinks that require that specific information appears on the pages. By using 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 page's URL, when it serves the page.

Without parameter value substitution, the WebAccelerator system uses the value that it cached for the original request for all subsequent requests, even when the subsequent requests use different values that should be used in response.

For example, if the original request that generated the cached page contained the following URL:

http://www.somesite.com/apps/shopping.jsp?shopper=AAnb35vnM09&....

The embedded URL in the cached page might be:

<a href="http://www.somesite.com/apps/shoppingCart.jsp?
shopper=AAnb35vnM09&.... ">link</a>

If the WebAccelerator system receives a subsequent request for the following page:

http://www.somesite.com/apps/shopping.jsp?shopper=SNkj90qcL47&....

The WebAccelerator system still serves the cached page, which contains the following URL:

<a href="http://www.somesite.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.somesite.com/apps/shoppingCart.jsp?
shopper=SNkj90qcL47&.... ">link</a>

Note

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 above example, if a subsequent request was simply: http://www.somesite.com/apps/shopping.jsp then embedded URLs served to the requestor are:
<a href="http://www.somesite.com/apps/shoppingCart.jsp?">link</a>

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.

Configuring value substitution parameters

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.

Source definition

A source definition contains the value that the WebAccelerator system embeds in the URL, in place of the cached value. Typically, the source is a specific request element, such as a particular query parameter, and the WebAccelerator system uses 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.

The HTTP request data type parameters that you can use as the source of a substitution are:

  • Query parameter
  • Unnamed query parameter
  • Path segment

Or, you can one of the following:

  • Number randomizer
  • Request URL

If you use the request URL as the source, the WebAccelerator system uses the entire request URL as the value to substitute.

For example, if the request URL is:

http://www.somesite.com/apps/something.jsp?entity=orange

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.somesite.com/anotherthing.jsp?
url=http%3A%2F%2Fwww.somesite.com%2Fapps%2Fsomething.jsp ?
entity=orange&....">

Target definition

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.

The HTTP request data type parameters that you can use as the target of a substitution are:

  • Query parameter
  • Unnamed query parameter
  • Path segment

Target URLs

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:

http://www.asite.com/valueList.jsp

The WebAccelerator system performs substitution on the following embedded URL:

http://www.asite.com/valueList.jsp?entity=Larry

However, the WebAccelerator system does not perform substitution on the following embedded URL:

http://www.asite.com/apps/lookup.jsp?entity=Moe

Random value substitution

Random value substitution is similar to parameter value substitution parameters. Random value substitution 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:

<iframe src="http://www.aaaa-Ads.com/getAd?entity=45&..."></iframe>

When random value substitution is specified as such, the WebAccelerator system sets random values set for the entity query parameter for subsequent pages as follows:

<iframe src="http://www.aaaa-Ads.com/getAd?entity=45&..."></iframe>

<iframe src="http://www.aaaa-Ads.com/getAd?entity=11&..."></iframe>

<iframe src="http://www.aaaa-Ads.com/getAd?entity=87&..."></iframe>

Important

The WebAccelerator system ignores parameter value substitution (including random value substitution) if it conflicts with ESI markup. See Serving ESI content from cache for more information.

Configuring an assembly rule example

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 Request Type Hierarchy as follows.

  • Home
    Specifies the rules related to the home page.
  • Applications
    Specifies the rules related to the applications for the site, with child nodes, such as:
    • Default
      Specifies the rules related to non-search related applications.
    • Search
      Specifies the rules related to your site's search application.
  • Images
    Specifies the rules related to graphics images.
Note

For specific instructions about how to create the Request Type Hierarchy tree see, To create the Home, Application, and Images nodes for the example Request Type Hierarchy tree , located in Chapter 4.

For this example, the applications are all requested with a query parameter named sessionID. This means that you must use the requests's value sessionID for the sessionID query parameter in the URLs that are embedded in your site's web pages.

For this example, you should:

  • Enable compression 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.
  • Create a parameter value substitution policy 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, so compression is disabled for those objects. Since compression is disabled by default for images, you do not have to explicitly set assembly rules for the Images node.

To enable compression and configure parameter value substitution parameters

  1. On the Main tab of the navigation pane, expand WebAccelerator, and then click Policies.
    The Policies screen opens, displaying a list of acceleration policies.
  2. Click Edit next to the policy you want to edit.
    The Policy Editor screen opens.
  3. On the acceleration policy menu bar, click Assembly.
    The Assembly rules screen opens.
  4. From the Request Type Hierarchy tree, click the Home node.
  5. In the Parameter Value Substitution section, click the Add button.
    The Parameter Value Substitution screen opens.
  6. From the Source Definition Type list, select Query Parameter.
    The screen refreshes and displays the Name box.
  7. In the Source Definition Name box, type sessionID.
  8. From the Target Definition Type list, select Query Parameter.
    The screen refreshes and displays the Name box and Target URL options.
  9. In the Target Definition Name box, type sessionID.
  10. 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.
  11. Verify that the Compress contents check box is checked.
  12. Click the Save button.
    The screen refreshes.
  13. From the Request Type Hierarchy, click the Applications node.
  14. Repeat steps 5 - 12.

For a new or modified acceleration policy to be in effect for your site, you must publish it. See Publishing acceleration policies , located in Chapter 3, 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)