You are on page 1of 186

Policy Management Guide for the BIG-IP WebAccelerator System

version 10.2
MAN-0252-03

Product Version
This manual applies to product version 10.2 of the BIG-IP WebAccelerator.

Publication Date
This manual was published on August 17, 2011.

Legal Notices
Copyright
Copyright 2008-2011, F5 Networks, Inc. All rights reserved. F5 Networks, Inc. (F5) believes the information it furnishes to be accurate and reliable. However, F5 assumes no responsibility for the use of this information, nor any infringement of patents or other rights of third parties which may result from its use. No license is granted by implication or otherwise under any patent, copyright, or other intellectual property right of F5 except as specifically described by applicable user licenses. F5 reserves the right to change specifications at any time without notice.

Trademarks
F5, F5 Networks, the F5 logo, BIG-IP, 3-DNS, Access Policy Manager, APM, Acopia, Acopia Networks, Application Accelerator, Ask F5, Application Security Manager, ASM, ARX, Data Guard, Edge Client, Edge Gateway, Enterprise Manager, EM, FirePass, FreedomFabric, Global Traffic Manager, GTM, iControl, Intelligent Browser Referencing, Internet Control Architecture, IP Application Switch, iRules, Link Controller, LC, Local Traffic Manager, LTM, Message Security Module, MSM, NetCelera, OneConnect, Packet Velocity, Protocol Security Module, PSM, Secure Access Manager, SAM, SSL Accelerator, SYN Check, Traffic Management Operating System, TMOS, TrafficShield, Transparent Data Reduction, uRoam, VIPRION, WANJet, WAN Optimization Module, WOM, WebAccelerator, WA, and ZoneRunner are trademarks or service marks of F5 Networks, Inc., in the U.S. and other countries, and may not be used without F5's express written consent. All other product and company names herein may be trademarks of their respective owners.

Patents
This product protected by U.S. Patent[s] 6,505,230; 6,640,240; 6,772,203; 6,970, 933; 7,113,962; and 7,114,180. Other patents pending.

Export Regulation Notice


This product may include cryptographic software. Under the Export Administration Act, the United States government may consider it a criminal offense to export this product from the United States.

RF Interference Warning
This is a Class A product. In a domestic environment this product may cause radio interference, in which case the user may be required to take adequate measures.

FCC Compliance
This equipment has been tested and found to comply with the limits for a Class A digital device pursuant to Part 15 of FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This unit generates, uses, and can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case the user, at his own expense, will be required to take whatever measures may be required to correct the interference. Any modifications to this device, unless expressly approved by the manufacturer, can void the user's authority to operate this equipment under part 15 of the FCC rules.

Policy Management Guide for the BIG-IP WebAcceleratorTM System

Canadian Regulatory Compliance


This Class A digital apparatus complies with Canadian ICES-003.

Standards Compliance
This product conforms to the IEC, European Union, ANSI/UL and Canadian CSA standards applicable to Information Technology products at the time of manufacture.

Acknowledgments
This product includes software developed by the University of California, Berkeley and its contributors. This product includes software developed by the Computer Systems Engineering Group at the Lawrence Berkeley Laboratory. This product includes software developed by the NetBSD Foundation, Inc. and its contributors. This product includes software developed by Christopher G. Demetriou for the NetBSD Project. This product includes software developed by Adam Glass. This product includes software developed by Christian E. Hopps. This product includes software developed by Dean Huxley. This product includes software developed by John Kohl. This product includes software developed by Paul Kranenburg. This product includes software developed by Terrence R. Lambert. This product includes software developed by Philip A. Nelson. This product includes software developed by Herb Peyerl. This product includes software developed by Jochen Pohl for the NetBSD Project. This product includes software developed by Chris Provenzano. This product includes software developed by Theo de Raadt. This product includes software developed by David Muir Sharnoff. This product includes software developed by SigmaSoft, Th. Lockert. This product includes software developed for the NetBSD Project by Jason R. Thorpe. This product includes software developed by Jason R. Thorpe for And Communications, http://www.and.com. This product includes software developed for the NetBSD Project by Frank Van der Linden. This product includes software developed for the NetBSD Project by John M. Vinopal. This product includes software developed by Christos Zoulas. This product includes software developed by Charles Hannum. This product includes software written by Steffen Beyer and licensed under the Perl Artistic License and the GPL This product includes software written by Makamaka Hannyaharamitu (C) 2007-2008. This product includes software developed by Charles Hannum, by the University of Vermont and State Agricultural College and Garrett A. Wollman, by William F. Jolitz, and by the University of California, Berkeley, Lawrence Berkeley Laboratory, and its contributors. This product includes software developed by the University of Vermont and State Agricultural College and Garrett A. Wollman. In the following statement, "This software" refers to the Mitsumi CD-ROM driver: This software was developed by Holger Veit and Brian Moore for use with "386BSD" and similar operating systems. "Similar operating systems" includes mainly non-profit oriented systems for research and education, including but not restricted to "NetBSD," "FreeBSD," "Mach" (by CMU). In the following statement, "This software" refers to the parallel port driver: This software is a component of "386BSD" developed by William F. Jolitz, TeleMuse. This product includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/). This product includes software developed by Darren Reed. ( 1993-1998 by Darren Reed). This product includes software licensed from Richard H. Porter under the GNU Library General Public License ( 1998, Red Hat Software), www.gnu.org/copyleft/lgpl.html.

ii

This product includes the standard version of Perl software licensed under the Perl Artistic License ( 1997, 1998 Tom Christiansen and Nathan Torkington). All rights reserved. You may find the most current standard version of Perl at http://www.perl.com. This product includes software developed by the University of California, Berkeley and its contributors. This product includes software developed by the Computer Systems Engineering Group at the Lawrence Berkeley Laboratory. This product includes software developed by the NetBSD Foundation, Inc. and its contributors. This product includes software developed by Christopher G. Demetriou for the NetBSD Project. This product includes software developed by Adam Glass. This product includes software developed by Christian E. Hopps. This product includes software developed by Dean Huxley. This product includes software developed by John Kohl. This product includes software developed by Paul Kranenburg. This product includes software developed by Terrence R. Lambert. This product includes software developed by Philip A. Nelson. This product includes software developed by Herb Peyerl. This product includes software developed by Jochen Pohl for the NetBSD Project. This product includes software developed by Chris Provenzano. This product includes software developed by Theo de Raadt. This product includes software developed by David Muir Sharnoff. This product includes software developed by SigmaSoft, Th. Lockert. This product includes software developed for the NetBSD Project by Jason R. Thorpe. This product includes software developed by Jason R. Thorpe for And Communications, http://www.and.com. This product includes software developed for the NetBSD Project by Frank Van der Linden. This product includes software developed for the NetBSD Project by John M. Vinopal. This product includes software developed by Christos Zoulas. This product includes software developed by Charles Hannum. This product includes software developed by Charles Hannum, by the University of Vermont and Stage Agricultural College and Garrett A. Wollman, by William F. Jolitz, and by the University of California, Berkeley, Lawrence Berkeley Laboratory, and its contributors. This product includes software developed by the University of Vermont and State Agricultural College and Garrett A. Wollman. In the following statement, "This software" refers to the Mitsumi CD-ROM driver: This software was developed by Holger Veit and Brian Moore for use with "386BSD" and similar operating systems. "Similar operating systems" includes mainly non-profit oriented systems for research and education, including but not restricted to "NetBSD," "FreeBSD," "Mach" (by CMU). In the following statement, "This software" refers to the parallel port driver: This software is a component of "386BSD" developed by William F. Jolitz, TeleMuse. This product includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/). This product includes software developed by Darren Reed. ( 1993-1998 by Darren Reed). This product includes software licensed from Richard H. Porter under the GNU Library General Public License ( 1998, Red Hat Software), www.gnu.org/copyleft/lgpl.html. This product includes the standard version of Perl software licensed under the Perl Artistic License ( 1997, 1998 Tom Christiansen and Nathan Torkington). All rights reserved. You may find the most current standard version of Perl at http://www.perl.com. This product includes software developed by Eric Young. Portions of the material included in Appendix C came from the Internet Software Consortium, http://www.isc.org/. Rsync was written by Andrew Tridgell and Paul Mackerras, and is available under the Gnu Public License. This product includes Malloc library software developed by Mark Moraes. ( 1988, 1989, 1993, University of Toronto).

Policy Management Guide for the BIG-IP WebAcceleratorTM System

iii

This product includes open SSL software developed by Eric Young (eay@cryptsoft.com), ( 1995-1998). This product includes open SSH software developed by Tatu Ylonen <ylo@cs.hut.fi>, Espoo, Finland ( 1995). This product includes open SSH software developed by Niels Provos ( 1999). This product includes SSH software developed by Mindbright Technology AB, Stockholm, Sweden, www.mindbright.se, info@mindbright.se ( 1998-1999). This product includes free SSL software developed by Object Oriented Concepts, Inc., St. John's, NF, Canada, ( 2000). This product includes software developed by Object Oriented Concepts, Inc., Billerica, MA, USA ( 2000). This product includes software developed by The Legion of the Bouncy Castle. Copyright (c) 2000 - 2009 The Legion Of The Bouncy Castle (http://www.bouncycastle.org)

iv

Table of Contents

Table of Contents

1
Getting Started with the WebAccelerator System
About the WebAccelerator system .......................................................................................... 1-1 About this guide .................................................................................................................... 1-1 Reviewing the documentation set .............................................................................................. 1-2 Finding help and technical support resources ......................................................................... 1-3

2
Using Acceleration Policies
Overview of acceleration policies .............................................................................................. 2-1 Types of acceleration policies ............................................................................................ 2-1 Managing your acceleration policies .......................................................................................... 2-3 Customizing acceleration policies .............................................................................................. 2-6 Creating a user-defined acceleration policy .................................................................... 2-6 Creating a signed acceleration policy ............................................................................... 2-8 Publishing acceleration policies ................................................................................................. 2-10 Saving an acceleration policy to an XML file .......................................................................... 2-11

3
Using the Policy Editor
Overview of the Policy Editor screen ....................................................................................... 3-1 Using the Policy Tree .................................................................................................................... 3-4 Policy Tree example ............................................................................................................ 3-4 Understanding acceleration policy rule inheritance ............................................................... 3-6 Inheriting rule parameters .................................................................................................. 3-7 Overriding inherited rule parameters .............................................................................. 3-8 Modifying a Policy Tree for an acceleration policy .............................................................. 3-11

4
Using HTTP Headers to Configure Acceleration Policy Rules
Using HTTP header parameters to process requests ........................................................... 4-1 Requirements for servicing requests ................................................................................ 4-1 Requirements for caching responses ................................................................................ 4-2 Configuring rules based on HTTP request headers ............................................................... 4-4 Specifying HTTP data type parameters for a rule ......................................................... 4-5 Configuring rules based on HTTP response headers .......................................................... 4-12 Classifying responses .......................................................................................................... 4-12 Applying associated acceleration policy rules .............................................................. 4-13 Assembling responses ........................................................................................................ 4-14 Using regular expressions and meta tags for rules .............................................................. 4-15 Supported regular expression strings ............................................................................ 4-15 Supported meta characters .............................................................................................. 4-17 Managing Cache-Control response headers .......................................................................... 4-19 Honoring HTTP request and response header no-cache directives ...................... 4-19 Using max-age value for compiled responses .............................................................. 4-21 Using ESI Surrogate-Control headers ..................................................................................... 4-22 Supported Surrogate-Control directives ....................................................................... 4-22 Overriding HTTP Cache-Control headers ................................................................... 4-24 Using surrogate targeting .................................................................................................. 4-24 Viewing X-PvInfo response headers ........................................................................................ 4-25 S code .................................................................................................................................... 4-26 C code ................................................................................................................................... 4-27 A code ................................................................................................................................... 4-28 Policy Management Guide for the BIG-IP WebAccelerator System vii

Table of Contents

R code .................................................................................................................................... 4-28 G code ................................................................................................................................... 4-28 U code ................................................................................................................................... 4-29

5
Configuring Matching Rules
Overview of application matching .............................................................................................. 5-1 Application matching based on node precedence ......................................................... 5-2 Additional application matching considerations ............................................................. 5-2 Processing unmatched requests ........................................................................................ 5-3 Configuring an example matching rule ...................................................................................... 5-4

6
Configuring Variation Rules
Overview of variation rules ......................................................................................................... 6-1 Using variation rules to increase cache efficiency ......................................................... 6-2 Using variation rules to serve user-specific content ..................................................... 6-2 Defining variation rule parameters ............................................................................................ 6-4 Using value groups ................................................................................................................ 6-4 Managing conflicting rule parameters ........................................................................................ 6-5 Configuring an example variation rule ...................................................................................... 6-7

7
Configuring Assembly Rules
Overview of assembly rules ......................................................................................................... 7-1 Using the Intelligent Browser Referencing feature ................................................................ 7-2 Enabling the Intelligent Browser Referencing feature .................................................. 7-3 Intelligent Browser Referencing example ........................................................................ 7-4 Using the MultiConnect feature ................................................................................................. 7-5 Enabling the MultiConnect feature ................................................................................... 7-5 Using content compression ......................................................................................................... 7-8 Enabling content compression ........................................................................................... 7-8 Managing content served from origin web servers .............................................................. 7-10 Enabling content assembly on proxies feature ............................................................. 7-10 Using parameter value substitution ......................................................................................... 7-11 Configuring value substitution parameters for an assembly rule ............................. 7-12 Specifying advanced assembly options ..................................................................................... 7-15 Configuring an example assembly rule .................................................................................... 7-17

8
Configuring Proxying Rules
Overview of proxying rules ......................................................................................................... 8-1 Configuring example proxy rule parameters ........................................................................... 8-3 Enabling the Always proxy requests for this node setting ................................................... 8-4 Configuring an example proxy override rule .......................................................................... 8-5 Configuring an example proxying rule ...................................................................................... 8-6

9
Configuring Lifetime Rules
Overview of lifetime rules ........................................................................................................... 9-1 Understanding lifetime mechanism precedence ............................................................ 9-1

viii

Table of Contents

Defining Header Lifetime Option settings ............................................................................... 9-3 Obey ESI max-age headers if present ............................................................................... 9-3 Use HTTP lifetime headers if present .............................................................................. 9-3 Configuring the WebAccelerator Cache Settings .................................................................. 9-5 Maximum Age ........................................................................................................................ 9-5 Stand-in Period ...................................................................................................................... 9-5 HTTP Lifetime Heuristic ..................................................................................................... 9-6 Configuring the Client Cache Settings ...................................................................................... 9-7 Do not change ....................................................................................................................... 9-7 Maximum Age ........................................................................................................................ 9-7 Insert no-cache header ........................................................................................................ 9-8 Configuring an example lifetime rule ......................................................................................... 9-9

10
Configuring Invalidations Rules
Overview of invalidations rules ................................................................................................ 10-1 Triggering invalidation ........................................................................................................ 10-2 Setting the lifetime for invalidations rules ..................................................................... 10-3 Defining invalidations rule parameters .................................................................................... 10-4 Request Header Matching Criteria ................................................................................. 10-4 Cached Content to Invalidate .......................................................................................... 10-5 Configuring an example invalidations rule .............................................................................. 10-6

11
Configuring Responses Cached Rules
Overview of responses cached rules ...................................................................................... 11-1 Caching HTML content ..................................................................................................... 11-2 Caching content based on response status codes ...................................................... 11-2 Configuring an example responses cached rule .................................................................... 11-3

12
Specifying Log Formats for Hit Logs
Using hit logs ................................................................................................................................. 12-1 Selecting a standard log format for hit logs ........................................................................... 12-2 Standard log format examples ......................................................................................... 12-3 Creating a custom log format for hit logs .............................................................................. 12-5 Configuring an example customized hit log format ............................................................. 12-7

Glossary Index

Policy Management Guide for the BIG-IP WebAccelerator System

ix

Table of Contents

1
Getting Started with the WebAccelerator System

About the WebAccelerator system Reviewing the documentation set Finding help and technical support resources

Getting Started with the WebAccelerator System

About the WebAccelerator system


The BIG-IP WebAccelerator system is a delivery solution designed to improve the speed at which users access your web applications (such as Microsoft SharePoint, Microsoft Outlook Web Access, BEA AquaLogic, SAP Portal, Oracle Siebel CRM, Oracle Portal, and others) and wide area network (WAN). The WebAccelerator system does this through acceleration policy features that modify web browser behavior, as well as compresses and caches dynamic and static content, which decreases bandwidth usage and ensures that your users get the most quick and efficient access to your web applications and WAN. These processes, and deployment options, are discussed in the following sections. The BIG-IP WebAccelerator system is one of several products that constitute the BIG-IP product family. All BIG-IP products run on the Traffic Management Operating System, commonly referred to as TMOS. For an overview of the complete BIG-IP product offering, see the Introduction to the BIG-IP System chapter of the TMOS Management Guide for BIG-IP Systems.

About this guide


This guide provides the detailed information that you need to manage and customize your acceleration policies. Read this guide only after you have configured the WebAccelerator system using the information provided in the Configuration Guide for the BIG-IP WebAccelerator System.

Policy Management Guide for the BIG-IP WebAccelerator System

1-1

Chapter 1

Reviewing the documentation set


The WebAccelerator system documentation set consists of the following items:

Configuration Guide for the BIG-IP WebAccelerator System Describes the core product concepts and provides the procedures for configuring and monitoring the WebAccelerator system. Policy Management Guide for the BIG-IP WebAccelerator System Provides information about creating and editing policies to tailor the WebAccelerator system for optimal performance. Release notes Provide information about new features, fixes, known issues, and workarounds. Online help Provides context-sensitive description of each control and setting on each screen.

Additionally, you must review specific chapters in the following guides:

BIG-IP Systems: Getting Started Guide For information about performing the required configuration for the BIG-IP Local Traffic Manager, as well as information about installing, enabling, and configuring resource provisioning for the WebAccelerator system license. Configuration Guide for BIG-IP Local Traffic Manager For information about how to define a virtual server and pool. TMOS Management Guide for BIG-IP Systems For an overview of the complete BIG-IP product offering.

1-2

Getting Started with the WebAccelerator System

Finding help and technical support resources


You can find technical documentation and product information using the following resources:

Welcome screen in the Configuration utility The Welcome screen in the Configuration utility contains links to many useful web sites and resources, including: The F5 Networks Technical Support web site The F5 Solution Center The F5 DevCentralSM web site Plug-ins, SNMP MIBs, and SSH clients Online help The WebAccelerator system provides context-sensitive online help for each screen. The online help contains descriptions of each control and setting on the screen. To access the online help, click the Help tab on the left navigation pane of the Configuration utility. F5 Networks Technical Support web site The F5 Networks Technical Support web site provides the latest documentation set for the product, including: Release notes, current and past Software and hardware guides, current and past (in PDF and HTML format) Technical notes The Ask F5SM Knowledge Base To access the F5 Networks Technical Support web site, you need to register at https://support.f5.com.

Policy Management Guide for the BIG-IP WebAccelerator System

1-3

Chapter 1

1-4

2
Using Acceleration Policies

Overview of acceleration policies Managing your acceleration policies Customizing acceleration policies Publishing acceleration policies Saving an acceleration policy to an XML file

Using Acceleration Policies

Overview of acceleration policies


An acceleration policy is a collection of defined rule parameters that dictate how the BIG-IP WebAccelerator system handles HTTP requests and responses. The WebAccelerator system uses two types of rules to manage content: matching rules and acceleration rules. Matching rules are used to classify requests by object type and match the request to a specific acceleration policy. Once matched to an acceleration policy, the WebAccelerator system applies the associated acceleration rules to manage the requests and responses. Depending on the application specific to your site, information in requests can sometimes imply one type of response (such as a file extension of .jsp), when the actual response is a bit different (like a simple document). For this reason, the WebAccelerator system applies matching rules twice: once to the request, and a second time to the response. This means that a request and a response can match to different acceleration rules, but it ensures that the response is matched to the acceleration policy that is best suited to it.
Tip

See Chapter 4, Using HTTP Headers to Configure Acceleration Policy Rules, for details about how the WebAccelerator system performs matching on specific parameters in acceleration policy rules.

Types of acceleration policies


There are three types of acceleration policies that you can use to speed up the access to your web applications.

Pre-defined Acceleration Policies The WebAccelerator system ships with several predefined acceleration policies that are optimized for specific web applications, as well as two non-application specific policies for general delivery, and one for an optional symmetric deployment. The general-delivery acceleration policies work well for sites that use Java 2 Platform Enterprise Edition (J2EE) applications, and are defined as follows: Level 1 Delivery Prompts the WebAccelerator system to send all requests for HTML pages to the origin web server for content, ignore any no-cache directives included in HTTP Cache-Control request headers, and use the cache response directives that it receives from the origin web server. This policy is compliant with HTML version 2.0. Level 2 Delivery Prompts the WebAccelerator system to cache HTML pages and set a lifetime setting for content to 0, use the Intelligent Browser Referencing feature only for documents and includes, ignore any no-cache directives included in HTTP Cache-Control request header, and use the cache response directives that it receives from the origin

Policy Management Guide for the BIG-IP WebAccelerator System

2-1

Chapter 2

web server. This policy is compliant with HTML version 3.0, and later. In most cases, you should use this predefined policy for those applications for which there is no application-specific predefined policy available.

User-defined Acceleration Policies A policy that you create by either copying an existing policy and modifying or adding rules, or by creating a new acceleration policy and specifying all new rules. Signed Acceleration Policies A policy created, certified, and encrypted by its author, such as a consultant or vendor. You can also create your own signed acceleration policy by configuring a user-defined acceleration policy, and signing it. After an acceleration policy is signed, you cannot view or modify the configured rules, as you can for predefined and user-defined acceleration policies.

2-2

Using Acceleration Policies

Managing your acceleration policies


The Policies screen displays all of the acceleration policies that are available for assignment to your applications.

To access the Policies screen


In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies.

Figure 2.1 Example Policies screen

From the Policies screen, you can access other screens, from which you can perform additional tasks.

To view rules for an acceleration policy


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies.

Policy Management Guide for the BIG-IP WebAccelerator System

2-3

Chapter 2

2. Click the name of the acceleration policy you want to view. Note that you cannot view rules for a signed acceleration policy. For more information, see Creating a signed acceleration policy, on page 2-8. 3. Click a node on the Policy Tree. The matching rules display for the selected node. 4. From the Matching Rules list, choose Acceleration Rules. 5. Click the name of an acceleration rule to view the configured rule parameters for the selected node.

To rename a user-defined or signed acceleration policy


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. In the Tools column for the acceleration policy you want to modify, click the Rename link. 3. In the Name box, type a new name for the acceleration policy. 4. In the Description box, type an optional description. 5. Click the Rename button to save the changes.

To delete a user-defined or signed acceleration policy


WARNING

Do not delete an acceleration policy unless you are sure that you do not ever want to refer to it again. You cannot recover a deleted acceleration policy. You can retain an acceleration policy to use later, even if you do not have an application that is currently using it. 1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Select the check box next to an acceleration policy, and then click the Delete button. Note that you cannot delete a predefined acceleration policy. 3. Confirm the deletion, keeping in mind that you cannot recover a deleted acceleration policy.

To specify a logging format for an acceleration policy


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. In the Tools column for the acceleration policy you want to modify, click the Logging link. Note that you cannot change the logging options for a predefined acceleration policy.
2-4

Using Acceleration Policies

3. To create individual logs for the HTTP and HTTPS protocols, select the Log HTTP and HTTPS requests separately check box. 4. For each protocol you want to log, select the button next to the following options as required: Log all transactions Only log transactions served from cache Do not log 5. If you select Log all transactions, or Only log transactions served from cache, then select a format for the logs from the Log Format list for each protocol. 6. Click the Save button.

For detailed information about logging options, see Chapter 12, Specifying Log Formats for Hit Logs.

Policy Management Guide for the BIG-IP WebAccelerator System

2-5

Chapter 2

Customizing acceleration policies


If you have a unique application for which you cannot use a predefined acceleration policy, you can create a new, user-defined acceleration policy or a signed acceleration policy. Before you can create a new acceleration policy, you need to analyze the type of traffic that your sites applications receive, and decide how you want the WebAccelerator system to manage those HTTP requests and responses. To help you do that, consider questions similar to those that follow. Which responses do I want the WebAccelerator system to cache? Are there responses for static documents that can remain in the WebAccelerator systems cache for several days before being refreshed? Which responses are dynamic documents that the WebAccelerator system should refresh hourly? Are there responses that the WebAccelerator system should never cache? After you decide how you want the WebAccelerator system to handle certain requests for your site, you can identify the HTTP data parameters that the WebAccelerator system uses to match requests and responses to the appropriate acceleration policies. For example, the path found on requests for static documents may be different than the path for dynamic documents. Or the paths may be similar, but the static documents are in PDF format and the dynamic documents are Word documents or Excel spreadsheets. These differences help you specify matching rules that prompt the WebAccelerator system to match the HTTP request to the acceleration policy that will handle the request and the response most expeditiously.

Creating a user-defined acceleration policy


You can create a user-defined acceleration policy most efficiently by copying an existing acceleration policy and modifying its rules to meet your unique requirements. Alternatively, you can create a new user-defined acceleration policy and define each matching rule and acceleration rule individually. When you copy or create an acceleration policy, the WebAccelerator system maintains that acceleration policy as a development copy until you publish it, at which time the WebAccelerator system creates a production copy. Only a production (published) copy of an acceleration policy is available for you to assign to an application. You can make as many changes as you like to the development copy of an acceleration policy without affecting current traffic to your applications.

2-6

Using Acceleration Policies

To copy an existing acceleration policy


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. In the Tools column for the acceleration policy you want to copy, click the Copy link. 3. In the Name box, type a descriptive name for the acceleration policy so you can easily identify it later. 4. In the Description box, type an optional description. 5. Click Copy.

To view and modify an acceleration policys rules


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy you want to view. 3. Click the branch node for the type of content you want to modify or a leaf node for a specific page type. The matching rules display for the selected node, and you can make changes as required. 4. From the Matching Rules list, choose Acceleration Rules. 5. Click the name of an acceleration rule to view the configured rule parameters for the selected node, and make changes as required See Modifying a Policy Tree for an acceleration policy, on page 3-11. 6. After you make the last change, click the Publish button from any screen within the Policy Editor. Alternatively, you can publish an acceleration policy from the Policies screen as described in Publishing acceleration policies, on page 2-10.

The acceleration policy is now available for assignment to an application.

To create a new user-defined acceleration policy


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the Create button. 3. In the Name box, type a descriptive name for the acceleration policy so you can easily identify it later. 4. In the Description box, type an optional description. 5. Click the Create button. 6. Click the name of the acceleration policy that you created.

Policy Management Guide for the BIG-IP WebAccelerator System

2-7

Chapter 2

7. Create the Policy Tree by defining branch nodes for the groups of content, and leaf nodes for specific content. 8. Click a node and specify the matching and acceleration rules. For more information, see Modifying a Policy Tree for an acceleration policy, on page 3-11. 9. After you make the last change, click the Publish button from any screen within the Policy Editor. Alternatively, you can publish an acceleration policy from the Policies screen as described in Publishing acceleration policies, on page 2-10.

The acceleration policy is now available for assignment to an application.

Creating a signed acceleration policy


A signed acceleration policy is encrypted and certified by its author and customized to work specifically for an application. You cannot view or modify the specific rules for a signed acceleration policies; the policy is locked. You can import a signed acceleration policy from several sources, such as the publisher of a specific application or a consultant, or you can sign a user-defined policy that you have created and customized.

To sign an acceleration policy


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. In the Tools column for the acceleration policy you want to sign, click the Sign link. 3. From the SSL Certificate(s) to encrypt to list, select one or more SSL certificate that you want to use for the signed acceleration policy. Alternatively, you can create a new SSL certificate and key, or import one by clicking the Create or Import link. For specific information about creating or importing SSL certificates and keys refer to the online help, or see the Managing keys and certificates section in the Managing SSL Traffic chapter of the Configuration Guide for BIG-IP Local Traffic Manager. 4. From the Signing SSL Certificate private key list, select the private key that you want to use. 5. Click the Export button. 6. Click the Save button. 7. Navigate to the location where you want to save the file. 8. Click the Save button.

2-8

Using Acceleration Policies

Once you sign and save the acceleration policy to an XML file, you can load it onto any system running the same version of the WebAccelerator system software. Then, you can publish it and make it available for assignment to your applications. See Publishing acceleration policies, on page 2-10.

To import a signed acceleration policy


Important

Before importing a signed acceleration policy, you must first import the SSL certificate of the system on which the policy was signed. For a symmetric deployment, the signed acceleration policy must be signed against each WebAccelerator system in the deployment. For specific information about importing SSL certificates and keys, refer to the online help, or see the Managing keys and certificates section in the Managing SSL Traffic chapter of the Configuration Guide for BIG-IP Local Traffic Manager. 1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the Import button. 3. Click the Browse button to browse to the location of the XML file you want to import. 4. Specify whether you want to replace the existing acceleration policy: If you do not want to replace the existing acceleration policy, clear the Overwrite existing policy of the same name check box. You can rename the acceleration policy after you import it. If you want to replace an existing acceleration policy with the imported acceleration policy with the same name, select the Overwrite existing policy of the same name check box.

Tip

If you have more than one application that requires the same signed acceleration policy, but with different logging options, you can copy the signed acceleration policy and modify the logging options as required. See To copy an existing acceleration policy, on page 2-7. For more information about logging options, see Chapter 12, Specifying Log Formats for Hit Logs.

Policy Management Guide for the BIG-IP WebAccelerator System

2-9

Chapter 2

Publishing acceleration policies


When you modify rules for a user-defined acceleration policy that is currently assigned to an application, the WebAccelerator system creates a development copy and continues to use the currently published (production) copy to manage requests. The WebAccelerator system uses the modified acceleration policy to manage traffic only after you publish it. If you create a new acceleration policy, you must publish it before you can assign it to an application.

To publish an acceleration policy


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. In the Tools column for the acceleration policy you want to publish, click the Publish link. 3. In the Comment box, type any optional text that you want displayed with the publishing details, such as a brief summary of the changes you made. 4. Click Publish Now.

2 - 10

Using Acceleration Policies

Saving an acceleration policy to an XML file


You can use the export feature to save an acceleration policy to an XML file. We recommend that you use the export feature every time you change a user-defined acceleration policy, so that you always have a copy of the most recent acceleration policy. You can use this file for back up and archival purposes, or to provide to the F5 Networks Technical Support team for troubleshooting issues.

To save an acceleration policy to an XML file


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. In the Tools column for the acceleration policy you want to export, click the Export link. 3. From the Export list, select one of the following: Published Policy Select this option to export an acceleration policy that an application is currently using. If the acceleration policy has not been published, this option does not display. Development Policy Select this option to export an unpublished acceleration policy. 4. Click the Export button. 5. Click the Save button. 6. Navigate to the location where you want to save the file. 7. Click the Save button.

To import a saved acceleration policy


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click Import. 3. Click the Browse button to browse to the location of the XML file you want to import. 4. Specify whether you want to replace the existing acceleration policy: If you do not want to replace the existing acceleration policy, clear the Overwrite existing policy of the same name check box. You can rename the acceleration policy after you import it. If you want to replace an existing acceleration policy with the imported acceleration policy of the same name, select the Overwrite existing policy of the same name check box.

Policy Management Guide for the BIG-IP WebAccelerator System

2 - 11

Chapter 2

After you import an acceleration policy, you can publish it to make it available for assignment to your applications.

2 - 12

3
Using the Policy Editor

Overview of the Policy Editor screen Using the Policy Tree Understanding acceleration policy rule inheritance Modifying a Policy Tree for an acceleration policy

Using the Policy Editor

Overview of the Policy Editor screen


From the Policy Editor screen, you can view the matching rules and acceleration rules for user-defined and predefined acceleration policies, as well as create or modify user-defined acceleration policies.

To access the Policy Editor screen


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of a user-defined or predefined acceleration policy. The Policy Editor screen opens, where you can view the matching rules and acceleration rules for the selected acceleration policy.
Note

You cannot view or modify the rules for a signed acceleration policy. For more information, see Creating a signed acceleration policy, on page 2-8.

Figure 3.1 Policy Editor screen for an example acceleration policy

Policy Management Guide for the BIG-IP WebAccelerator System

3-1

Chapter 3

There are three main parts to the Policy Editor screen:

Policy Tree Located on the left side of the Policy Editor screen, the Policy Tree contains branch nodes and leaf nodes. A branch node represents a group of content types (such as application generated or static) and each leaf node represents specific content (such as images, includes, PDF documents, or Word documents). The Policy Tree function bar includes the following options: Add Use to create a new content type group (branch node) or a new content type (leaf node). Rename Use to change the name of a branch or leaf node. Delete Use to remove a branch or leaf node. Copy Use to copy a branch or leaf node. up, down arrows Use to change the priority of a leaf node up or down within the branch node.

Screen trail Located above the Policy Editor menu bar, the screen trail displays (horizontally) the screens that you accessed in order to arrive at the current screen. You can click the name of a screen in the trail to move back to a previous location. Policy Editor menu bar Located below the screen trail, the Policy Editor menu bar contains a list from which you select Matching Rules (default) or Acceleration Rules.

Figure 3.2 Matching rules displayed from the Policy Editor

3-2

Using the Policy Editor

When you select Acceleration Rules, the acceleration rules menu bar displays, as illustrated in Figure 3.3.

Figure 3.3 Policy Editor menu bar displaying acceleration rules options

For more information about these acceleration rules, see the associated chapters in this guide.

Policy Management Guide for the BIG-IP WebAccelerator System

3-3

Chapter 3

Using the Policy Tree


Matching rules and acceleration rules for acceleration policies are organized on the Policy Tree, which you access from the Policy Editor screen.

To view the Policy Tree for an acceleration policy


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to view. The Policy Editor screen opens, with the Policy Tree to the left of the screen.

Figure 3.4 A Policy Tree example

Policy Tree example


For this example, the site receives only two types of requests: Requests for a CGI-based application and requests for GIF images. The Policy Tree for this acceleration policy consists of two leaf nodes. The Application leaf node has two associated matching rules that identify a match for a CGI-based application as follows: A rule based on the path that appears in the requests URL A rule based on the request and response not matching an image content type The Images leaf node has an associated matching rule that identifies a match in a request, if the file extension is .gif.

3-4

Using the Policy Editor

The WebAccelerator system matches requests to the Application leaf node when the requests path is for a CGI-based application. Since the WebAccelerator system matches both requests and responses, if the response from the application on the origin web server is a GIF image, the WebAccelerator system matches the response to the Images leaf node and applies that leafs associated acceleration rules.

Policy Management Guide for the BIG-IP WebAccelerator System

3-5

Chapter 3

Understanding acceleration policy rule inheritance


The structure of the Policy Tree supports a parent-child relationship. This allows you to easily randomize rules. That is, because a leaf node in a Policy Tree inherits all the rules from its root node and branch node, you can quickly create multiple leaf nodes that contain the same rule parameters by creating a branch with multiple leaf nodes. If you override or create new rules at the branch node level, the WebAccelerator system reproduces those changes to the associated leaf nodes. Nodes are defined as follows.

Root node The root node exists only for the purpose of inheritance; the WebAccelerator system does not perform matching against root nodes. The Policy Tree typically has only one root node, from which all other nodes are created. For the example illustrated in Figure 3.5, on page 3-7, the root node is Home. What distinguishes a root node from a branch node is that a root node has no parent node. Branch node The branch nodes exist only for the purpose of propagating rule parameters to leaf nodes; the WebAccelerator system does not perform matching against branch nodes. For the example illustrated in Figure 3.5, on page 3-7, the branch nodes are Applications, Images, Documents, Components, and Other. Branch nodes can have multiple leaf (child) nodes, as well as child branch nodes. Leaf node A leaf node inherits rule parameters from its parent branch node. The WebAccelerator system performs matching only against leaf nodes, and then applies the leaf nodes corresponding acceleration rules to the request. Leaf nodes are displayed on the Policy Tree in order of priority. If a request matches two leaf nodes equally, the WebAccelerator system matches to the leaf node with the highest priority. For the example illustrated in Figure 3.5, on page 3-7, the leaf nodes that are displaying are Default and Search.

Figure 3.5, on page 3-7, shows a sample Policy Tree for an acceleration policy. Since the majority of the rules are the same for each leaf node, all of the example acceleration policys rule parameters are defined at the Home branch node. Therefore, all of the leaf nodes for the branch have the same matching and acceleration rules. From that point, it was easy to modify the rules only for the specific needs of the Default and Search leaf nodes.

3-6

Using the Policy Editor

Figure 3.5 Rule inheritance on a Policy Tree

Inheriting rule parameters


When you create a user-defined acceleration policy by copying an existing acceleration policy, you must determine from which branch node the acceleration policy is inheriting specific rules, and decide whether you want to change the rules at the leaf node or change the rules at the branch node. To determine inheritance for a rule parameter, view the rule parameters inheritance icon. For example, Figure 3.6 illustrates matching rules for the Path and Header rule parameters for a particular leaf node.

Figure 3.6 Inheritance example for Path and Header parameters

Policy Management Guide for the BIG-IP WebAccelerator System

3-7

Chapter 3

The arrow icon in the Inheritance column next to the Path parameter indicates this rule was inherited from the parent branch node. The inheritance icon next to the Header parameter does not have an arrow, indicating that the rule was not inherited; it was created locally at the leaf node. Since the Header parameter rule is not inherited, you can delete the rule at the leaf node level. However, you cannot delete the Path parameter because it was inherited from the branch node. To delete the Path parameter rule, you must delete from its parent branch node. For inherited rule parameters, you can determine the ancestor branch node by hovering the cursor over the inheritance icon. For this example, when placing the cursor on the inheritance icon next to Path, the branch node Home displays as the ancestor node, as illustrated in Figure 3.7.

Figure 3.7 Inheritance example for Path parameter

Overriding inherited rule parameters


When you override an inherited setting for a rule, an override icon displays (the inheritance icon with a red X) next to the rule setting. To see the node where the option was overridden, place your cursor over the override icon. For example, for the content assembly rule in Figure 3.8, all of the options are inherited from the branch node, except for the Enable MultiConnect option. For this node, the rule was disabled at the leaf node. When hovering the cursor over the override icon, a message displays next to the Content Assembly Options menu.

Figure 3.8 Inheritance example with overridden rule option

3-8

Using the Policy Editor

To see if the current leaf node inherited this overridden option, click the parent branch node and view its rules. In Figure 3.9, you see that there were no rule settings overridden at the parent branch, indicating the rule was inherited from the branch node, Home, and overridden at the leaf node.

Figure 3.9 Parent of leaf node example

When you follow this rule back to its grandparent, you see the rule options are not inherited from any other node; they are set at the grandparent node and they are all enabled, as indicated in Figure 3.10.

Figure 3.10 Grandparent of leaf node example

If you want to enable the content compression feature at the leaf node, you can use one of the following options: Override the inherited setting at the leaf node and select the Enable Content Compression check box. Cancel the override setting at the parent, so that the parent inherits the Enable Content Compression setting of the grandparent, and passes that setting to the leaf node.

Policy Management Guide for the BIG-IP WebAccelerator System

3-9

Chapter 3

Keep in mind that if you cancel the override setting at the grandparent branch node, you change the settings for all of the child leaf nodes, not just the leaf node you want to change.
Tip

Although you have the option to override rules at the leaf node level, you should set up the Policy Tree in a logical way so that you only specify rules for branch nodes that you want all or most of its child leaf nodes to inherit. In other words, do not set a rule for a branch node if you know that most its leaf nodes will not use that rule.

3 - 10

Using the Policy Editor

Modifying a Policy Tree for an acceleration policy


To customize a user-defined acceleration policy, you can modify the branch and leaf nodes matching rules and acceleration rules. Or, you can add new branch and leaf nodes and associated matching and acceleration rules to the Policy Tree.
Important

You can edit only user-defined acceleration policies. You cannot edit predefined or signed acceleration policies.

To add a new branch or leaf node to the Policy Tree


1. On the Policy Tree function bar, click Add. 2. In the Name box, type a name for the new branch or leaf node. 3. In the Description box, type an optional description. 4. Select the Create a new Policy Tree branch check box. 5. Click the Create button. The screen refreshes and the Policy Tree displays with the new branch, where you can specify the matching rules and acceleration rules for the new branch as required.

To rename a node on the Policy Tree tree


1. On the Policy Tree, click the name of the node that you want to rename. 2. On the Policy Tree function bar, click Rename. 3. In the Name box, type a new name for the node as required. 4. Click the Rename Node button. The screen refreshes and the Policy Tree displays the node with the new name.

To delete a node from the Policy Tree


1. On the Policy Tree, click the node that you want to delete. 2. On the Policy Tree function bar, click Delete. The screen refreshes and the Policy Tree displays, without the node you removed.

To copy a node on the Policy Tree


1. On the Policy Tree, click the node that you want to copy. 2. On the Policy Tree function bar, click Copy. 3. In the Name box, type a name for the new node.
Policy Management Guide for the BIG-IP WebAccelerator System

3 - 11

Chapter 3

4. In the Description box, type an optional description. 5. Click the Copy button. The screen refreshes and the Policy Tree displays with the node you copied.

To change the priority of a node on the Policy Tree


For ambiguous queries, the WebAccelerator system chooses between the leaf nodes based on their priority on the Policy Tree. You can change the priority of a leaf node only within a branch of the tree. For example, in Figure 3.5, on page 3-7, you can give the Default leaf node priority over the Search leaf node, but not over the Images node. 1. On the Policy Tree, click the node for which you want to change the priority. 2. On the Policy Tree function bar, click the Up or Down button. The node changes positions on the Policy Tree, as directed.

For more information about ambiguous queries, see Application matching based on node precedence, on page 5-2.

3 - 12

4
Using HTTP Headers to Configure Acceleration Policy Rules

Using HTTP header parameters to process requests Configuring rules based on HTTP request headers Configuring rules based on HTTP response headers Using regular expressions and meta tags for rules Managing Cache-Control response headers Using ESI Surrogate-Control headers Viewing X-PvInfo response headers

Using HTTP Headers to Configure Acceleration Policy Rules

Using HTTP header parameters to process requests


Much of the WebAccelerator systems behavior is dependent on the configured rules associated with parameters in the HTTP request headers. Although important, the presence or value of HTTP response headers does not influence as many aspects of the WebAccelerator systems behavior, because the WebAccelerator system receives HTTP response headers after performing certain types of processing. When the WebAccelerator system receives a new request from a client, it first reviews the HTTP request parameters to match it to the relevant acceleration policy. After applying the associated matching rules, it sends the request to the origin web server for content. Before sending a response to a client, the WebAccelerator system inserts an X-PvInfo response header to track how it handled the request. You cannot change these informational headers, and they do not affect processing, however, they can provide useful information for evaluating your acceleration policies. For more information, see Viewing X-PvInfo response headers, on page 4-25.

Requirements for servicing requests


To maintain high performance, the WebAccelerator system does not service an HTTP request unless the request meets the following conditions. The request includes an HTTP request header that is no larger than 8192 bytes, and in the first line, identifies its method, URI, and protocol. The method for the HTTP request header is a GET, POST, or HEAD. The protocol for the HTTP request header is a HTTP/0.9, HTTP/1.0, or HTTP/1.1. The HTTP post data on the request is no larger than 32768 bytes. If the request provides the Expect request header, the value is 100-continue. If the request provides the Content-Type request header, the value is application/x-www-form-urlencoded. The request includes a Host request header identifying a targeted host that is mapped to an origin server at your site. For more information, see the Planning your host map section in Chapter 3 of the Configuration Guide for the BIG-IP WebAccelerator System. If the HTTP Host request header is missing or does not have a value, the WebAccelerator system responds to the requesting client with a 400-series error message. If the request violates any of the other conditions, the WebAccelerator system redirects the request to the origin web servers for content.

Policy Management Guide for the BIG-IP WebAccelerator System

4-1

Chapter 4

Processing requests
When a WebAccelerator system receives an HTTP request that meets the conditions described in Requirements for servicing requests, on page 4-1, the WebAccelerator system processes the request as follows: 1. Performs application matching against the request and retrieves the associated acceleration rules. 2. If matched to a proxying rule, the WebAccelerator system sends the request to the origin web servers as required by the rule. Proxying rules are described in Chapter 8, Configuring Proxying Rules. 3. If the request does not match to a proxying rule, the WebAccelerator system attempts to retrieve the appropriate compiled response from its cache. 4. If there is no compiled response in its cache, the WebAccelerator system sends the request to the origin web servers for content. 5. If it finds a compiled response in its cache, the WebAccelerator system looks for an associated content invalidations rule for the compiled response. For the conditions and mechanisms that trigger a content invalidations rule, see Chapter 10, Configuring Invalidations Rules. 6. If a content invalidations rule is triggered for the compiled response, the WebAccelerator system compares the rules effective time against the compiled responses last refreshed time. If the compiled responses last refreshed time is before the content invalidations rules triggered time, the WebAccelerator system sends the request to the origin web servers for content. 7. If a content invalidations rule is not triggered, or if the compiled responses last refreshed time is after the invalidations rules effective time, the WebAccelerator system examines the compiled responses TTL value to see if the compiled response has expired. If it has expired, the WebAccelerator system sends the request to the origin web servers. 8. If the compiled response has not expired, the WebAccelerator system services the request using the cached compiled response.

Requirements for caching responses


When the WebAccelerator system receives a response from the origin web server, it inspects the HTTP response headers, applies the acceleration rules to the response, and sends the content to the client. To ensure the most effective performance, the WebAccelerator system does not cache a response from the origin server, or forward it to the originating requestor, unless it meets the following conditions. The request does not match to a do-not-cache proxying rule. See Chapter 8, Configuring Proxying Rules, for more information.
4-2

Using HTTP Headers to Configure Acceleration Policy Rules

The first line of the response identifies the protocol, a response code that is an integer value, and a response text. For example: HTTP/1.1 200 (OK) If the Transfer-Encoding response header is used on the response, the value is chunked. The response is complete, based on the method and type of data contained within the response, as follows: HTML tags By default, the WebAccelerator system considers a response in the form of an HTML page complete only if it contains both beginning and ending HTML tags. Content-Length response header If a response is anything other than an HTML page, or if you have overridden the default behavior described in the previous bullet point, the WebAccelerator system considers content complete only if the response body size matches the value specified on the Content-Length response header. Chunked transfer coding If you do not use a Content-Length response header for a response, you must use chunked transfer coding. If you use chunked transfer coding, the WebAccelerator system does not consider content complete until it receives the final zero-sized chunk. For information about chunked transfer coding, see section 3.6 in the HTTP/1.1 specification http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6 The body of a response does not exceed the value of the maxResponseDataSize parameter in the WebAccelerator systems configuration file. By default, this value is 64MB. If the WebAccelerator system receives a response from the origin server that does not conform to these conditions, it does not cache the response before sending it to the client.

Policy Management Guide for the BIG-IP WebAccelerator System

4-3

Chapter 4

Configuring rules based on HTTP request headers


In most cases, the default values for the predefined acceleration policies are sufficient, but you can fine-tune the WebAccelerator systems behavior by creating a user-defined acceleration policy and modifying the HTTP request data type parameters. When you specify or modify an HTTP data type parameter for an acceleration policy rule, you define specific HTTP data type parameter criteria that the WebAccelerator system uses to manage HTTP requests. When specifying parameter criteria, you designate the following information within a rule.

Parameter identity This can include one or more of the following criteria: Parameter type Parameter name Parameter location within the HTTP request

Parameter value or state This can include one or more of the following parameter state and value: Parameter is present in the HTTP request and matches the defined value provided in the form of a regular expression Parameter is present in the HTTP request and does not match the specified value provided in the form of a regular expression Parameter is present in the HTTP request, but has no value (is an empty string) Parameter is not present in the HTTP request

WebAccelerator system action Where you specify the following criteria: Whether the WebAccelerator system performs an action on a match or a no match The action that the WebAccelerator system performs, which is dictated by the rules in the associated acceleration policy For example, if you specify a rule that the WebAccelerator system performs an action when a request does not match a configured parameter, the rule triggers if the parameter in the request is a different value than you specified, or if the value is empty (null). The WebAccelerator system does not perform the specified action if the parameter does not appear in the request.

4-4

Using HTTP Headers to Configure Acceleration Policy Rules

Specifying HTTP data type parameters for a rule


You cannot configure rules based on all HTTP data types parameters; you can only specify the parameters that the WebAccelerator system uses when processing HTTP requests. Table 4.1 outlines the HTTP data type parameters that you can configure specific rules.
Matching Rules x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x Variation Rules x Assembly Rules Proxying Rules x Invalidations Rules x x x x x x x x x x x x x

Parameters Host Path Extension Query parameter Unnamed query parameter Path segment Cookie User Agent Referrer Protocol Method Header Client IP Content Type

Table 4.1 HTTP request data type parameters

Note

Lifetime rules and responses cached rules, described in Chapter 9, Configuring Lifetime Rules, and Chapter 11, Configuring Responses Cached Rules, do not use HTTP data type parameters. The HTTP data type parameters that the WebAccelerator system uses when processing HTTP requests, are defined as follows.
Note

To specify that the parameter name is case-sensitive, enable the Values are case sensitive setting when configuring the parameter options.

Policy Management Guide for the BIG-IP WebAccelerator System

4-5

Chapter 4

Host
A rule that uses the host parameter is based on the value provided for the HTTP Host request header field. This header field describes the DNS name that the HTTP request is using. For example, for the following URL the host equates to HOST: www.siterequest.com. http://www.siterequest.com/apps/srch.jsp?value=computers

Path
A rule that uses the path parameter is based on the path portion of the URI. The path is defined as everything in the URL after the host and up to the end of the URL, or up to the question mark, (whichever comes first). For example:
URL Path

http://www.siterequest.com/apps/srch.jsp?value =computers http://www.siterequest.com/apps/magic.jsp Table 4.2 Path example

/apps/srch.jsp

/apps/magic.jsp

Extension
A rule that uses the extension parameter is based on the value that follows the far-right period, in the far-right segment key of the URL path.
Note

Segment keys, the text following the semicolon and preceding the question mark in the third URL, are described in Path segment, on page 4-7. For example, in the following URLs, gif, jpg, and jsp are all extensions: http://www.siterequest.com/images/up.gif http://www.siterequest.com/images/down.jpg http://www.siterequest.com/apps/psrch.jsp;sID=AAyB23?src=magic

Query parameter
A rule that uses the query parameter is based on a particular query parameter that you identify by name, and for which you provide a value to match against. The value is usually literal and must appear on the query parameter in the request, or a regular expression that matches the requests query parameter value. The query parameter can be in a request that uses GET or POST methods.

4-6

Using HTTP Headers to Configure Acceleration Policy Rules

You can also create a rule that matches the identified query parameter when it is provided with an empty value, or when it is absent from the request. For example, in the following URL the action query parameter provides an empty value: http://www.siterequest.com/apps/srch.jsp?action=&src=magic

Unnamed query parameter


An unnamed query parameter is a query parameter that has no equal sign. That is, only the query parameter value is provided in the URL of the request. For example, the following URL includes two unnamed query parameters that have the value of dog and cat: http://www.siterequest.com/apps/srch.jsp?dog&cat&src=magic A rule that uses the unnamed query parameter specifies the ordinal of the parameter, instead of a parameter name. The ordinal is the position of the unnamed query parameter in the query parameter portion of the URL. You count ordinals from left to right, starting with 1. In the previous URL, dog is ordinal 1, and cat is ordinal 2. You can create a rule that matches the identified (unnamed) query parameter when it is provided with an empty value, or when it is absent from the request. For example, in the following URL, ordinal 1 provides an empty value. http://www.siterequest.com/apps/srch.jsp?&cat&src=magic In the following URL, ordinal 3 is absent (dog is in ordinal 1 and src is in ordinal 2). http://www.siterequest.com/apps/srch.jsp?dog&src=magic.

Path segment
A rule that uses the path segment parameter identifies one of the following values: Segment key Segment parameter

Segment keys
A segment is the portion of a URI path that is delimited by a forward slash (/). For example, in the path: /apps/search/full/complex.jsp, apps, search, full, and complex.jsp all represent path segments. Further, each of these values are also the segment key, or the name of the segment.

Segment parameters
A segment parameter is the value in a URL path that appears after the segment key. Segment parameters are delimited by semicolons. For example, magic, shop, and act are all segment parameters for their respective path segments in the following path: /apps/search/full;magic/complex.jsp;shop;act

Policy Management Guide for the BIG-IP WebAccelerator System

4-7

Chapter 4

To specify segment parameters, you must also identify: Segment ordinals Segment parameter ordinals

Segment ordinals
To specify a segment for a rule, you must provide an ordinal that identifies the location of the segment in the path: /apps/search/full;magic/complex.jsp;shop;act You must also indicate in the rule, which way you are counting ordinals in the path: from the left or the right (you always count starting at 1). For the example shown, /full;magic, the ordinals for this path are as show in Table 4.3.
Ordinal 3 2 Numbering Selection Numbering Left-to-Right in the Full Path Numbering Right-to-Left in the Full Path

Table 4.3 Segment ordinals example

Segment parameter ordinals


When you specify a segments ordinal for a rule, you must also identify the ordinal of the element within the segment. You count segment parameter ordinals left-to-right in the path, and the segment key is always ordinal 0. For the segment, /complex.jsp;shop;act, the ordinals and elements are defined as outlined in Table 4.4.
Ordinal 0 1 2 Segment Segment Element Type segment key segment parameter segment parameter

complex.jsp shop act

Table 4.4 Segment parameter example

Cookie
A rule that uses the cookie parameter is based on a particular cookie that you identify by name, and for which you provide a value to match against. Usually the value is literal and must appear on the cookie in the request, or a regular expression that must match the requests cookie that appears on the cookie HTTP request headers. These are the same names you use to set the cookies, using the HTTP SET-COOKIE response headers.

4-8

Using HTTP Headers to Configure Acceleration Policy Rules

You can also create a rule that matches when the identified cookie is provided with an empty string or when it is absent from the request. For example, in the following string, the following REPEAT cookie is empty: COOKIE: REPEAT= In the following string, the USER cookie is present and the REPEAT cookie is absent: COOKIE: USER=334A5E4.

User agent
A rule that uses the user agent parameter is based on the value provided for the HTTP USER_AGENT in the request header, which identifies the browser that sent the request. For example, the following USER_AGENT request header indicates that the requesting browser is IE 5.01 running on Windows NT 5.0: USER_AGENT: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) You do not typically base rules on the USER_AGENT request header, unless your site behaves differently depending on the browser in use.

Referrer
A rule that uses the referrer parameter is based on the value provided for the HTTP REFERER in the request header. (Note the misspelling of REFERER. This spelling is defined for this request header in all versions of the HTTP specification.) This header provides the URL location that referred the client to the page that the client is requesting. That is, REFERER provides the URL that contains the hyperlink that the user clicked to request the page. For example: REFERER: http://www.siterequest.com/ You do not typically base rules on the REFERER request header, unless you want your sites behavior to be dependent on the specific referrer. For example, one implementation would be for sites that provide different branding for their pages based on the users web portal or search engine.

Protocol
A rule that uses the protocol parameter is based on whether the request uses the HTTP or HTTPS protocol. For example, the following URL uses the HTTP protocol: http://www.siterequest.com/apps/srch.jsp?value=computers The following URL uses the HTTPS protocol: https://www.siterequest.com/apps/srch.jsp?value=computers

Policy Management Guide for the BIG-IP WebAccelerator System

4-9

Chapter 4

Method
A rule that uses the method parameter is based on whether the request used the GET or POST method.

Header
A rule that uses the header parameter is based on a particular header that you identify by name, and for which you provide a value to match against. You can use an HTTP request data type header parameter to create rules based on any request header, other than one of the recognized HTTP request data types that are listed in Table 4.1, on page 4-5. The HTTP request data type header parameter you use can be standard HTTP request header fields such as AUTHORIZATION, CACHE-CONTROL, and FROM. They can also be user or acceleration defined headers in the form of a structured parameter. Following are examples of HTTP request data type parameters: Accept: text/html, image/* Accept-Encoding: gzip Accept-Language: en-us CSP-Gadget-Realm-User-Pref: NM=5,PD=true,R=3326 The last header in the example depicts a structured parameter. The format of a structured parameter in a request is similar to that used for a cookie, with a header name that you choose, followed by a series of name=value pairs separated by commas. The header name is not case-sensitive and in this structure, the semicolons (;) are special characters. The parser ignores anything after a semicolon until it reaches the subsequent comma. For example, following are valid header structured parameters: CSP-Global-Gadget-Pref: AT=0 CSP-Gadget-Realm-User-Pref: NM=5,PD=true,R=3326 CSP-User-Pref: E2KU=chi,E2KD=ops%u002esiterequest%u002enet,E2KM=chi CSP-Gateway-Specific-Config: PT-User-Name=chi,PT-User-ID=212,PT-Class-ID=43 Standards: type=SOAP;SOAP-ENV:mustUnderstand="1",version=1.2 In the last line, the parser ignores SOAP-ENV:mustUnderstand="1", because it follows a semicolon. Since version=1.2 follows the command, the parser reads it as a name=value pair. If you have metadata that you want to include in the header, but want the WebAccelerator system to ignore, put it after a semicolon. If you specify a header as a structured parameter when creating a rule, the WebAccelerator system parses it into name=value pairs when it examines the request. If you do not specify it as a structured parameter, the WebAccelerator system processes it like a normal header, and treats everything after the colon (:) as the value. To define a header as a structured parameter when you are creating or editing a rule, you specify the name using the following syntax: headername:parmname

4 - 10

Using HTTP Headers to Configure Acceleration Policy Rules

Where: headername Is the name of the header. parmname Is the name of the parameter with the value that you want to affect the rule. Using the CSP-Global-Gadget-Pref header as an example, if you want the WebAccelerator system to evaluate the value for AT to determine if a configured rule should apply, specify the name of the header parameter as follows: CSP-Global-Gadget-Pref:AT If you want the WebAccelerator system to evaluate the entire string without assigning meaning to name=value pairs, specify the name of the header parameter as follows: CSP-Global-Gadget-Pref You can create a rule that matches when the identified header is provided with an empty value, or when it is absent from the request. In the following example, the WebAccelerator system considers Standards:release, empty and considers Standards:SOAP-ENV absent, because it is ignored: Standards: type=SOAP;SOAP-ENV:mustUnderstand="1",release=,version=1.2

Client IP
A rule that uses the client IP parameter is based on the IP address of the client making the request. The IP address, however, may not always be the address of the client that originated the request. For example, if the client goes through a proxy server, the IP address is the IP address of the proxy server, rather than the client IP address that originated the request. If several clients use a specific proxy server, they all appear to come from the same IP address.

Content Type
A rule that uses the Content Type parameter is based on type definitions in the config/wa/globalfragment.xml file. Unlike the HTTP request data types, a matching rule based on content type is specific to the content type parameter that the WebAccelerator system generates for a response. You specify the regular expression that you want a response's content type to match.

Policy Management Guide for the BIG-IP WebAccelerator System

4 - 11

Chapter 4

Configuring rules based on HTTP response headers


After the WebAccelerator system receives a response from the origin web server, it performs the following processes: Classifies the response Applies associated acceleration policy rules Assembles the response Response headers have no effect on application matching, variation, or invalidations rules. The WebAccelerator system evaluates response headers associated with caching after it compiles, but before it caches, the response. Once the WebAccelerator system begins the compilation and assembly process, it then examines existing response headers that influence assembly. You can configure assembly, proxying, lifetime, or responses cached rules based on response headers.
Note

If you configure proxying rules based on HTTP response header parameters, you can use them only in terms of how the WebAccelerator system caches the responses, because the WebAccelerator system has already sent the request to the origin web servers when it reviews the response headers.

Classifying responses
After the WebAccelerator system receives a response from the origin server, and before it performs application matching, it classifies the response based on the object types that are defined on the Object Types screen. The WebAccelerator system bases this classification on the first item it finds, in the following order: The file extension in the file name field of the responses Content-Disposition header The file extension in the extension field of the responses Content-Disposition header The responses Content-Type header, unless it is an ambiguous MIME type The requests path extension For example, if the extension in the file name field of the responses Content-Disposition header is empty, the WebAccelerator system looks at the responses Content-Disposition headers file extension in the extension field. If that has an extension, the WebAccelerator system attempts to match it to a defined object type. If there is no match, the WebAccelerator system assigns an object type of other and uses the settings for other. The WebAccelerator system examines the information in the Content-Type header only if there is no extension in the file name or extension fields of the Content-Disposition header.
4 - 12

Using HTTP Headers to Configure Acceleration Policy Rules

If the WebAccelerator system finds a match to an object type, it classifies the response with that object type, group, and category, and uses the associated settings for compression. The object type and group under which the response is classified is also included in the X-PvInfo response header. For more information, see Viewing X-PvInfo response headers, on page 4-25.
Important

If you have defined a compression setting for an object from the Object Types screen, it overrides any compression setting configured for an assembly rule for the responses matched node. For specific information about how to configure object types, see the Changing Default Settings chapter in the Configuration Guide for the BIG-IP WebAccelerator System. Once it classifies the response by object type, the WebAccelerator system appends it as follows: group.objectType. The WebAccelerator system then matches the response to a node of a Policy Tree in an acceleration policy (the first matching process was for the request), using the new content type. In many cases, this content type is the same as the content type for the request, and the WebAccelerator system matches the response to the same node as the request.
Note

The WebAccelerator system also matches the response to the same node as the request if there is no Content Type parameter specified in a matching rule. Unlike the HTTP request data types, you do not base a matching rule directly on the value of an HTTP response data type. Instead, you base the rule on the content type parameter that the WebAccelerator system generates, by specifying the regular expression that you want a request or responses content type to match, or not to match.

Applying associated acceleration policy rules


After classifying the response, the WebAccelerator system uses its Rewrite Engine to run any associated response rewrite scripts, defined by one of the following: The responses object type The assembly rules for the node to which the response matched The WebAccelerator system then compiles the response, and determines if it can cache it by looking for a responses cached rule for the node that matches the response. If the response is cacheable, the WebAccelerator system caches a copy of the response.

Policy Management Guide for the BIG-IP WebAccelerator System

4 - 13

Chapter 4

Assembling responses
The WebAccelerator system assembles responses using the following information: The assembly rules specified for the node that matches the response. The Enable Compression setting (configured from the Object Types screen) for the object type under which the response was classified. The options for this setting are: Policy Controlled The WebAccelerator system uses the compression settings configured in the acceleration policys assembly rules. None The WebAccelerator system never compresses the response. This option overrides the compression setting in the acceleration policys assembly rules. Select this option only if you want the WebAccelerator system to ignore assembly rules for the specified object type. In Symmetric Deployment only The WebAccelerator system compresses the response only when it sends it to another WebAccelerator system, but never compresses the response when sending a response to a browser client. This option overrides the compression setting in the acceleration policys assembly rules. Select this option only if you have a symmetric deployment and want the WebAccelerator system to compress this object type when it is sent between a central and remote WebAccelerator system. For more information about symmetrical deployments, see the Configuration and Maintenance Tasks chapter in the Configuration Guide for the BIG-IP WebAccelerator System. If the response includes an ESI Surrogate-Control header, the WebAccelerator system performs ESI processing as part of the assembly and applies any associated lifetime rules and parameter substitutions configured for the node, and then sends the response to the client. For more information, see Using ESI Surrogate-Control headers, on page 4-22.

4 - 14

Using HTTP Headers to Configure Acceleration Policy Rules

Using regular expressions and meta tags for rules


When the WebAccelerator system performs pattern matching based on regular expressions, it assumes all regular expressions are in the form of ^expression$, even if you do not explicitly set the beginning of line (^) and end of line ($) indicators. For substring searches, you enter *expression.* as a regular expression. The string that the WebAccelerator system matches is dependent on the HTTP data type for which you are providing the regular expression. Before the WebAccelerator system attempts to match information in an HTTP request to the HTTP request data type parameters, it translates any escaped characters (such as %2F or %2E) back to their regular form, such as (/ or .,).

Supported regular expression strings


The HTTP data types supported by the WebAccelerator system for regular expression strings are defined in the Table 4.5.
HTTP data type host Definition The value set for the HTTP Host request header Example The WebAccelerator system matches the following HTTP Host request header: HOST: www.siterequest.com To the following string: www.siterequest.com path The value set for the path portion of the URI For the following URI: http://www.siterequest.com/apps/search.jsp? value=computer the WebAccelerator system matches the following string: /apps/search extension The value set for the extension portion of the URI For the following URI: http://www.siterequest.com/apps/search.jsp? value=computer the WebAccelerator system matches the following string: jsp query parameter The value set for the identified query parameter The WebAccelerator system matches the following value set for the action query parameter: http://www.siterequest.com?action=display& PDA to the following string: display

Table 4.5 Supported regular expression strings

Policy Management Guide for the BIG-IP WebAccelerator System

4 - 15

Chapter 4

HTTP data type unnamed query parameter

Definition The value set for the identified query parameter

Example If the value set for the unnamed query parameter in ordinal 2 is as follows: http://www.siterequest.com?action=display& PDA the WebAccelerator system matches the following string: PDA

path segment

The name of the segment key, or the value set for the segment parameter, depending on what you have identified for the match

If you identify the path segment in ordinal 1 for the full path (counted from left-to-right) and parameter ordinal 0, that means that in the following URL you have identified the segment key: http://www.siterequest.com/apps;AAY34/sear ch.jsp?value=computer the WebAccelerator system matches the following string: apps If you specify parameter ordinal 1, the WebAccelerator system matches to: AAY34

cookie

The value set for the identified cookie

For the following cookie: COOKIE: SESSIONID=TN2MM1QQL The WebAccelerator system matches the following string: TN2MM1QQL

user agent

The value set for the HTTP USER_AGENT request header

For the following user agent: USER_AGENT: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) the WebAccelerator system matches the following string: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)

referrer

The value set for the HTTP REFERER request header

For the following referrer: REFERER: http://www.siterequest.com?action=display the WebAccelerator system matches the following string: http://www.siterequest.com?action=display

header

The value set for the identified header

For the following header: Accept-Encoding: gzip the WebAccelerator system matches the following string: gzip

Table 4.5 Supported regular expression strings

4 - 16

Using HTTP Headers to Configure Acceleration Policy Rules

Supported meta characters


The WebAccelerator system uses the meta characters defined in the following table for pattern matching. As long as you use the escape character, you can use one of these meta characters as a literal value for fields that expect a regular expression.
Meta Character . ^

Definition Matches any single character. Matches the beginning of the line in a regular expression. Note that the WebAccelerator system assumes that the beginning and end of line meta characters exist for every regular expression it sees.

Example

Matches the end of the line. Note that the WebAccelerator system assumes that the beginning and end of line meta characters exist for every regular expression it sees.

For example, the expression G.*P.* matches the following: GrandPlan GreenPeace GParse GP You can begin a pattern with the * character, which is the same as using: .* For example, the WebAccelerator system views the following two expressions as identical. *Plan .*Plan

Matches zero or more of the patterns that precede it.

Matches one or more of the patterns that precede it.

For example, the expression G.+P.* matches the following: GrandPlan GreenPeace Do not begin a pattern with the + character. For example, do not use +Plan Instead, use the following: .+Plan

Matches none, or one of the patterns that precede it.

For example, the expression G.?P.* matches the following: GParse GP Do not begin a pattern with the ? character. For example, do not use ?Plan Instead, use the following: .?Plan

Table 4.6 Patterns and symbols to use for pattern matching

Policy Management Guide for the BIG-IP WebAccelerator System

4 - 17

Chapter 4

Meta Character [...]

Definition Matches a set of characters. You can list the characters in the set using a string made of the characters to match.

Example For example, the expression C[AHR] matches the following: CAT CHARISMA CRY You can also provide a range of characters using a dash. For example, the expression AA[0-9]+ matches the following: AA269812209 AA2 However, it does not match AAB2. To match any alphanumeric character, both upper- and lower-case, use the following expression: [a-zA-Z0-9]

[^...]

Matches any character not in the set. Just as with the character, [...], you can specify the individual characters, or a range of characters by using a dash (-).

For example, the expression C[^AHR].* matches the following: CLEAR CORY CURRENT But does not match: CAT CHARISMA CRY

(...)

Matches the regular expression contained inside the parenthesis, as a group.

For example, the expression AA(12)+CV matches the following: AA12CV AA121212CV

exp1 exp2

Matches either exp1 or exp2, where exp1 and exp2 are regular expressions.

For example, the expression AA([de]12|[zy]13)CV matches the following: AAd12CV AAe12CV AAz12CV AAy13CV

Table 4.6 Patterns and symbols to use for pattern matching

4 - 18

Using HTTP Headers to Configure Acceleration Policy Rules

Managing Cache-Control response headers


The HTTP Cache-Control version 1.1 header specification identifies general-header field directives for all caching mechanisms along the request/response chain, and is used to prevent caching behavior from adversely interfering with the request or the response. (For additional information, see sections 13 and 14 of the HTTP/1.1 specification at http://www.w3.org/Protocols/rfc2616/rfc2616.html.) Directives can appear in response or request headers, and certain directives can appear in either type of header. The HTTP Cache-Control general-header field directives typically override any default caching algorithms. The origin web servers cache response directives are organized in two groups: no-cache and max-age.

Honoring HTTP request and response header no-cache directives


By default, the majority of the WebAccelerator systems acceleration policies are configured to cache responses and ignore the following HTTP Cache-Control headers no-cache directives. Pragma: no-cache Cache-Control: no-cache Cache-Control: no-store Cache-Control: private You can configure the WebAccelerator system to honor no-cache directives. However, doing so may result in a noticeable increase in the traffic sent to the origin web server, depending on how many users send no-cache directives in requests.

To honor no-cache directives


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to edit. 3. On the Policy Tree, click the node you want to modify. 4. From the Matching Rules list, choose Acceleration Rules. 5. Click Lifetime.

Policy Management Guide for the BIG-IP WebAccelerator System

4 - 19

Chapter 4

6. In the Header Lifetime Options area: a) Clear the Ignore no-cache HTTP headers in request check box. b) Clear the Ignore no-cache HTTP headers in response check box. 7. Click Save.

Important

For images and documents that use the origin web servers Cache-Control: Private directive (such as Microsoft SharePoint and Microsoft Outlook Web Access), the Ignore no-cache HTTP headers in response check box is clear by default to ensure privacy. If you select the Ignore no-cache HTTP headers in response check box for items that use the origin web server Cache-Control: Private directive, privacy could be compromised. 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.

4 - 20

Using HTTP Headers to Configure Acceleration Policy Rules

Using max-age value for compiled responses


The WebAccelerator system uses the HTTP Cache-Control headers max-age directives defined in Table 4.7 (in order of priority) to determine the TTL values for compiled responses. For example, if the TTL values for the s-maxage and the max-age directives are different, the WebAccelerator system uses the TTL value for the s-maxage directive.
Priority 1 Directive Cache-Control: s-maxage Description The WebAccelerator system bases the TTL on the current time, plus the value specified for the HTTP Cache-Control headers s-maxage directive. Values for this directive are expressed in seconds The WebAccelerator system bases the TTL on the current time, plus the value specified for the HTTP Cache-Control headers max-age directive. Values for this directive are expressed in seconds The WebAccelerator system uses the TTL provided for HTTP Cache-Control headers entity-header field. Values for this field are expressed in Coordinated Universal Time (UTC time). To avoid caching issues, the WebAccelerator system must be properly synchronized with the origin web server. For this reason, F5 Networks recommends that you configure a Network Time Protocol (NTP) server. For information about configuring an NTP server, see the Configuration and Maintenance Tasks chapter in the Configuration Guide for the BIG-IP WebAccelerator System 4 Last-Modified The WebAccelerator system bases this TTL using the following formula: TTL = curr_time + ( curr_time - last_mod_ time ) * last_mod_factor Where: curr_time is the time that the response is received by the WebAccelerator system last_mod_ time is the time specified by this directive last_mod_factor is a percentage value used to weight the TTL you set it with a lifetime rule

Cache-Control: max-age

Expires

Table 4.7 HTTP Cache-Control headers max age directives

Important

The HTTP Cache-Control headers max-age directive is not the same as a lifetime rules Maximum Age for WebAccelerator system Cache Settings. The max-age directive defines a TTL for content. The lifetime rules Maximum Age setting is a boundary beyond which, for example, the max-age directive cannot surpass. For more information about lifetime rule parameters, see Configuring an example lifetime rule, on page 9-9.

Policy Management Guide for the BIG-IP WebAccelerator System

4 - 21

Chapter 4

Using ESI Surrogate-Control headers


Edge Side Includes (ESI) is a simple markup language that supports web surrogates, such as the WebAccelerator system, and is used to define web page components for dynamic assembly and delivery of web applications. For those sites that use ESI for page assembly, you can use ESI Surrogate-Control headers to manage the WebAccelerator systems behavior. When the WebAccelerator system receives an HTTP request that it cannot service from cache, it adds an ESI Surrogate-Capabilities header to the HTTP request and then sends it to the origin server for content. The Surrogate-Capabilities header specifies wa as the device token used by the WebAccelerator system, and identifies the WebAccelerator system as an ESI 1.0 compliant device, as follows: Surrogate-Capabilities: wa=ESI/1.0
Note

See Using surrogate targeting, on page 4-24, for information about specifying a device token. The response that the origin web server returns must contain an ESI Surrogate-Control response header if there is any ESI markup in the response. The ESI specification that defines the Surrogate-Control response header is available at http://www.esi.org/architecture_spec_1-0.html site.

Supported Surrogate-Control directives


Origin web servers use Surrogate-Control response header control directives to dictate how web surrogates manage content processing and caching for response entities. The WebAccelerator system supports the following Surrogate-Control response header control directives: Content No-store Max-age If the ESI Surrogate-Control header contains more than one of these directives, they must be separated by a comma (,). The WebAccelerator system ignores any unsupported directives defined in the ESI Surrogate-Control response header.

4 - 22

Using HTTP Headers to Configure Acceleration Policy Rules

Content directive
The WebAccelerator system requires that the origin server include an ESI Surrogate-Control response headers content directive (always specified as a name=value pair) in an HTTP response, if it contains ESI markup. At a minimum, a content directive header must have the following value: Surrogate-Control: content="ESI/1.0" If the response does not include an ESI Surrogate-Control response header, the WebAccelerator system ignores any ESI markup that appears in the response. When the origin web server response includes an ESI Surrogate-Control response header, content assembly is always performed on the object, whether or not the Enable Content Assembly on Proxies check box is selected, as described in Using content compression, on page 7-8.

no-store directive
The Surrogate-Control response headers no-store directive is always specified as the string no-store. For example: Surrogate-Control: content="ESI/1.0",no-store If the response includes an ESI Surrogate-Control header with the no-store directive, the WebAccelerator system does not cache the response.

max-age directive
Expressed in seconds, the Surrogate-Control response headers max-age directive specifies how long to cache content. For example, max-age=3600 indicates that the content should be cached for 1 hour. The WebAccelerator system uses this value as the compiled responses TTL value. You can also define a stand-in period, expressed with a + operator. For example, max-age=1800+600 indicates that the content should be cached for 30 minutes with a 10 minute stand-in interval. For more information, see Configuring an example lifetime rule, on page 9-9.
Important

The ESI Surrogate-Control headers max-age directive is not the same as the Maximum Age setting for the lifetime rules WebAccelerator system Cache Settings. You use the ESI Surrogate-Control headers max-age directive to define an actual TTL for content. The lifetime rules Maximum Age setting is a boundary condition beyond which, for example, the ESI Surrogate-Control headers max-age directive cannot pass. For more information about lifetime rule parameters, see Configuring an example lifetime rule, on page 9-9.

Policy Management Guide for the BIG-IP WebAccelerator System

4 - 23

Chapter 4

Overriding HTTP Cache-Control headers


If ESI Surrogate-Control headers appear in an HTTP response from the origin server, the WebAccelerator system ignores any existing HTTP 1.1 Cache-Control headers that appear in the same response. For example, if a response includes a Surrogate-Control response headers max-age directive and an HTTP 1.1 no-cache or no-store header, the WebAccelerator system caches the response. The HTTP 1.1 Cache-Control headers supported by the WebAccelerator system are described in Configuring the WebAccelerator Cache Settings, on page 9-5. The exception to this rule is that you can use a lifetime rule to direct the WebAccelerator system to ignore the Surrogate-Control response ESI headers max-age directive. For information about configuring lifetime rules, see Overview of lifetime rules, on page 9-1.

Using surrogate targeting


Surrogate targeting is an ESI mechanism that allows you to control a specific surrogate device. This mechanism is required, because a site can contain multiple web surrogates. You can use surrogate targeting to identify header information that is meant for the WebAccelerator system, by adding a parameter to the Surrogate-Control directive. This allows an origin server to specify one directive value for the WebAccelerator system, for example, and a different value for all other surrogates. The origin server appends the parameter to the directive using a semicolon (;). A comma (,) separates the parameter from any other directives that follow. For example: Surrogate-Control: max-age=3600+600;wa,max-age=3600 This example is parsed as follows: max-age=3600+600;wa Resulting in a max-age of 30 minutes with a 10 minute stand-in interval for the WebAccelerator system. max-age=3600 Resulting in a max-age of 30 minutes for all other devices. The device token in this example is wa. The wa device token was defined to the origin web servers in the Surrogate-Capability request header that the WebAccelerator system added to the request before it sent the request to the origin web servers. The WebAccelerator system always uses a device token of wa in the Surrogate-Capability header.

4 - 24

Using HTTP Headers to Configure Acceleration Policy Rules

Viewing X-PvInfo response headers


Before sending a response to a client, the WebAccelerator system inserts an X-PvInfo response header that includes specific codes, which describe the properties and history of the object. The X-PvInfo response header is for informational purposes only and provides a way for you to assess the effectiveness of your acceleration policy rules. Following is an example of an X-PvInfo header:
X-PvInfo: [S10101.C5025.PL.A15957.RA0.G3F6B.U896F2B1E].[OT/msword.OG/documents]

The code is divided into fields by the period ( . ) delimiter. Each field begins with a letter code, followed by one or more letters or numbers. The object type and group under which the response is classified are also included in the X-PvInfo response header. The object type is preceded by OT and the group is preceded by OG, as in the following example:
[OT/msword.OG/documents]

You define object types and groups from the Object Types screen, and the WebAccelerator system stores the information in its global fragment file, config/wa/globalfragment.xml. The object type for the response indicates if the WebAccelerator system overrode the rewrite or compression settings in the assembly rule for the node specified by the A code. (See also, A code, on page 4-28.)
Note

For more information about how the WebAccelerator system classifies objects, see Classifying responses, on page 4-12. For information about adding or modifying object type settings and specifying groups, see the Changing Default Settings chapter in the Configuration Guide for the BIG-IP WebAccelerator System. You can view X-PvInfo response headers by: Performing a packet capture of the page Using an HTTP viewer utility like HttpWatch, HTTP Analyzer, or Live Headers Using the WebAccelerator systems hit log For more information about the hit logs, see Chapter 12, Specifying Log Formats for Hit Logs.

Policy Management Guide for the BIG-IP WebAccelerator System

4 - 25

Chapter 4

S code
The S code is the first field of the X-PvInfo response header. This field code indicates whether the object in the HTTP response was served from the WebAccelerator systems cache, or was sent to the original web server for content. The S codes are defined in Table 4.8.
Code SO Definition Response was served from an unknown source. Description Indicates that the WebAccelerator system was unable to determine if a response was served from cache or sent to the origin web server for content. This indicates that the response was served from memory.

S10101

Response was served from Smart Cache (memory). Response was served from Smart Cache (disk).

S10102

Indicates that the response was served from disk because it required specific assembly processing by the WebAccelerator system, in accordance to an acceleration policy. When the WebAccelerator system receives a request for new content, is sends the request to the origin web server and caches the content before responding to the request. Future requests for this content are served from cache. When the WebAccelerator system receives a request for cached content that exceeds a lifetime rules Maximum Age setting, it revalidates the content with the origin web server. After revalidating the content, the WebAccelerator system serves requests from cache, until the Maximum Age setting is once again exceeded. When the WebAccelerator system matches a request to a node with a proxying rule set to Always proxy requests for this node, the WebAccelerator system sends that request to the origin web server, rather than serving content from cache. If the WebAccelerator system receives a request that contains an HTTP no-cache directive, the WebAccelerator system sends the request to the origin server and does not cache the response. In addition, the WebAccelerator system does not currently support some vendor-specific HTTP methods (such as OPTIONS) and some web services methods (such as SOAP). The WebAccelerator system sends requests containing those methods to the origin web server for content. You can perform a cache invalidation manually, through direct XML messaging over HTTPS on port 8443, or with an acceleration rule setting. After the WebAccelerator system invalidates cache and retrieves new content from the origin web server, it stores the response and serves future requests from cache.

S10201

Response was served from the origin web server, because the request was for new content.

S10202

Response was served from the origin web server, because the cached content had expired.

S10203

Response was served from the origin web server, as dictated by an acceleration policy rule.

S10204

Response was served from the origin web server, because of specific HTTP or web service methods.

S10205

Response was served from the origin web server because the cached content was invalidated.

Table 4.8 S code definitions

4 - 26

Using HTTP Headers to Configure Acceleration Policy Rules

Code S10206

Definition Response was served from the origin web server, because the content cannot be cached.

Description If a response cannot be cached, for example, because the content is private or the header is marked as no-store, the WebAccelerator system includes this code in the response to the client. If an acceleration rule prompts the WebAccelerator system to expire content, it sends the next request to the origin web server. If the origin web server indicates that the cached content has not changed, the WebAccelerator system includes this code in the response to the client. Large multimedia objects often cannot be optimized because they are typically composed of files that are already compressed and too large to cache. You can create a proxying rule to recognize requests for these types of objects and prompt the WebAccelerator system to send those requests directly to the origin web server for content. Further, you can specify a responses-cached rule directing the WebAccelerator system to not cache that content. When a request includes an Expect: 100-continue header, that request and its response bypass the WebAccelerator system, which responds with an X-PvInfo header that includes an S10413 field code. When a response exceeds the size specified in the WebAccelerator system's pvsystem.conf file for the maxResponseDataSize parameter, the WebAccelerator system does not match and apply an acceleration policy to the response. By default, this value is 64MB.

S10232

Response was served from the WebAccelerator system's Smart Cache, because the expired content is still valid.

S10301

Response was served from the origin web server, because the response contained large multimedia objects.

S10413

Response bypassed the WebAccelerator system.

S10414

Request and response bypassed the WebAccelerator system.

When the WebAccelerator system's license has expired, it does not match and apply acceleration policies to requests or responses. This response was served from memory without requiring specific assembly processing by the WebAccelerator system. This is the most efficient and fastest response method.

S11101

Response was served from Hot Cache.

Table 4.8 S code definitions

C code
The C code is the second field of the X-PvInfo response header, and it indicates the acceleration policy that the WebAccelerator system applied to the request. The C code is also part of the path where cached objects are stored on disk, and also identifies the specific application used. For example, if you have two applications defined in an acceleration policy, the WebAccelerator system saves cached content for the first application under parent directory 1, and cached content for the second application under parent directory 2.

Policy Management Guide for the BIG-IP WebAccelerator System

4 - 27

Chapter 4

A code
The A code is the third field of the X-PvInfo response header, and identifies to which node on the Policy Tree the WebAccelerator system matched the request. This helps you determine which acceleration rules the WebAccelerator system applied to the request.

To view a nodes ID in an acceleration policy


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy for which you want to view the nodes ID. 3. Place your cursor on a node. The ID appears in parentheses below the cursor and above the Policy Tree function toolbar.

R code
The R code is the fourth field of the X-PvInfo response header, and it identifies the application match of a response to an acceleration policy. The WebAccelerator system can perform response-based application matching against MIME types in a response, or by matching attachment file name extensions. Request-based application matching against extensions (defined in the globalfragment.xml file) in the URL path is not considered a response application match; however, a request application match appears in the A field. In addition, you can configure an assembly rule to specify custom rewrites that redirect one application match to another application match in an acceleration policy. This is most often used to handle exceptions to a general application match rule. For more information about configuring assembly rules, see Chapter 7, Configuring Assembly Rules. A 0 (zero) R code in the X-PvInfo response header indicates that the WebAccelerator system did not use response-based application matching.

G code
The G code is the fifth field of the X-PvInfo response header. The G code, when converted from hexadecimal to decimal, identifies where cached objects are stored on disk. The value of the G code is called the Application Sign number. The Application Sign changes when you make edits to an acceleration policy (generally to variation rules) that result in a substantial change in the way the WebAccelerator system manages a request, making it difficult to revalidate existing cached objects. Moving Application Sign changes to a new cache subdirectory is similar to wiping the disk cache, except that disk space is not freed and must be reclaimed using the hds_prune process.

4 - 28

Using HTTP Headers to Configure Acceleration Policy Rules

U code
The U code is the sixth field of the X-PvInfo response header and is a hexadecimal cache ID number. The U code identifies where cached objects are stored on disk.

Policy Management Guide for the BIG-IP WebAccelerator System

4 - 29

Chapter 4

4 - 30

5
Configuring Matching Rules

Overview of application matching Configuring an example matching rule

Configuring Matching Rules

Overview of application matching


The WebAccelerator system uses matching rules to classify a request or response and generate an object type. For requests, the classification is based on the file extension present in the request. For example, a matching rule might specify that the WebAccelerator system place all requests with a .gif extension into a group for images. Once the WebAccelerator system classifies a request or response by object type, it performs application matching which consists of: Generating a content type by appending the object type to the group to which the object type belongs Processing the request based on the acceleration policy associated with the node to which it matched For an HTTP request or response to match to a specific leaf node, it must match all the matching rules defined for the leaf node. Once you create the matching rules for an acceleration policy, you can configure the various acceleration rules to handle requests. For example, for images files you might have a matching rule based on common image extensions found in HTTP requests. In this case, an Image leaf node on the Policy Tree with a matching rule for requests that contain an extension of gif, GIF, jpg, JPG, jpeg, or JPEG. When the WebAccelerator system matches a request to the Image node, it applies the associated acceleration rules to manage image files for your site. You configure matching rules from the matching rule screen.

To access the a matching rule screen


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to edit. 3. Click the node for which you want to create a matching rule. 4. From the Add Parameter list, select a parameter, and then click the Add button. 5. Add the parameter options as required. 6. 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.

Policy Management Guide for the BIG-IP WebAccelerator System

5-1

Chapter 5

Application matching based on node precedence


When performing application matching, the WebAccelerator system uses the following priority, and selects: The most specific match, over a more general match A superset over a subset The priority of the leaf node on the Policy Tree For example, if two leaf nodes are defined as follows:

Leaf node 1 Contains matching rules based on three query parameters. Leaf node 2 Contains matching rules based on two of the same three query parameters as Leaf node 1.

A request that matches all three query parameters is considered a match. However, the WebAccelerator system matches the request to Leaf node 1, because that node is a superset and is the best match. Conversely, if you have two leaf nodes defined as follows:

Leaf node 1 Contains three matching rules based on three query parameters. Leaf node 2 Contains two matching rules based on two query parameters.

Then query is considered ambiguous, because the matching rules do not dictate that one leaf node is a better match than another node. For ambiguous queries, the WebAccelerator system chooses between the leaf nodes based on their priority on the Policy Tree. For more information about ambiguous parameters, see Managing conflicting rule parameters, on page 6-5. For information about how to modify leaf node priority, see To change the priority of a node on the Policy Tree, on page 3-12.

Additional application matching considerations


In addition to precedence, the WebAccelerator system attempts to match first to the following two HTTP request data type parameters, when performing application matching: Path HTTP request data type parameter Extension HTTP request data type parameter Matching rules based on the path parameter have first priority over all other parameter matches and the WebAccelerator system always chooses an exact path match before other path matches. An exact path match is one where the value set for the path parameter includes the question mark. For example, if you have a rule with the following path parameter value:
5-2

Configuring Matching Rules

apps/srch.jsp? the WebAccelerator system considers the following request an exact match, and matches the request to the leaf node to which the rule belongs. http://www.siterequest.com/apps/srch.jsp?value=computers It is important to note that a path of / and /? are two different things. A path that includes a ? indicates that an exact match is required. By default, a path that you provide for a policy is a prefix. For example, if you give a parameter the path, /a/b, the WebAccelerator system considers both of the following requests a match: http://www.siterequest.com/a/b?treat=bone http://www.siterequest.com/a/b/c?toy=ball If you add a question mark to the parameter so that it is, /a/b?, the WebAccelerator system considers only the following a match, because the question mark indicates that an exact match is required. http://www.siterequest.com/a/b?treat=bone Matching rules based on the extension parameter have the second priority over other parameter matches. If the extension on a request matches the extension parameter specified by a matching rule, the WebAccelerator system matches the request to the leaf node to which the rule belongs.

Processing unmatched requests


If a request does not match a leaf node on the Policy Tree, the WebAccelerator system either uses a predefined accelerator policy that manages unmatched requests and responses, or sends the request to the origin web server for content. It is important to keep in mind that for the WebAccelerator system to consider a request a match, the request must match all the matching rules configured for a leaf node. If a request matches all the rules for a leaf node, except for one, the WebAccelerator system does not consider it a match, and processes it as an unmapped request.

Policy Management Guide for the BIG-IP WebAccelerator System

5-3

Chapter 5

Configuring an example matching rule


This section of the chapter provides information about how to configure an example matching 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.

You configure matching rules for this example Policy Tree, as described in Table 5.1.
Node Home Application matching parameter Create a rule based on the Path data type. Provide the following two two values for the Path parameter: /index.jsp /? Default Create a rule based on the Path data type. Provide the following value for the Path parameter: /apps Search Create a rule based on the Path data type. Provide the following value for the Path parameter: /srch Images Create a rule based on the Path data type. Provide the following value for the Path parameter: /images

Table 5.1 Application matching rules example configuration

To create the example matching rule


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the example acceleration policy to edit.

5-4

Configuring Matching Rules

3. On the Policy Tree, click a node to configure the parameter. 4. From the Add Parameter list, select Path, and click the Add button. 5. In the Value(s) box, type the values for each node, as specified in Table 5.1, on page 5-4. 6. 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.

Policy Management Guide for the BIG-IP WebAccelerator System

5-5

Chapter 5

5-6

6
Configuring Variation Rules

Overview of variation rules Defining variation rule parameters Managing conflicting rule parameters Configuring an example variation rule

Configuring Variation Rules

Overview of variation rules


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 its 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. You configure variation rules from the variation rule screen.

To access the variation rule screen


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to edit. 3. Click the Applications node. 4. From the Matching Rules list, choose Acceleration Rules. 5. Click Variation. 6. Click the node you want to modify.

Policy Management Guide for the BIG-IP WebAccelerator System

6-1

Chapter 6

7. Modify the options as required. 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.

Using variation rules to increase cache efficiency


By default, the WebAccelerator system includes the following HTTP request parameters in the UCI: Host Query Parameter Unnamed Query Parameter Path Segment Protocol 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.

Using variation rules to serve user-specific content


By default, the WebAccelerator system does not include the following HTTP request elements in the UCI: Method Cookie User Agent Referrer Header Client IP You must create a variation rule if the content you want to serve is dependent one of these elements. That is, configure a variation rule if you want to serve different content based on:

6-2

Configuring Variation Rules

The method that a request uses The state of a cookie contained in a request The connecting clients IP address 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.

Policy Management Guide for the BIG-IP WebAccelerator System

6-3

Chapter 6

Defining variation rule parameters


When you define a variation rule, you specify one of the following behaviors for a parameter:

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 under which 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.

Using value groups


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.

6-4

Configuring Variation Rules

Managing conflicting rule parameters


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 6.1.
Parameter All other query parameters Unnamed query parameter in ordinal 1 Value Match All values All values Content to Serve different content same content

Table 6.1 Example of conflicting query parameters

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 An unnamed query parameter in ordinal 1, for which the value is set to computer 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.

To treat ambiguous query parameters as unnamed


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to edit. 3. On the Policy Tree, click the node that you want to modify. 4. From the Matching Rules list, choose Acceleration Rules. 5. Click Variation.

Policy Management Guide for the BIG-IP WebAccelerator System

6-5

Chapter 6

6. Click All Other Query Parameters. 7. Select the Treat ambiguous query parameters as unnamed check box. 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.

6-6

Configuring Variation Rules

Configuring an example variation rule


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.

This site also has the following two considerations: 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. For this example, you create the following two variation rules: 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.

To create the example REFERRER rule


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to edit. 3. Click the Applications node. 4. From the Matching Rules list, choose Acceleration Rules. 5. Click Variation. 6. Click Referrer.
Policy Management Guide for the BIG-IP WebAccelerator System 6-7

Chapter 6

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: http://www\.siterequest\.com.* Note: For more information about regular expressions, see Using regular expressions and meta tags for rules, on page 4-15. 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.

To create the example Query Parameter rule


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to edit. 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.

6-8

7
Configuring Assembly Rules

Overview of assembly rules Using the Intelligent Browser Referencing feature Using the MultiConnect feature Using content compression Managing content served from origin web servers Using parameter value substitution Specifying advanced assembly options Configuring an example assembly rule

Configuring Assembly Rules

Overview of assembly rules


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: Assembly rules that identify: The content assembly features to apply, such as Intelligent Browser Referencing and MultiConnect 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. You configure assembly rules from the assembly screen.

To access the assembly screen


1. In the navigation pane, expand WebAccelerator and click Policies. 2. Click the name of the acceleration policy that you want to edit. 3. Click the node for which you want to set the Enable Intelligent Browser Referencing feature. 4. From the Matching Rules list, choose Acceleration Rules. 5. Click Assembly. 6. Modify the assembly rules as required. 7. 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.

Policy Management Guide for the BIG-IP WebAccelerator System

7-1

Chapter 7

Using the Intelligent Browser Referencing feature


When an origin web server sends a response, the clients browser stores the response in its local cache. If the object has no expiration time, the browser makes subsequent requests for that content using a conditional GET request in 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 it is 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. For example, if your site has several images for each page, clients may perceive a slow response time because of the large number of conditional GET requests for the image objects. You can increase the efficiency of the clients web browsers local cache and improve perceived access to your site by enabling the Intelligent Browser Referencing feature, which reduces or eliminates requests to your site for relatively static content, such as images and style sheet (CSS) files. When enabled, the Intelligent Browser Referencing feature prompts the WebAccelerator system to manage the web browsers cache in two ways: 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. By 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. The WebAccelerator system applies the Intelligent Browser Referencing feature only to: Image tags For example: <img src="..."> Script tags For example: <script src="..."> Link tags For example: <link href="..."> Frame tags For example: <frame src="..."> Forms, for which the input type is an image For example: <form><input type="mage" src="...."></form>

7-2

Configuring Assembly Rules

Enabling the Intelligent Browser Referencing feature


For the WebAccelerator system to apply the Intelligent Browser Referencing feature, the following conditions must met for the link: There are no variation rules defined. 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. There are no proxying rules defined.
Note

When an object is matched to a rule in which the Intelligent Browser Referencing feature is enabled, the WebAccelerator system ignores the client cache minimum age settings for that object. However the HTML page, into which those objects are loaded, honors all client cache minimum age settings. For more information about client age settings, see Configuring an example lifetime rule, on page 9-9.

To enable the Intelligent Browser Referencing feature


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to edit. 3. Click the node for which you want to set the Enable Intelligent Browser Referencing feature. 4. From the Matching Rules list, choose Acceleration Rules. 5. Click Assembly. 6. Select the Enable Intelligent Browser Referencing check box. 7. Click the Save button.

Important

If you set the Enable the Intelligent Browser Referencing feature, you must also set the assembly rules Enable Content Assembly on Proxies feature, as described in Using content compression, on page 7-8.

Policy Management Guide for the BIG-IP WebAccelerator System

7-3

Chapter 7

Intelligent Browser Referencing example


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>

When the Intelligent Browser Referencing feature is enabled, the WebAccelerator system modifies the page as follows:
<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, 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 client browser conducts subsequent requests for the page by: Performing a conditional GET request 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 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.

7-4

Configuring Assembly Rules

Using the MultiConnect feature


Most web browsers create a limited number of persistent TCP connections when requesting data, which restricts the amount of content a client can receive at one time. You can provide faster data downloads to your clients using the WebAccelerator systems MultiConnect feature. When enabled, the MultiConnect feature 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). The origin web servers never get a request from these additional subdomains; they are used exclusively on embedded URLs or links that request images or scripts and 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 removes the subdomain prefixes before sending the request. The WebAccelerator system uses the MultiConnect feature only on 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>

Enabling the MultiConnect feature


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 to your site. Before you enable the MultiConnect feature, you must first perform the following tasks: Configure DNS with entries for the additional subdomains. Map the additional DNS entries to the same IP address as the base origin web server (for example, www.siterequest.com). 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 enable it. For information about these required tasks, see the Configuration and Maintenance Tasks chapter in the Configuration Guide for the BIG-IP WebAccelerator System.
Policy Management Guide for the BIG-IP WebAccelerator System 7-5

Chapter 7

To enable the MultiConnect feature


Important

Some client browsers close HTTPS connections to one domain before opening HTTPS connections to a new one. This type of browser behavior can decrease the speed of access to applications when MultiConnect is enabled; therefore, F5 Networks recommends that you do not enable MultiConnect for HTTPS connections for those client browsers. If you are using MultiConnect with HTTPS, you must construct a trusted SSL certificate that lists the additional subdomains that you created as Subject Alternative Name entries. (This is not necessary for use with only HTTP.) 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 displays a list of existing acceleration policies. 2. Click the acceleration policy that you want to edit. 3. On the Policy Tree, click the node for which you want to enable the MultiConnect feature. 4. From the Matching Rules list, choose Acceleration Rules. 5. Click Assembly. 6. Select the Enable MultiConnect check box. 7. Click the Save button. 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: wa1.www.siterequest.com wa2.www.siterequest.com

MultiConnect example
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>

7-6

Configuring Assembly Rules

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> </html>

Policy Management Guide for the BIG-IP WebAccelerator System

7-7

Chapter 7

Using content compression


You can decrease the size of the data that the WebAccelerator system serves by enabling content compression. This lowers your sites bandwidth costs and can improve the perceived performance of your site. When you enable content compression you identify content that you want the WebAccelerator system to compress, using gzip-encoding, when the following criteria are met: The objects Enable Compression setting (configured on the Object Types screen) is configured as Policy Controlled. The Enable Content Compression setting is set on the node for the assembly rule to which the request and response are matched. The client can accept gzip-encoded content. The Enable Content Assembly on Proxies feature is enabled.
Note

By default, the Enable Compression setting is 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.

Enabling content compression


To enable the Content Compression feature
1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the acceleration policy that you want to edit. 3. On the Policy Tree, click the node for which you want to enable the content compression feature. 4. From the Matching Rules list, choose Acceleration Rules. 5. On the Policy Editor menu bar, click Assembly. 6. Select the Enable Content Compression check box. Note: If the WebAccelerator system matches a request to an object type for which the Enable Compression setting is configured for Symmetric Deployment only or set to None, it overrides this Enable Content Compression setting. You can view individual object type settings from the Object Types screen. For more information about object type settings, see the Changing Default Settings chapter in the Configuration Guide for the BIG-IP WebAccelerator System 7. Click the Save button.

7-8

Configuring Assembly Rules

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.
Important

After you configure Enable Content Compression setting, you must configure the Enable Content Assembly on Proxies setting, as described in Managing content served from origin web servers, on page 7-10.

Policy Management Guide for the BIG-IP WebAccelerator System

7-9

Chapter 7

Managing content served from origin web servers


The primary purpose of the Enable Content Assembly on Proxies setting 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, you must always set the Enable Content Assembly on Proxies setting whenever you enable content compression or enable intelligent browser referencing. If you do not enable this feature, the WebAccelerator system does not modify responses that it receives from the origin web servers before it forwards the responses to the client.

Enabling content assembly on proxies feature


Note

If the response from the origin web servers contains ESI assembly instructions, the WebAccelerator system always applies assembly rules to the content, regardless of whether the content assembly on proxies setting is enabled.

To Enable Content Assembly on Proxies setting


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to edit. 3. On the Policy Tree, click the node you want to edit. 4. From the Matching Rules list, choose Acceleration Rules. 5. On the Policy Editor menu bar, click Assembly. 6. Select the Enable Content Assembly on Proxies check box. 7. 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.

7 - 10

Configuring Assembly Rules

Using parameter value substitution


Some requested pages include hyperlinks that require that specific information appear in the response. You can configure parameter value substitution so that when a query parameter contains identification information for a sites visitors, it prompts the WebAccelerator system to serve different content for the request, based on the specific visitor. Conversely, 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. For example, if the original request that generated the cached page contained the following URL:
http://www.siterequestsiterequest.com/apps/shopping.jsp? shopper=AAnb35vnM09&....

then the embedded URL in the cached page might be:


<ahref=http://www.siterequest.com/apps/shoppingCart.jsp? shopper=AAnb35vnM09&....>link</a>

For subsequent requests of the following page:


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

The WebAccelerator system still serves the cached page, which contains the following URL:
<a href=http://www.siterequest.com/apps/shoppingCart.jsp? shopper=AAnb35vnM09&....>link</a>

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. 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, when you define a 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>

Policy Management Guide for the BIG-IP WebAccelerator System

7 - 11

Chapter 7

Configuring value substitution parameters for an assembly rule


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.

Source definition
When you define a source definition, you specify the value that you want the WebAccelerator system to embed in the URL, in place of the cached (target) value. Typically, the source is a certain request element, such as a query parameter. However, you can define another source type, such as a random number, as described in Number randomizer, on page 7-13. When you define the source, you identify the parameter by data type and name or location in the request. 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:
siterequesthttp://www.siterequest.com/apps/something.jsp?entity =orange

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%2 F%2Fwww.siterequest.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. 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.

7 - 12

Configuring Assembly Rules

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

then 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

If the source you specify for the substitution does not appear on the request, the WebAccelerator system removes the parameter in its entirety from the qualifying embedded URLs. In the previous example, if a subsequent request were simply:
http://www.siterequest.com/apps/shopping.jsp

then embedded URLs served to the requestor are:


<a href=http://www.siterequest.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.

Number randomizer
When configured, the assembly rules number randomizer setting generates a random number and places it in a targeted location in the embedded URL. When the WebAccelerator system compiles 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.siterequest.com/getAd?entity=45&...> </iframe>

Policy Management Guide for the BIG-IP WebAccelerator System

7 - 13

Chapter 7

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:
<iframe src=http://www.siterequest.com/getAd?entity=45&...> </iframe> <iframe src=http://www.siterequest.com/getAd?entity=11&...> </iframe> <iframe src=http://www.siterequest.com/getAd?entity=87&...> </iframe>

Important

If ESI markup conflicts with any configured parameter value substitution, the WebAccelerator system ignores the parameter value substitution (including random value substitution).

7 - 14

Configuring Assembly Rules

Specifying advanced assembly options


You can fine-tune how the WebAccelerator system manages certain types of traffic, without changing the settings for all of your traffic, by specifying an advanced assembly string at the node level. Once configured, the WebAccelerator system uses the configured settings for 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. The advanced assembly strings are defined in Table 7.1.
Valid Strings followRedirects=true followRedirects=false Description 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 that matches to the node. The system-wide default is false. disableContentBasedIdentity=true disableContentBasedIdentity=false 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.

Table 7.1 Advanced assembly strings

Policy Management Guide for the BIG-IP WebAccelerator System

7 - 15

Chapter 7

To specify advanced assembly options


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to edit. 3. On the Policy Tree, click the node that you want to edit. 4. From the Matching Rules list, choose Acceleration Rules. 5. Click Assembly. 6. From the Content Assembly Options list box, select Advanced. 7. In the Advanced Assembly box, type the node string options as described in Table 7.1, on page 7-15. 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.

7 - 16

Configuring Assembly Rules

Configuring an example assembly rule


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. For this example, you should: 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 WebAccelerator System.

To configure the example assembly rule


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to edit. 3. On the Policy Tree, click the Home node.
Policy Management Guide for the BIG-IP WebAccelerator System 7 - 17

Chapter 7

4. From the Matching Rules list, choose Acceleration Rules. 5. Click Assembly. 6. In the Parameter Value Substitution area, click the Create button. 7. In the Source Definition area, from the Type list, select Query Parameter. 8. In the Name box, type sessionID. 9. In the Target Definition area, from the Type list, select Query Parameter. 10. In the Name box, type sessionID. 11. In the Target URLs section, select the All URLs option. 12. Click the Save button. 13. Verify that the Enable Content Compression box is selected. 14. Click the Save button. 15. On the Policy Tree, click the Applications node. 16. To add each additional node, repeat steps 7 - 12.

7 - 18

8
Configuring Proxying Rules

Overview of proxying rules Configuring example proxy rule parameters Enabling the Always proxy requests for this node setting Configuring an example proxy override rule Configuring an example proxying rule

Configuring Proxying Rules

Overview of proxying rules


In general, the WebAccelerator system attempts to service all HTTP requests from its cache. However, if you have certain types of content that you do not want the WebAccelerator system to service from its cache, you can configure proxying rules. Using proxying rules, you identify HTTP request elements that prompt the WebAccelerator system to send a request to your origin web servers for content. The proxying rule parameters consist of several components:

Proxying Options Which consist of the following directives: Always proxy When you select this option, the WebAccelerator system sends all requests that match the associated node to the origin web server for content. This option overrides any configured proxying rules. Configure and use Proxy Rules When you select this option, the WebAccelerator system applies configured proxy rules to requests that match the associated node. Note: When you use Configure and use Proxy Rules and disable the Enable Content Assembly on Proxies option, located on the Assembly tab, if the content in the WebAccelerator system cache is unexpired, the WebAccelerator system services from its cache and performs content assembly. If the WebAccelerator system cache is empty or the content is expired, the WebAccelerator system refreshes its cache, by sending the request to the origin web server for content, and does not perform content assembly. This response from the origin web server also includes ETags from the origin web server.

Proxy rules For this option, you can define specific parameters for proxying rules. In general, proxy rules options are only relevant to requests that match their node, rather than to matched responses. Proxy overrides rules For this option, you can define parameters and associated conditions under which the WebAccelerator system should ignore proxying rules options.

You configure proxying rules from the proxying screen.

To access the proxying screen


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to edit. 3. On the Policy Tree, click the node you want to edit. 4. From the Matching Rules list, choose Acceleration Rules. 5. Click Proxying.
Policy Management Guide for the BIG-IP WebAccelerator System 8-1

Chapter 8

6. Configure the proxying rules as required. 7. 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.

8-2

Configuring Proxying Rules

Configuring example proxy rule parameters


When defining parameters for proxy rules, you identify the parameter and its value that must appear in a request, for the WebAccelerator system to send it to the origin web server for content. That is, if you create a proxy rule based on a cookie named version, the WebAccelerator system sends the request to the origin server if one of the following conditions is true: The version cookie does not appear on the request. The version cookie appears on the request, but has no value set for it (version is empty).

To configure example proxy rule parameters


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to edit. 3. On the Policy Tree, click the node for which you want to define a proxy rules option. 4. From the Matching Rules list, choose Acceleration Rules. 5. Click Proxying. 6. Enable the Configure and use Proxy Rules for this node option. 7. In the Proxy Rules area, select Cookie from the Add Parameter list, and click the Add button. 8. In the Name box, type version. 9. From the Value(s) list, select Value does not match, and select the associated check box. 10. In the regular expression box, type version. 11. Select the Value is an empty string check box. 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.

Policy Management Guide for the BIG-IP WebAccelerator System

8-3

Chapter 8

Enabling the Always proxy requests for this node setting


When the WebAccelerator system matches a request to a node that has the Always proxy requests for this node setting enabled, it sends the request to the origin server, and responds to the request without caching the content. This option overrides any configured proxying rule, and is useful for specific content that is private.

To enable the Always proxy requests for this node setting


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to edit. 3. On the Policy Tree, click the node for which you want to enable the Always proxy requests for this node setting. 4. From the Matching Rules list, choose Acceleration Rules. The acceleration rules display on the Policy Editor menu bar. 5. On the Policy Editor menu bar, click Proxying. 6. In the Proxying Options area, click the button next to Always proxy requests for this node. 7. 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. Once you publish the acceleration policy, the WebAccelerator system sends all matched requests to the origin server for content.

8-4

Configuring Proxying Rules

Configuring an example proxy override rule


One common application for proxy override rules, is for sites that receive a high volume of traffic related to web crawlers and robots clients. You can avoid having your origin web server manage this excessive traffic by configuring a proxy override rule. It is especially important to consider a proxy override rule for this application if your proxy rules are based on a set cookie, because web crawlers and robots rarely present cookies in their requests. Before configuring the rule, you could examine the origin servers log files to see if the web crawler presents a specific a string that you can use for a proxy override rule. For example, the web crawler might present a string for the HTTP USER_AGENT request header that looks very much like the value presented for MSIE 5.0 browsers. However, the web crawler adds badcrawler to the HTTP USER_AGENT string. For this example, you use a proxy override rule for the nodes proxying rule, based on the user agent parameter to match the regular expression .*badcrawler.* When the WebAccelerator system finds the user agent with this regular expression in an HTTP request, it services the request from its cache, even if the matched proxying rule dictates that the WebAccelerator should send the request to the origin server.

To configure the example proxy override rule


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to edit. 3. On the Policy Tree, click the node for which you want to define a proxy rules option. 4. From the Matching Rules list, choose Acceleration Rules. 5. Click Proxying. 6. In the Proxy Override Rules area, select User Agent from the Add Parameter list, and click the Add button. 7. In the Value(s) area, select Values matches from the list and select the Values matches check box. 8. In the Value matches box, type the regular expression that matches the user agent value. For this example, type .*badcrawler.* 9. 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. Once you publish the acceleration policy, the WebAccelerator system attempts to service, from its cache, all requests that it receives with a HTTP USER_AGENT value that matches .*badcrawler.*, regardless of any proxy rules that the request matches.
Policy Management Guide for the BIG-IP WebAccelerator System 8-5

Chapter 8

Configuring an example proxying rule


This section of the chapter provides information about how to configure an example proxying rule. For this 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, you use a segment parameter to contain identifying information for your shopping cart application. Requests for your applications are all in the following form:
http://www.somesite.com/apps/doSomething.jsp;AAy23BV39

If the session tracking string does not appear in the segment parameter at the end of the URI, you want the WebAccelerator system to send the request to the origin web servers for special handling. Create a proxying rule for your Applications node with just one parameter based on the path segment data type. This rule should identify the subject as being: Path ordinal 1 in the full path, as counted from right to left Segment parameter ordinal 1
Note

See Path segment, on page 4-7, for information about path segments and their ordinals. You set this rule to go into effect if the parameter value is an empty string or if the parameter is absent from the request.

To configure the example proxying rule


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to edit. 3. On the Policy Tree, click the Applications node. 4. From the Matching Rules list, choose Acceleration Rules.

8-6

Configuring Proxying Rules

5. Click Proxying. 6. Click the Configure and use Proxy Rules for this node option. 7. In the Proxy Rules area, select Path Segment from the Add Parameter list, and click the Add button. 8. In the Alias box, type a meaningful name for the parameter. 9. In the Segment Ordinal box, type 1, and from the list, select Numbering Right-to-Left in the Full Path. 10. In the Parameter Ordinal box, type 1. 11. In the Value(s) area, select the following check boxes: Value is an empty string Parameter is absent from the request 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.

Policy Management Guide for the BIG-IP WebAccelerator System

8-7

Chapter 8

8-8

9
Configuring Lifetime Rules

Overview of lifetime rules Defining Header Lifetime Option settings Configuring the WebAccelerator Cache Settings Configuring the Client Cache Settings Configuring an example lifetime rule

Configuring Lifetime Rules

Overview of lifetime rules


The length of time that the WebAccelerator system keeps compiled content in its cache before refreshing it is called content lifetime. Content lifetime is expressed in the form of a time to live (TTL) value, and can vary for each cached response. When content is in cache longer than its TTL value, the WebAccelerator system considers the content expired. When the WebAccelerator system receives a request for expired content, it sends that request to the origin web servers for fresh content, replaces the expired cached content with the fresh response, and then responds to the request. Lifetime rules are not relevant to requests. The WebAccelerator system applies lifetime rules only to responses that it receives from the origin web server. You can define how the WebAccelerator system manages cached content for responses, through the following lifetime rule options.

Header Lifetime Options These options specify whether the WebAccelerator system honors the TTL values provided with the headers sent from the origin web server, and whether the WebAccelerator system should honor any existing no-cache directives. See Defining Header Lifetime Option settings, on page 9-3, for more information. WebAccelerator Cache Settings These settings specify how long the WebAccelerator system retains cached content, how long the WebAccelerator system serves cached content if the origin web server is not available, and when to expire cached content. See Configuring the WebAccelerator Cache Settings, on page 9-5, for more information. Client Cache Settings These settings specify whether the client browser should store content locally and if so, the maximum time the browser should store content. See Configuring the Client Cache Settings, on page 9-7, for more information.

These settings you configure apply to any HTTP response that matches to a leaf node for a specific acceleration policy, for which the option is set.

Understanding lifetime mechanism precedence


The options and parameters that the WebAccelerator system uses to manage caching are collectively called lifetime mechanisms. The WebAccelerator system uses the lifetime mechanisms to determine the TTL value for compiled responses. Because the WebAccelerator system manages cached responses by using the parameters for different lifetime mechanisms simultaneously, it obeys the following precedence if any of the lifetime mechanism parameters conflict.

Policy Management Guide for the BIG-IP WebAccelerator System

9-1

Chapter 9

If the Obey ESI max age if present setting is enabled, the TTL value indicated by the ESI Surrogate-Control headers max-age directive supersedes all other TTL values, provided that the ESI Surrogate-Control headers max-age directive does not violate the boundary conditions described in the previous bullet. The WebAccelerator system uses the HTTP lifetime headers only if the following two conditions are met: The Use HTTP lifetime headers if present setting is enabled An ESI Surrogate-Control headers max-age directive is not included in the header If the Use HTTP lifetime headers if present setting is not enabled, or if HTTP lifetime headers are not otherwise available in the response, then the WebAccelerator system uses the Maximum Age value specified in the WebAccelerator Cache Settings section of the lifetime rule.
Tip

Before you consider changing the WebAccelerator Cache Settings, determine whether using invalidations rules to invalidate specific content would be more appropriate for your application. For information about configuring invalidation rules, see Chapter 10, Configuring Invalidations Rules. You configure lifetime rules from the lifetime screen.

To access the lifetime screen


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. On the User-defined Acceleration Policies table, click the name of the acceleration policy that you want to edit. 3. Click the node you want to modify. 4. From the Matching Rules list, choose Acceleration Rules. The Example policy screen displays a list of variation rules. 5. Click Lifetime. The Lifetime screen displays available header lifetime options and cache settings. 6. Modify the lifetime rules as required. 7. Click the Save 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.

9-2

Configuring Lifetime Rules

Defining Header Lifetime Option settings


You can specify whether the WebAccelerator system honors certain parameters contained in HTTP headers. To do this, enable or disable the following options from the Header Lifetime Options area of the lifetime screen. Obey ESI max-age headers if present Use HTTP lifetime headers if present Ignore no-cache HTTP headers in the request Ignore no-cache HTTP headers in the response

To access Header Lifetime Option settings


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. On the User-defined Acceleration Policies table, click the name of the acceleration policy that you want to edit. 3. Click the node you want to modify. 4. From the Matching Rules list, choose Acceleration Rules. The Example policy screen displays a list of variation rules. 5. Click Lifetime. The Lifetime screen displays available header lifetime options and cache settings. 6. Modify the Header Lifetime Option settings as required. 7. Click the Save save button.

Obey ESI max-age headers if present


When responding to sites that use Edge Side Includes (ESI) for assembly, the origin web server sends the WebAccelerator system ESI Surrogate-Control headers, along with the HTTP response headers. If you enable the HTTP lifetime header option, Obey ESI max-age headers if present, the WebAccelerator system uses the max-age directive included in the ESI Surrogate-Control headers as the TTL value for compiled responses.

Use HTTP lifetime headers if present


The HTTP Cache-Control version 1.1 header specification identifies headers that are used to control web entities, such as the WebAccelerator system. Clients that are HTTP version 1.1 compliant are capable of providing request headers that contain directives that control caching behavior.

Policy Management Guide for the BIG-IP WebAccelerator System

9-3

Chapter 9

If the Use HTTP lifetime headers if present option is enabled, the WebAccelerator system obeys any HTTP Cache-Control header directives configured for the client. If this option is enabled and the client includes a HTTP Cache-Control header directive that indicates the client is not willing to accept content served from a cache, the WebAccelerator system is required to refresh the corresponding cached content for the request, even if that content has not yet expired.

Ignoring no-cache HTTP headers in the request


If you want to use HTTP lifetime headers, but want to be able to serve valid content that the WebAccelerator system has in its cache when applicable, you can enable the associated option, Ignore no-cache HTTP headers in the request.

Ignoring no-cache HTTP headers in the response


If the origin web server provides content that contains an HTTP Cache-Control header that indicates the response should not be cached, the WebAccelerator system is required to send subsequent requests to the origin server for fresh content, even if the content is has cached is still valid. If you want to use HTTP lifetime headers, but want to be able to serve valid content that the WebAccelerator system has in its cache when applicable, you can enable the associated option, Ignore no-cache HTTP headers in the response.

9-4

Configuring Lifetime Rules

Configuring the WebAccelerator Cache Settings


You can specify how the WebAccelerator system manages cached content by configuring values for the following options, in the WebAccelerator Systems Cache Settings area of the lifetime screen. Maximum Age Stand-in period HTTP Lifetime Heuristic

To access the WebAccelerator Cache Settings


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. On the User-defined Acceleration Policies table, click the name of the acceleration policy that you want to edit. 3. Click the node you want to modify. 4. From the Matching Rules list, choose Acceleration Rules. The Example policy screen displays a list of variation rules. 5. Click Lifetime. The Lifetime screen displays available header lifetime options and cache settings. 6. Modify the WebAccelerator Cache Settings as required. 7. Click the Save save button.

Maximum Age
The value for the WebAccelerator Cache Settings Maximum Age option dictates how long the WebAccelerator system stores cached content. Once that limit is met, the WebAccelerator system requests fresh content from the origin web server. If you have certain content that rarely changes, you can increase the amount of time that the WebAccelerator system stores that content. This reduces the load on your origin web server and increases the perceived performance of your site.

Stand-in Period
The value for the WebAccelerator Cache Settings Stand-in Period option identifies how long the WebAccelerator system continues to serve content from its cache, if the origin web server does not respond to the WebAccelerator systems requests for fresh content.

Policy Management Guide for the BIG-IP WebAccelerator System

9-5

Chapter 9

If the WebAccelerator system cannot retrieve fresh content from the origin web server after the stand-in period expires, it responds to subsequent requests for that content with an HTTP 404 (page not found) response. The default stand-in period is 0. If you do not specify a stand-in period, the WebAccelerator system immediately responds with an HTTP 404 response code, if content expires and the WebAccelerator system cannot obtain fresh content from the origin web servers.

HTTP Lifetime Heuristic


The value for the WebAccelerator Cache Settings HTTP Lifetime Heuristic option specifies a percentage of time on which the WebAccelerator system calculates the lifetime for cached content from the last time it was refreshed. To determine the lifetime based on this setting, the WebAccelerator system reviews the value for the HTTP LAST_MODIFIED response header, and computes the cache expiration according to the percentage defined for the HTTP Lifetime Heuristic option. The formula for this calculation is: ((current time - HTTP LAST_MODIFIED response header = X) * (lifetime heuristic)) + (current time) = content expiration For example if the HTTP LAST_MODIFIED response header specifies that the object was last modified at 9:00 a.m., the current time is 11:00 a.m., and the HTTP Lifetime Heuristic option is set to a value of 50%, then the content expiration is 12:00 p.m. The HTTP Lifetime Heuristic option is only in effect if you are using HTTP headers to identify content lifetime. Use this setting only if you want to use the HTTP LAST_MODIFIED response header to set compiled response TTL values.

9-6

Configuring Lifetime Rules

Configuring the Client Cache Settings


You can specify how the client browser caches content by configuring the following options, in the Client Cache Settings area of the lifetime screen. Do not change Maximum Age Insert no-cache directive into header

To access the Client Cache Settings


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. On the User-defined Acceleration Policies table, click the name of the acceleration policy that you want to edit. 3. Click the node you want to modify. 4. Modify the Client Cache Settings as required. 5. Click the Save save button.

Do not change
When you select the Client Cache Settings Do not change option, the WebAccelerator system directs the client browser to store content locally on the client, in accordance with the cache settings that are defined in the HTTP headers sent from the origin web server.

Maximum Age
The value defined for the Client Cache Setting Maximum Age option dictates how long the client browser stores content locally on the client. The WebAccelerator system uses the Maximum Age value to override any HTTP Cache-Control Expires headers and max-age directives that the origin web server sends to the client. The WebAccelerator overrides the max-age directive only if the new value for the max-age is greater than the value supplied by the origin web server. This setting affects only the browsers local cache, not the compiled response stored on the WebAccelerator systems cache.
Note

When a user clicks the browsers Refresh button, most browsers update their cache with fresh content immediately, even before the value defined for the Maximum Age setting is met.

Policy Management Guide for the BIG-IP WebAccelerator System

9-7

Chapter 9

The Client Cache Settings Maximum Age value applies even if the WebAccelerator system has invalidated the compiled response in its cache (see Chapter 10, Configuring Invalidations Rules). Do not increase the Client Cache Settings Maximum Age value unless there is an acceptable trade off between the freshness of the content, and overall site performance.
Important

If the assembly rules Intelligent Browser Referencing option is enabled, then the WebAccelerator system ignores the Client Cache Settings Maximum Age value for any objects it loads through the Intelligent Browser referencing feature. The top-level HTML page still uses the Client Cache Settings Maximum Age value, if defined. See Using parameter value substitution, on page 7-11, for more information.

Insert no-cache header


When the Client Cache Settings Insert no-cache directive into header setting is selected, the WebAccelerator system inserts a no-cache directive into the HTTP Cache-Control header that is returned from the origin web server. This header instructs the client browser to not cache content.

9-8

Configuring Lifetime Rules

Configuring an example lifetime rule


This section of the chapter provides information about how to configure an example lifetime 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, you configure the acceleration policys lifetime rules for the specified nodes on the Policy Tree, as described in Table 9.1.
Node Home node You change your sites content approximately every 4 hours. You want the WebAccelerator system to cache content for no longer than 24 hours. If the origin web servers are not responding for request for fresh content, you are willing to allow the WebAccelerator system to serve content that is 8 hours old (or twice the age of the content). To ensure that you can manage content invalidation, you do not want to rely solely on the browsers local cache settings for the home node, so you do not have a minimum time set for content residing in the browser cache before performing a check for content freshness. Default leaf node The content served for your general applications changes about once every 4 hours. You use an invalidations rule to force a refresh when content changes, but you do not want content to remain in the WebAccelerator systems cache for more than 5 hours without a refresh. If the origin web servers are not responding to the WebAccelerator systems refresh requests, you are willing to allow the WebAccelerator system to serve content that is 8 hours old (or twice the age of the content). Create a lifetime rule for the Default leaf node and, in the WebAccelerator Cache Settings section, specify a Maximum Age of 5 hours and a Stand-in Period of 8 hours. Leave all other options at the default settings. Lifetime Rule Parameters Create a lifetime rule for the Home node and, in the WebAccelerator Cache Settings section, specify a Maximum Age of 24 hours and a Stand-in Period of 8 hours. Leave all other options at the default settings.

Table 9.1 Lifetime rule parameters for Policy Tree example

Policy Management Guide for the BIG-IP WebAccelerator System

9-9

Chapter 9

Node Search leaf node Your search application returns data that has various expiration times; some content expires in as little as 10 minutes, and some content expires at 8 hours. You intend to use the HTTP Cache-Control Expire header max-age directive to identify the cache time for content served by the search application. Since search applications change more frequently than the rest of the site content, you are willing to allow the WebAccelerator system to serve search content that is 2 hours old. Images node You change the images for your applications approximately every 4 hours. You want the WebAccelerator system to cache images for no longer than 24 hours and, if the origin web servers are not responding to the WebAccelerator systems refresh requests, you are willing to allow the WebAccelerator system to serve images that are 8 hours old (or twice the age of the image).

Lifetime Rule Parameters Create a lifetime rule for the Search leaf node and, in Header Lifetime Options section, enable the Use HTTP lifetime headers if present option. In the WebAccelerator Cache Settings section, specify a Maximum Age of 8 hours and a Stand-in Period of 10 hours. Leave all other options at the default settings.

Create a lifetime rule for the Image node and, in the WebAccelerator Cache Settings section, specify a Maximum Age of 24 hours and a Stand-in Period of 8 hours. In the Client Cache Setting section, specify a Maximum Age of 4 days. Leave all other options at the default settings.

Table 9.1 Lifetime rule parameters for Policy Tree example

The following procedures describe how to create the lifetime rules for the nodes and leaf nodes for this example.

To configure the lifetime rule example for the Home node


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to edit. 3. Click the Home node. 4. From the Matching Rules list, choose Acceleration Rules. 5. Click Lifetime. 6. In the Header Lifetime Options area: a) Clear the Obey ESI max age if present check box. b) Clear the Use HTTP lifetime headers if present check box. 7. In the WebAccelerator Cache Settings area: a) In the Maximum Age box, type 24 and select Hours from the associated list. b) In the Stand-in Period box, type 8 and select Hours from the associated list. 8. Click the Save button.

9 - 10

Configuring Lifetime Rules

To configure the lifetime rule example for the Default leaf node
1. Click the Default leaf node. 2. In the Header Lifetime Options area: a) Clear the Obey ESI max age if present check box. b) Clear the Use HTTP lifetime headers if present check box. 3. In the WebAccelerator Cache Settings area: a) In the Maximum Age box, type 5 and select Hours from the associated list. b) In the Stand-in Period box, type 8 and select Hours from the associated list. 4. Click the Save button.

To configure the lifetime rule example for the Search leaf node
1. Click the Search leaf node. 2. In the Header Lifetime Options area: a) Clear the Obey ESI max age if present check box. b) Clear the Ignore no-cache HTTP headers in the request check box. c) Clear the Ignore no-cache HTTP headers in the response check box. 3. In the WebAccelerator Cache Settings area: a) In the Maximum Age box, type 8 and select Hours from the associated list. b) In the Stand-in Period box, type 2 and select Hours from the associated list. 4. Click the Save button.

To configure the lifetime rule example for the Image node


1. Click the Image node. 2. In the Header Lifetime Options area: a) Clear the Obey ESI max age if present check box. b) Clear the Use HTTP lifetime headers if present check box. 3. In the WebAccelerator Cache Settings area: a) In the Maximum Age box, type 5 and select Hours from the associated list.

Policy Management Guide for the BIG-IP WebAccelerator System

9 - 11

Chapter 9

b) In the Stand-in Period box, type 8 and select Hours from the associated list. 4. In the Client Cache Settings area: a) Select Maximum Age. The Maximum Age options display. b) In the Maximum Age box, type 4 and select Days from the associated list. 5. 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.

9 - 12

10
Configuring Invalidations Rules

Overview of invalidations rules Defining invalidations rule parameters Configuring an example invalidations rule

Configuring Invalidations Rules

Overview of invalidations rules


Cache invalidation is a powerful tool that you can use to maintain tight coherence between the content on your origin web servers and the content that the WebAccelerator system has in its cache. If you update content for your site at regular intervals, such as every day or every hour, you can use lifetime rules to ensure that the WebAccelerator systems cache is refreshed with the same frequency. Invalidations rules, on the other hand, allow you to expire cached content before it has reached its time to live (TTL) value, and is a good tool to use when content updates are event-driven, such as when an item is added to a shopping cart, a request contains a new auction bid, or a poster has submitted content on a forum thread. You configure invalidation rules from the invalidation screen.

To access the invalidation rules screen


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to edit. 3. On the Policy Tree, click the node you want to edit. 4. From the Matching Rules list, choose Acceleration Rules. 5. Click Invalidations. 6. Click the Create button. 7. In the Description box, type a description for the invalidations rule. For example: doSomething invalidated producttype 8. Configure the invalidation rule options as required. 9. Click the Save button.

When you configure invalidations rules, you define elements in a request that prompt the WebAccelerator system to invalidate and refresh specific cached content. When the WebAccelerator system receives a request that matches the parameters that you specified for the invalidations rule, it performs the following steps: Invalidates the cached content that it would have served. Sends the request to the origin web server for fresh content. Replaces the specified content, which it previously had in its cache, with the new content it receives from the origin web server. Responds to the request with the refreshed content. You can create invalidations rules that are based on a specific parameter, for example, an invalidation rule based on a certain cookie.

Policy Management Guide for the BIG-IP WebAccelerator System

10 - 1

Chapter 10

Important

Although there may be situations that require you to invalidate a significant portion of the cache, it is important to keep in mind that such a broad invalidation process can tax the origin web server as it attempts to respond to multiple requests for new content. For this reason, we recommend that you make the invalidations rule parameters as specific as possible, whenever possible.

Triggering invalidation
The WebAccelerator system triggers an invalidations rule for a request, only when the following conditions exist.

An invalidations rule is active. You can create invalidations rules and enable or disable them at any time. The invalidations rule contains a path parameter for both the Request Header Matching Criteria and the Cached Content to Invalidate. If you do not want to assign a specific path, you can use a single slash (/). The invalidations rule has reached its effective time. You can specify that invalidations rules are effective immediately, or you can set a time in the future. The WebAccelerator system has refreshed the cached content that corresponds to the request, before the effective date on the invalidations rule. This ensures that the WebAccelerator system does not invalidate a compiled response more than once, under the same invalidations rule. A compiled responses refresh time identifies the last time the WebAccelerator system refreshed that compiled response with content from the origin web server. If the compiled response was refreshed after the invalidations rule went into effect, the WebAccelerator system considers the content current. The request matches the configured request header matching criteria that you specified. The information that appears on the request must match all the HTTP request data type parameters that you specified for the Request Header Matching Criteria within the invalidations rule. For example, the following requests are candidates for invalidation for an invalidations rule that specifies, in the Request Header Matching Criteria, that the product query parameter must be Computers and that the path for the request must begin with /apps.

http://www.somesite.com/apps/shop.jsp?action=show&product=Computers http://web1.somesite.com/apps/search/simple.jsp?product=Computers& category=desktop

10 - 2

Configuring Invalidations Rules

While the following requests are not candidates for invalidation:


http://www.somesite.com/shop.jsp?action=show&product=Computers http://web1.somesite.com/apps/search/simple.jsp?product=Organizers& category=desktop

Setting the lifetime for invalidations rules


Invalidations rules are typically targeted at a range of compiled responses. The WebAccelerator system does not invalidate a compiled response until it matches a request to the invalidations rule for that compiled response, and it does not invalidate a range of compiled responses until it receives a request for each individual response in the range. By assigning an appropriate lifetime for a rule, the WebAccelerator system ensures that it refreshes every targeted compiled response, before it discards the rule. The WebAccelerator system assigns the lifetime value for the invalidations rule by examining the maximum lifetime values set for all compiled responses targeted by the rule, and using the longest TTL value it finds. When the longest TTL value for the compiled responses is reached, the WebAccelerator system considers those compiled responses expired and refreshes them, even if an invalidation trigger has not occurred. For example, if you created an invalidations rule for any requests that have either /apps or /srch in their path, your Policy Tree would include two nodes with application matching rules set so that requests with /apps in the path match to one node, and requests with /srch match to the other node. For this example, the /srch node has a lifetime rule specifying a maximum age of 15 minutes, while the /apps node uses the systems maximum lifetime of 24 hours. Compiled responses that the WebAccelerator system creates to service requests matching the /srch node have a maximum lifetime of 15 minutes. Compiled responses that the WebAccelerator system creates to service requests matching the /apps node uses a maximum lifetime of 24 hours. Based on this, the WebAccelerator system assigns a 24-hour lifetime for the invalidations rule. During the 24 hours that the rule is in effect, the WebAccelerator system refreshes compiled responses either because they match an invalidations rule or because they have exceeded the set lifetime value. Either way, the WebAccelerator system refreshes any content matching the invalidations rule at least once before it discards the rule.

Policy Management Guide for the BIG-IP WebAccelerator System

10 - 3

Chapter 10

Defining invalidations rule parameters


When configuring an invalidations rule, you must specify parameters for these settings:

Request Header Matching Criteria You define the parameters that the WebAccelerator system must match in a request, in order to trigger the invalidations rule. Cached Content to Invalidate You define the content to invalidate and refresh, if the WebAccelerator system finds the parameters in the HTTP request header that are specified in the Request Header Matching Criteria setting.
WARNING

When configuring an invalidation rule, all parameters are optional except for the Path parameter. If you do not specify the Path parameter for the Request Header Matching Criteria and the Cached Content to Invalidate settings, the invalidations rule does not trigger the WebAccelerator system to invalidate the specified cache. If you do not want to define a specific path, you can use a single slash (/).

Request Header Matching Criteria


For the Request Header Matching Criteria setting, you specify the HTTP request data type parameter that the WebAccelerator system must find in an HTTP request header, in order to trigger the invalidations rule. For the WebAccelerator system to apply an invalidations rule, the HTTP request must match to a leaf node as well the associated parameters specified for the Request Header Matching Criteria setting. Not all requests that match a node that you define will trigger the invalidations rule. You can define a subset of matching requests by specifying additional parameters for the source as part of the rule. Then, only the defined subset of requests trigger the invalidations rule. For example, assume that to match to a particular node, a request must include /apps/shopping in the path and the query parameter cart must be present. To configure the Request Header Matching Criteria setting parameters for this node, you specify that a request must include the query parameter cart and the value of cart must equal Add. In this case, not all requests that match the node prompt the invalidation. The WebAccelerator system only invalidates requests where cart=add.

10 - 4

Configuring Invalidations Rules

Cached Content to Invalidate


The WebAccelerator system only matches a request to an invalidation rule if it first finds the parameters set for the Request Header Matching Criteria setting. If it matches a request to the parameters configured for the Request Header Matching Criteria setting, only then does the WebAccelerator system review the parameters set for the Cached Content to Invalidate setting. If a match occurs, the WebAccelerator system invalidates the content specified, and retrieves fresh content from the origin web server. The WebAccelerator system stores the fresh content in its cache and services the request. When configuring an invalidations rule, you must provide at least one parameter based on the Path data type for the Cached Content to Invalidate setting.

Policy Management Guide for the BIG-IP WebAccelerator System

10 - 5

Chapter 10

Configuring an example invalidations rule


This section of the chapter provides information about how to configure an example invalidations 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, any request for the /apps/doSomething.jsp application changes content returned by /srch/doSimpleSearch.jsp. However, you want requests for doSimpleSearch.jsp to be updated only if its producttype query parameter matches the value set for the group query parameter on doSomething.jsp. That is, if the WebAccelerator system receives the following request:
http://www.somesite.com/apps/doSomething.jsp?group=Doors&....

it should send, to the origin web server, any subsequent requests that appear as follows:
http://www.somesite.com/srch/doSimpleSearch.jsp?producttype=Doors&....

To accomplish this, you create an invalidations rule for the Default leaf node, because you know that all requests for the path, /apps/doSomething.jsp, match to that node. The target, requests for doSimpleSearch.jsp, always match to the Search node and should include a producttype query parameter when a value matches the value of group in the triggering request for /apps/doSomething.jsp. Therefore, the Cached Content to Invalidate setting should specify doSimpleSearch.jsp for the path, and producttype for the query parameter.

To create the example invalidations rule


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to edit. 3. On the Policy Tree, click the Default leaf node. 4. From the Matching Rules list, choose Acceleration Rules.

10 - 6

Configuring Invalidations Rules

5. Click Invalidations. 6. Click the Create button. 7. In the Description box, type a description for the invalidations rule. For example: doSomething invalidated producttype 8. In the Request Header Matching Criteria area, select Path from the Add Parameter list, and click the Add button. 9. In the Value(s) box, type the following application path: /apps/doSomething.jsp This prompts the WebAccelerator system to trigger the invalidations rule only for this application. All other requests that match to the Default node do not trigger this invalidations rule. 10. Click the Save button. The Request Header Matching Criteria table displays the Path. 11. In the Cached Content to Invalidate area, select Path from the Add Parameter list, and click the Add button. 12. In the Value Match area, select Value Group from the Type list. 13. In the Value Group box, type the following path: /srch/doSimpleSearch.jsp 14. Click the Save button. 15. In the Cached Content to Invalidate area, select Query Parameter from the Add Parameter list, and click the Add button. 16. In the Name box, type producttype. 17. In the Value Match area, select Query Parameter from Request from the Type list. 18. In the Query Parameter from Request box, type group. 19. Click the Save button.

Policy Management Guide for the BIG-IP WebAccelerator System

10 - 7

Chapter 10

10 - 8

11
Configuring Responses Cached Rules

Overview of responses cached rules Configuring an example responses cached rule

Configuring Responses Cached Rules

Overview of responses cached rules


Most acceleration rules are based on information that is contained in a request. For example, when a particular query parameter is set to a certain value, it prompts the WebAccelerator system to perform a specified function, or the WebAccelerator system provides a specific response based on the presence or absence of a cookie in a request. Responses cached rules, on the other hand, are based on specific HTTP response characteristics that the WebAccelerator system receives from the origin web server. These HTTP response parameters determine whether the WebAccelerator system should cache that content and under what conditions it should continue to cache that content, when the origin web server returns certain response codes. You can override the WebAccelerator systems default behavior by modifying the following options for responses cached rules.

Caching HTML Documents Specifies whether an HTML response from the origin web server must contain matching begin and end HTML tags for WebAccelerator system to cache the content. By default, the WebAccelerator system caches only responses that are complete. Responses Codes Cached Specifies which response codes returned from the origin web server prompt the WebAccelerator system to cache content. By default, the WebAccelerator system caches content when the origin web server returns 200, 201, 203, or 207 response codes. You cannot change this default behavior, but you can specify additional codes.

You configure responses cached rules from the responses cached screen.

To access the responses cached screen


1. In the navigation pane, expand WebAccelerator and click Policies. 2. Click the name of the acceleration policy that you want to edit. 3. On the Policy Tree click the node you want to modify. 4. From the Matching Rules list, choose Acceleration Rules. 5. Click Responses Cached. 6. Configure the responses cached rules as required. 7. 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.

Policy Management Guide for the BIG-IP WebAccelerator System

11 - 1

Chapter 11

Caching HTML content


By default, the WebAccelerator system caches content only if it is complete. One way the WebAccelerator system determines if content is complete, is to verify that HTML pages contain both a begin and end HTML tag. However, for troubleshooting purposes you may require that the WebAccelerator system temporarily cache incomplete HTML content, until you determine why your application is not returning properly formed HTML pages. To do this, you can configure responses cached rules to override this default behavior and cache HTML content that does not contain both a begin and end HTML tag.

Caching content based on response status codes


The WebAccelerator system always caches content from the origin web servers if it contains an HTTP 200, 201, 203, or 207 response status code. You cannot change this default behavior. However, you can specify additional response codes to prompt the WebAccelerator system to cache content. Those response codes are defined in Table 11.1.
Response Code
300

Definition
Multiple Choices The requested resource has multiple possibilities, each with different locations. Moved Permanently The requested content has been permanently assigned a new URI. The origin web server is responding with a redirect to the new location for the content. Found The requested content temporarily resides under a different URI. The redirect to the new location may change. Temporary Redirect The requested content temporarily resides under a different URI. The redirect to the new location may change. Gone The requested content is no longer available and a redirect is not available.

301

302

307

410

Table 11.1 Response codes

11 - 2

Configuring Responses Cached Rules

Configuring an example responses cached rule


This section of the chapter provides information about how to configure an example responses cached rule. For this example site, you have three top-level nodes on the Policy Tree as follows:

Home This 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 node specifies the rules related to graphics images.

For this example, your site had an application requested as http://www.siterequest.com/apps/magic.jsp, but due to current development on your site, it is temporarily requested as http://www.siterequest.com/apps/magicact.jsp. As a result of this change, the WebAccelerator system handles requests for the http://www.siterequest.com/apps/magic.jsp with a temporary redirect to http://www.siterequest.com/apps/magicact.jsp. To manage this change, add a responses cached rule to the default node (which is inherited by all leaf nodes) that indicates that the WebAccelerator system should cache content that contains a 307 response code.

To configure the responses cached rule for this example


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to edit. 3. On the Policy Tree, click the Default leaf node. 4. From the Matching Rules list, choose Acceleration Rules. 5. Click Responses Cached. 6. In the Response Codes Cached area, select the 307 - Temporary Redirect check box. 7. Click Save.

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.

Policy Management Guide for the BIG-IP WebAccelerator System

11 - 3

Chapter 11

11 - 4

12
Specifying Log Formats for Hit Logs

Using hit logs Selecting a standard log format for hit logs Creating a custom log format for hit logs Configuring an example customized hit log format

Specifying Log Formats for Hit Logs

Using hit logs


Many sites perform traffic analysis against the HTTP log files that their web servers generate. The WebAccelerator system creates logs, called hit logs, that contain the same sort of information that origin web servers create in their HTTP log files. For user-defined acceleration policies, you can tailor the information that appears in the hit logs so that they work seamlessly with whatever analysis tools you use for your origin web servers HTTP log files. Through the logging feature, you can specify the type of information included in hit logs, as well as the format in which to log that information. You can log HTTP and HTTPS requests together or log them separately, selecting different logging options for each. Further, you can create a customized logging format if you do not want to use the predefined logging formats.
Note

You cannot enable logging for predefined acceleration policies; you can only enable logging on user-defined and signed acceleration policies.

To view hit log files from the command line


1. Log on to the WebAccelerator systems command line interface. 2. Change to the log directory by typing the following command:
cd /var/log/wa/access

3. Type the following command:


ls

4. To specify a certain log file, type the following command:


more access_log_<application>_<type>_v<version number>.log

Log files display in the following format: access_log_<application>_<type>_v<version number>.log Where: <application> is the name of the application, for which you are viewing the log file. <type> indicates the type of protocol logged. An i indicates HTTP protocol and an s indicates HTTPS protocol. Note that you can log both HTTP and HTTPS separately, or together in the same log file. For example, <type> could indicate either i or s, or i and s. <version number> is the version number of the log file.

Policy Management Guide for the BIG-IP WebAccelerator System

12 - 1

Chapter 12

Selecting a standard log format for hit logs


The lines that appear at the top of a log file are called, log headers. You can use log headers to identify the type and order of the information written to each line in the log file. Some log analysis software also uses log headers to determine how to parse a log file. The three common conventions for log headers are:

No header line Apache web servers use this option. By default, Apache web servers write access logs in a format that is identical to the NCSA Common format. NCSA Common or Combined headers Netscape servers, and their descendants (such as the iPlanet Enterprise Server) write a log header line that is unique to these family of servers. These servers generally use either the NCSA Common or Combined log format and the log header lines are comprised of keywords. For example:
#format=%Ses->client.ip% - %Req->vars.auth-user% [%SYSDATE%] ....

W3C headers Most Microsoft Internet Information Services (IIS) web servers write log files in the extended log file format, which are defined by a W3C working draft. For more information, see http://www.w3.org/TR/WD-logfile.html.

The predefined log format options on the WebAccelerator system represent a collection of logging information that is commonly used by origin web servers and consists of: NCSA Common (no log header) NCSA Common (Netscape log header) NCSA Combined (no log header) NCSA Combined (Netscape log header) W3C Extended

To specify a logging format


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the Logging link next to an acceleration policy. 3. To create individual logs for the HTTP and HTTPS protocols, select the Log HTTP and HTTPS requests separately check box in the What to Log area. 4. In the HTTP Logs area, select the options as required: Log all transactions Only log transactions served from cache Do not log
12 - 2

Specifying Log Formats for Hit Logs

5. If you select Log all transactions, or Only log transactions served from cache, then select a format for the HTTP logs from the Log Format list. 6. In the HTTPS Log area (available only if you are logging HTTP and HTTPS separately), select the options as required: Log all transactions Only log transactions served from cache Do not log 7. If you selected Log all transactions, or Only log transactions served from cache, then select a format for the HTTPS logs from the Log Format list. 8. Click the Save button.

Standard log format examples


Following are examples of the standard log formats.

NCSA Common log format


The NCSA Common log format syntax is as follows:
host rfc931 username [date:time UTC_offset] "method URI?query_parameters protocol" status bytes

For example:
125.125.125.2 - - [10/Oct/2002:23:44:03 -0600] "GET /apps/example.jsp?sessionID=34h76 HTTP/1.1" 200 3045

NCSA Combined log format


The NCSA Combined log format syntax is as follows:
host rfc931 username [date:time UTC_offset] "method URI?query_parameters protocol" status bytes "referrer" "user_agent" "cookie"

For example:
125.125.125.2 - - [23/Oct/2002:23:44:03 -0600] "GET /apps/example.jsp?sessionID=34h76 HTTP/1.1" 200 3045 "http://www.siterequest.com" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" "UserID=ssarette;Category=PDA;Selection=Various"

Policy Management Guide for the BIG-IP WebAccelerator System

12 - 3

Chapter 12

W3C Extended log format


The W3C extended log format syntax is as follows:
date time rfc931 username host method URI query_parameters status bytes request_length time_taken protocol user_agent cookie referrer

For example:
2002-10-23 23:44:03 205.47.62.112 - 125.125.125.2 GET /apps/example.jsp sessionID=34h76 200 3045 124 138 HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0 UserID=ssarette;Category=PDA;Selection=Various http://www.siterequest.com

12 - 4

Specifying Log Formats for Hit Logs

Creating a custom log format for hit logs


If you require information that is not included in the predefined log formats, you can create customized log formats.

To create a new hit log format


1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the Logging link next to an acceleration policy. 3. To create individual logs for the HTTP and HTTPS protocols, select the Log HTTP and HTTPS requests separately check box in the What to Log area. 4. In the Logs area (or HTTP Logs area, if you are logging HTTP and HTTPS separately), select the options as required: Log all transactions Only log transactions served from cache Do not log If you select Log all transactions or Only log transactions served from cache, the screen refreshes, displaying additional options. If you select Do not log, skip to Step 7. 5. From the Log Format list, select a format for the logs. If you select a log format from the list, skip to Step 7. Optionally, click the New button to create a new log format. a) In the Name box, type a descriptive name for the new log format. b) From the Header Format Type list, select a format type. c) From the Format Text list, select a component, one at a time, and then click the Add button. d) Click the Preview button to view the a sample of the log format you created. e) Click the Save button. f) From the Log Format list, select the log format that you created. 6. In the HTTPS Log area (available only if you are logging HTTP and HTTPS separately), select from the following options: Log all transactions Only log transactions served from cache Do not log

Policy Management Guide for the BIG-IP WebAccelerator System

12 - 5

Chapter 12

If you select Log all transactions or Only log transactions served from cache, the screen refreshes, displaying additional options. Repeat Step 5. 7. Click the Save button.

12 - 6

Specifying Log Formats for Hit Logs

Configuring an example customized hit log format


This section of the chapter provides information about how to configure an example customized log format. For this example, you want your hit logs to contain the following information: IP of the requesting client Date and time of the request HTTP method used for the request Query URI Query parameters passed using the GET method HTTP version used by the request HTTP status returned on the response Length of the response Actual origin web server to which the WebAccelerator system sends required requests For this example, your origin web servers are all running Apache so you want your log lines to follow the NCSA Common (No Header) formatting convention, as follows:
xxx.xxx.xxx.xxx [date:time UTC_offset] "Method uri?query_parameter HTTP_ver" response_status response_length

However, you want one to customize the NCSA Common (no header) log format to add an additional field that includes the origin web server host name and IP address.

To customize the NCSA Common (no header) log format with the origin web server information
1. In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the Logging link next to an acceleration policy. 3. In the Logs area, click Log all transactions. 4. From the Log Format list, select NCSA Common (no header) and click Edit. 5. In the Name box, type a descriptive name for the log. 6. From the Format Text list on the right side of the screen, select Hostname/IP of Origin Server and click Add. The %B symbol appears in the Log Item Format box. Verify that there is a space before %B symbol in the Log Item Format box. If there is not, manually add a space. 7. Click the Save button. 8. From the Log Format menu, select the log format you created. 9. Click the Save button.
Policy Management Guide for the BIG-IP WebAccelerator System 12 - 7

Chapter 12

12 - 8

Glossary

Glossary

acceleration policy An acceleration policy is a collection of rules that determine how the WebAccelerator system caches, assembles, and responds to HTTP requests. There are three types of acceleration policies offered with the WebAccelerator system: predefined acceleration policies, user-defined acceleration policies, and signed acceleration policies. See also acceleration rules, matching rules, predefined acceleration policy, user-defined acceleration policy, and signed acceleration policy. acceleration rules Acceleration rules dictate how the WebAccelerator system manages HTTP requests. Some acceleration rules pertain to how the WebAccelerator system handles a request, and some pertain to how the WebAccelerator system handles the response. Each acceleration rule is associated with a matching rule, represented by a leaf node on the Policy Tree. The WebAccelerator system first matches an HTTP request or response to a matching rule, then applies the associated acceleration rules. Just like a matching rule, the acceleration rule can inherit policies from its ancestors, or parent node, on the Policy Tree. See also matching rules and Policy Tree. application matching Application matching is the process of mapping HTTP requests and responses to associated application profiles. To perform application matching, the WebAccelerator system analyzes information in an HTTP request to match the request to an application profile that you created, and then apply the associated acceleration policys matching rules to group the request and response to a specific leaf node on the Policy Tree. Once matched to a leaf node, the WebAccelerator system applies the acceleration policys acceleration rules to each group. See also acceleration rules, application profile, and matching rules. assembly Assembly is the process of running a compiled response in order to respond to an HTTP request. When the WebAccelerator system receives an HTTP request that it can service from its cache, it places that request in an assembly queue. The WebAccelerator system then uses special threads to run the compiled response (including any related ESI-compiled response), and assembles the content required to respond to the request. assembly rules Assembly rules are acceleration rules that dictate how the WebAccelerator system assembles pages in order to respond to requests. Assembly rules contain specific parameter value substitution and various content assembly options, such as MultiConnect and Intelligent Browser Referencing. See also MultiConnect and Intelligent Browser Referencing.

Policy Management Guide for the BIG-IP WebAccelerator System

Glossary - 1

Glossary

branch node A branch node is part of the Policy Tree, and represents matching rules and acceleration rules for an acceleration policy. Branch nodes are used to propagate rule inheritance to leaf nodes. The WebAccelerator system does not apply matching rules and acceleration rules that are associated with a branch node directly to an HTTP request. See also Policy Tree, leaf node, and root node. client cache minimum age The client cache minimum age is a setting that specifies the minimum amount of time that content is stored in the web browsers local cache before the browser checks for fresh content from the WebAccelerator system. This setting affects only the browsers local cache, not the compiled response stored on the WebAccelerator systems cache. compiled response A compiled response consists of the information that the WebAccelerator system received from the origin web server, saved in an internal format. The WebAccelerator system uses the compiled response object that it created, to assemble responses. See also assembly. content lifetime Content lifetime is the length of time that is allowed to elapse before a compiled response expires, and the WebAccelerator system sends a request to the origin web server for fresh content. Content lifetime can vary for each compiled response. Edge Side Includes Edge Side Includes (ESI) is a simple markup language that supports web surrogates, such as the WebAccelerator system, and is used to define web page components for dynamic assembly and delivery of web applications. hit logs The WebAccelerator system creates log files called hit logs to log cache hits and misses. These hit logs contain the same sort of information that your web servers create in their log files. For user-defined acceleration policies, you can tailor the information that appears in the WebAccelerator systems hit logs so they work seamlessly with whatever analysis tools you use for your web server log files. Hot Cache The WebAccelerator system uses the Hot Cache feature to serve content that does not require special assembly.

Glossary - 2

Glossary

HTTP Lifetime Heuristic The HTTP Lifetime Heuristic setting, specified in an acceleration policys lifetime rules, is a calculation that the WebAccelerator system uses to determine the expiration of content based on a specified percent of time since the content was last modified. Intelligent Browser Referencing The Intelligent Browser Referencing feature (enabled by default) increases the efficiency of the web browsers local cache by reducing or eliminating requests to your site for relatively static content, such as images and style sheet (CSS) files. invalidations rules Invalidations rules are acceleration rules that you use to specify the events that prompt the WebAccelerator system to refresh cached content before it has reached its time to live (TTL) value. Invalidations rules are a good tool to use when content updates are event-driven, such as when an item is added to a shopping cart or a request contains a new auction bid. leaf node A leaf node is part of the Policy Tree. The WebAccelerator system performs application matching only against the leaf nodes on the Policy Tree. For each incoming HTTP request, the WebAccelerator system uses the matching rules for each node, to find the best leaf node to match and then applies the corresponding acceleration rules. See also Policy Tree, branch node, and root node. lifetime mechanisms The options and parameters that the WebAccelerator system uses to manage caching. log headers Log headers are the lines that appear at the top of a log file, and are used to identify the type and order of the information written to each line in the log file. Some log analysis software uses log headers to determine how to parse the log file. matching rules Matching rules are based on specific parameters for HTTP request data types and HTTP response data types. The WebAccelerator system uses matching rules to look for identified objects in an HTTP request or response, such as path, file extension, cookie, or query parameter, in order to group the requests and responses. Once the requests and responses are grouped, the WebAccelerator system applies the associated acceleration rules to the request and responses. See also Policy Tree and acceleration rules.

Policy Management Guide for the BIG-IP WebAccelerator System

Glossary - 3

Glossary

MultiConnect The WebAccelerator systems MultiConnect feature modifies embedded URLs with unique subdomains, prompting the clients web browser to open up to four (two per HTTP, and two per HTTPS protocol) TCP connections to the WebAccelerator system for each subdomain when requesting pages over the HTTP/HTTPS protocol. These additional browser connections result in faster data downloads. node See root node, branch node, and leaf node. number randomizer Number randomizer is an assembly rule parameter value substitution operation that 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. origin web servers Most sites are built on a collection of web servers, application servers, and database servers that we refer to collectively as origin web servers. Origin web servers can serve all possible permutations of the content offered by your site, while the WebAccelerator system only stores and serves page content combinations that were previously requested by clients visiting your site. parameter value substitution 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 specified appears on the URL embedded in the page. See also assembly rules. Policy Editor From the Policy Editor screen, you can view the matching rules and acceleration rules for user-defined and predefined acceleration policies, as well as create or modify user-defined acceleration policies. Policy Tree The Policy Tree is located on the left side of the Policy Editor screen, and is composed of root, branch, and leaf nodes. The WebAccelerator system performs application matching against leaf nodes that correspond to specific matching rules, and then applies the associated acceleration rules. See also Policy Editor, application matching, root node, branch node, and leaf node.

Glossary - 4

Glossary

predefined acceleration policy The WebAccelerator system comes with several predefined acceleration policies, most of which are optimized for a specific application. Additionally, the WebAccelerator system offers predefined acceleration policies for general delivery, which are not application specific. You can use the Policy Editor to view, add, or modify the rules for predefined acceleration policies. See also Policy Editor, signed acceleration policy, and user-defined acceleration policy. proxy override rules Proxy override rules are acceleration rule options that you can specify within proxying rules to identify conditions under which the WebAccelerator system should ignore all proxying rules. When a proxy override rule applies to an HTTP request, the WebAccelerator system can service the request from its cache, even if a proxying rule dictates that the WebAccelerator should send the request to the origin web server. See also proxying rules. proxying rules Proxying rules are acceleration rules that identify the elements in a URL of an HTTP request that indicate whether the WebAccelerator system should send a request to your origin web servers, instead of attempting to service it from its cache. See also proxy override rules. response rewrite scripts Response rewrite scripts manipulate HTTP responses that the WebAccelerator system receives from the origin web servers. This manipulation occurs before the response is processed by the WebAccelerator system, so it is the manipulated response that the WebAccelerator system manages and caches, not the actual response sent by the origin web servers. See also Rewrite Engine. responses cached rules Responses cached rules are acceleration rules that are based on information that is contained in the response that the WebAccelerator system receives from the origin web server. They provide the WebAccelerator system with the information that it needs to determine if it should cache that content. Rewrite Engine The Rewrite Engine uses response rewrite scripts to manipulate HTTP responses received from the origin web servers. See also response rewrite scripts.

Policy Management Guide for the BIG-IP WebAccelerator System

Glossary - 5

Glossary

root node A root node is a part of the Policy Tree and represents matching rules and acceleration rules for an acceleration policy. Root nodes are used to propagate rule inheritance to leaf nodes. The WebAccelerator system does not apply matching rules and acceleration rules that are associated with a root node directly to an HTTP request. What distinguishes a root node from a branch node is that a root node has no parent node. See also Policy Tree, branch node, and leaf node. signed acceleration policy A signed acceleration policy is an acceleration policy that is certified and encrypted by its author. Unlike with predefined or user-defined acceleration policies, you cannot view or modify the rules for a signed acceleration policy. See also predefined acceleration policy and user-defined acceleration policy. Smart Cache The WebAccelerator system uses the Smart Cache feature to serve an object that requires specific assembly processing, such as objects for which variation rules apply. source definition The WebAccelerator system uses a source definition for parameter value substitution during assembly. 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. Source definitions are specified in an acceleration policys assembly rule. See also target definition. stand-in period The stand-in period identifies how long the WebAccelerator system continues to serve content from its cache after content has expired and when the origin web servers do not respond when the WebAccelerator system requests fresh content. surrogate targeting Surrogate targeting is an ESI mechanism that allows you to control a specific surrogate device. This mechanism is required, because a site can contain multiple web surrogates. You can use surrogate targeting to identify header information that is meant for the WebAccelerator system, by adding a parameter to the Surrogate-Control directive.

Glossary - 6

Glossary

target definition The WebAccelerator system uses a target definition or parameter value substitution during assembly. 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. Target definitions are specified in an acceleration policys assembly rule. See also source definition. Unique Content Identifier (UCI) A UCI is a collection of elements, such as the URI and query parameters, that is generated in responses from the origin web server. The WebAccelerator system uses the UCI to easily match future requests to the correct content in its cache. See also variation rules. user-defined acceleration policy A user-defined acceleration policy is a policy that you create by either copying an existing policy and modifying the rules, or by creating a new acceleration policy and specifying all new rules. You can use the Policy Editor to view, add, and modify the rules for user-defined acceleration policies. See also Policy Editor, predefined acceleration policy, and signed acceleration policy. value groups A value group is a collection of variation rule parameter values. The purpose of a value group is to enable you to specify several different parameter values for the same variation rule. Each value can prompt a different behavior by the WebAccelerator system. variation rules Variation rules are acceleration rules that are associated with content that is specific to requests. If an acceleration policy contains a variation rule, the WebAccelerator system uses the information in the variation rule to help create the Unique Content Identifier (UCI), for the request and for the cached page, which the WebAccelerator system stores in its cache in the form of a compiled response. See also Unique Content Identifier (UCI). X-PvInfo response headers An X-PvInfo response header contains information about how the WebAccelerator system handles an HTTP request. Before sending a response to a client, the WebAccelerator system enters an informational X-PvInfo response header into the response.

Policy Management Guide for the BIG-IP WebAccelerator System

Glossary - 7

Glossary

Glossary - 8

Index

Index

200-series response status codes basing cache behavior on 11-2 300-series response codes basing caching behavior on 11-2 300-series response status codes basing cache behavior on 11-2 400-series response status codes basing cache behavior on 11-2 missing host header 4-1 410-response code basing caching behavior on 11-2 410-series response status codes basing cache behavior on 11-2

A
acceleration policies caching content based on response codes 11-2 creating a production copy 2-6 creating a signed acceleration policy 2-8 defined 2-1 deleting 2-3 exporting 2-11 importing 2-9, 2-11 maintaining a development copy 2-6 managing 2-3 matching to a proxying rule 4-2 publishing 2-10 reviewing types 2-1 signing 2-8 troubleshooting 4-1, 4-25 understanding 2-1 viewing 2-3, 2-7 acceleration policy for general delivery 2-1 acceleration policy analysis using X-PvInfo response headers 4-25 acceleration policy rules inheritting 3-6 acceleration rules mapping HTTP requests 5-1 understanding 2-1 advanced assembly options specifying system-wide settings 7-15 ambiguous query parameters basing on node priority 3-12, 5-2 example 6-5 for variation rules 6-5 Apache web servers selecting a log format 12-2 application matching and a leaf node 3-6 based on path parameter 5-2 basing on node priority 3-12, 5-2 determining the best match 5-2

example 5-4 processing unmatched requests 5-3 understanding precedence rules 5-2 using HTTP headers 4-1 assembly rules configuring value substitution parameters 7-12 example 7-17 for ESI 7-1 limiting URLs targeted for substitution 7-12 overriding compression settings 4-13 overview 7-1 specifying advanced assembly options 7-15 specifying target definitions 7-12 using parameter value substitution 7-11 using source definition for parameter value substitution 7-12 using the number randomizer 7-13

B
back-end processing 4-1 branch node defined 3-6 understanding rule inheritance 3-6 branch nodes representing content types 3-2 browser defining lifetime rules for client cache 9-7 browser behavior controlling 1-1 browser cache using the Intelligent Browser Referencing feature 7-2

C
cache conditions processing HTTP requests 4-2 cache invalidation creating invalidation triggers 10-4 performing 10-1 setting a lifetime for invalidation rules 10-3 triggered by invalidations rules 10-1 triggering cache invalidation 4-2 cache request directives specifying for a lifetime rule 9-3 cache resources managing with variation rules 6-2 cache response directives and no-cache directives 4-19 specifying for a lifetime rule 4-19 cached content to invalidate parameter specifying for invalidation 10-4 caching options caching HTML documents 11-1 child node. See leaf nodes. classifying responses 4-12 Index - 1

Policy Management Guide for the BIG-IP WebAccelerator System

Index

client browser cache defining lifetime rules options 9-7 client IP parameter HTTP request data type 4-11 compiled responses using assembly rules 7-1 using variation rules to reduce cache size 6-2 compression and default behavior 7-17 enabling 7-8 for image objects 7-8 for PDF objects 7-8 meeting requirements for 7-8 overriding assembly rules 4-13 using gzip-encoding 7-8 conditional GET request using Intelligent Browser Referencing feature 7-2 Configuration utility and the Welcome screen 1-3 content accelerating access 1-1 caching using variation rules 6-2 including HTTP request elements in UCI 6-2 refreshing using invalidations rules 10-2 refreshing when expired 9-1 content assembly compressing content using gzip-encoding 7-8 configuring parameter value substitution 7-12 content assembly on proxies feature enabling 7-10 content caching meeting required conditions for caching 4-2 content compression feature described 7-8 enabling 7-8 content expiration 9-1 using the Intelligent Browser Referencing feature 7-2 content invalidation servicing HTTP client requests 4-2 content lifetime defined 9-1 defining a stand-in period 9-5 defining for lifetime rules 9-1 obeying precedence rules 9-1 refreshing content 9-1 specifying options 9-3 using ESI Surrogate-Control headers 4-22, 9-3 using HTTP Cache-Control headers 4-19, 9-3 using HTTP Lifetime Heuristic 9-6 content lifetime rules configuring 9-1 expiring content 9-1 content type parameter HTTP request data type 4-11 content variation. See variation rules. Content-Length response headers caching responses 4-3

Content-Type request headers providing a value 4-1 cookie data types, supporting 4-16 cookie parameter HTTP request data type 4-8 customized logs, example 12-7

D
data analysis for traffic using hit logs 12-1 default caching behavior 6-2 device tokens for ESI 4-24 directives for Surrogate-Control response headers 4-22 disk serving content from Smart Cache 4-26 documentation finding 1-3 for the WebAccelerator system 1-2

E
Edge Side Includes. See ESI. Enable Compression setting for image and PDF object types 7-8 Enable Content Assembly on Proxies feature using with Intelligent Browser Referencing feature 7-3 encrypted acceleration policies. See signed acceleration policies. ESI and device token 4-24 conflicting with random value substitution 7-14 using HTTP lifetime headers 9-4 using surrogate targeting 4-24 using to assemble pages 7-1 ESI page assembly and Surrogate-Control headers 4-22 ESI Surrogate-Control headers and max-age directive 4-23, 9-3 using 4-22 examples calculating the HTTP Lifetime Heuristic 9-6 configuring a customized log format 12-7 configuring invalidations rules 10-6 configuring the MultiConnect feature 7-6 enabling the Intelligent Browser Referencing feature 7-4 for a variation rule 6-1 for application matching 5-4 for assembly rules 7-17 for proxying rules 8-6 for value groups 6-4 for value substitution parameters 7-12 processing ambiguous query parameters 6-5 using parameter value substitution 7-11

Index - 2

Index

Expect request header providing a value for 4-1 expired content using lifetime rules 9-1 using the Intelligent Referencing feature 7-2 exporting acceleration policies 2-11 extension data types and precedence 5-3 extension data types, supporting 4-15 extension parameter HTTP request data type 4-6

F
F5 Networks Technical Support, accessing 1-3

G
GET requests using the Intelligent Browser Referencing feature 7-2 globalfragment.xml file using to classify responses 4-12 guides finding documentation 1-3 gzip-encoding specifying in assembly rules 7-8

H
header data types, supporting 4-16 header parameter HTTP request data type 4-10 headers and format of a structured parameter 4-10 using ESI Surrogate-Control headers 9-3 viewing X-PvInfo response headers 4-1, 4-25 hit logs tailoring format 12-1 host data types, supporting 4-15 host headers returning a 400-series response status code 4-1 host parameter HTTP request data type 4-6 Host request headers and requirements for servicing requests 4-1 Hot Cache and response codes 4-27 HTML content caching 11-1 HTTP Cache-Control headers and no-cache directives 4-19 for lifetime rules 4-19, 9-3 HTTP client requests requirements for servicing 4-1 HTTP data type parameters supporting regular expression strings 4-15 HTTP LAST_MODIFIED response headers and lifetime rules 9-6 for HTTP Lifetime Heuristic option 9-6

HTTP lifetime headers and lifetime rule precedence 9-2 HTTP Lifetime Heuristic feature configuring 9-6 example 9-6 HTTP protocols, supporting 4-1 HTTP request data type parameters basing a rule on the client IP parameter 4-11 basing a rule on the content type parameter 4-11 basing a rule on the cookie parameter 4-8 basing a rule on the extension parameter 4-6 basing a rule on the header parameter 4-10 basing a rule on the host parameter 4-6 basing a rule on the method parameter 4-10 basing a rule on the path parameter 4-6 basing a rule on the path segment parameter 4-7 basing a rule on the protocol parameter 4-9 basing a rule on the referrer parameter 4-9 basing a rule on the unnamed query parameter 4-7 basing a rule on the user agent parameter 4-9 caching for UCI 6-2 for source substitution 7-12 specifying for invalidation rules 10-4 using the query parameter 4-6 HTTP request headers and size limit 4-1 processing requests with a no-cache directive 4-26 providing a value for Content-Type headers 4-1 providing a value for Expect request header 4-1 using for application matching 4-1 HTTP requests and requirements for servicing 4-1 mapping to acceleration rules 5-1 processing 4-2 processing using a proxying rule 4-2 redirecting 4-1 HTTP response codes 11-2 HTTP response headers matching the Content-Length header 4-3 using for application matching 4-1 using the Transfer-Encoding response header 4-3 HTTP/0.9 protocol, supporting 4-1 HTTP/1.0 protocol supporting 4-1 HTTP/1.1 protocol, supporting 4-1

I
If-Modified-Since headers 7-2 image objects compressing 7-8 image tags using the Intelligent Browser Referencing feature 7-2 incomplete documents caching 11-1

Policy Management Guide for the BIG-IP WebAccelerator System

Index - 3

Index

inheritance understanding rule inheritance 3-6 using the branch node 3-6 Intelligent Browser Referencing feature and required conditions 7-3 and supported tags 7-2 applying to content 7-2 avoiding conditional GET requests 7-2 described 7-2 enabling 7-1, 7-3 example 7-4 managing expiration times 7-2 using for client web browsers 7-2 using with the Enable Content Assembly on Proxies feature 7-3 invalidation triggers. See invalidations rules. invalidations rules configuring 10-6 configuring lifetime 10-3 creating 10-6 defining request header matching criteria 10-4 defining the cached content to invalidate 10-4 example 10-6 for cache invalidation 10-1 triggering 10-2 iPlant Enterprise Servers selecting a log format 12-2

using ESI Surrogate-Control headers 9-3 using HTTP Lifetime Heuristic 9-6 using lifetime mechanisms 9-1 link tags using the Intelligent Browser Referencing feature 7-2 locked acceleration policies See signed acceleration policies. Log Format screen accessing 12-5 logs and NCSA Common (No Header) formatting convention 12-7 defining options 12-1 example 12-7 specifying log format 12-2 using hit logs 12-1

M
manuals finding documentation 1-3 for the WebAccelerator system 1-2 matching rules creating for an existing acceleration policy 5-1 defined 2-1 finding an exact match 5-2 using value groups 6-4 max-age directives defining stand-in period 4-23 obeying ESI Surrogate-Control header directives 9-3 meta characters, supporting for pattern matching 4-17 method parameter HTTP request data type 4-10 Microsoft Internet Information Services web servers selecting a log format 12-2 MultiConnect feature additional subdomains 7-5 and recommended usage 7-5 and required tasks before enabling 7-5 applying to content 7-5 configuring Subject Alternative Name entries 7-6 constructing a trusted SSL certificate 7-6 defined 7-5 enabling 7-6 example 7-6

J
J2EE and standard delivery acceleration policies 2-1 Java 2 Platform Enterprise Edition. See J2EE.

L
leaf nodes defined 3-6 matching according to priority 3-6 representing specific content 3-2 Level 1 Delivery acceleration policy 2-1 Level 2 Delivery acceleration policy 2-1 lifetime mechanisms 9-1 lifetime rules Maximum Age setting exceeding 4-26 lifetime rules and no-cache directives 4-19 and Use HTTP lifetime headers if present option 9-4 example 9-9 exceeding Maximum Age setting 4-26 obeying precedence for content lifetime 9-1 specifying a stand-in period settings 9-5 specifying client cache options 9-7 specifying content lifetime options 9-3 using cache request directives 9-3 using cache response directives 4-19 Index - 4

N
NCSA Combined log headers selecting a log format 12-2 NCSA Common (no header) log format customizing 12-7 NCSA Common log headers selecting a log format 12-2 Netscape servers selecting a log format 12-2

Index

No header line log headers selecting a log format 12-2 no-cache directives and lifetime rules 4-19 honoring 4-19 nodes identifying for the X-PvInfo response header 4-28 number randomizer for parameter value substitution 7-13 using in assembly rules 7-13

O
origin web servers using Surrogate-Control response header 4-22 overriding 7-15

P
parameter value substitutions and target definition 7-12 example 7-11 for content assembly 7-11 specifying a target definition for parameter value substitution 7-12 targeting embedded URLs for substitution 7-12 using in assembly rules 7-11 using source definition 7-12 parameters and structure 4-10 configuring parameter value substitution 7-12 path data types and precedence 5-2 supporting 4-15 path parameter HTTP request data type 4-6 path parameters using the question mark 5-2 path segment data types, supporting 4-16 path segment parameter HTTP request data type 4-7 path segments and segment keys 4-7 and segment ordinals 4-8 and segment parameters 4-7 paths and the question mark 5-3 PDF objects compressing 7-8 perform content assembly on proxies feature and the Intelligent Browser Referencing feature 7-3 Policies screen accessing 2-3 Policy Editor screen accessing 3-1 defined 3-2 Policy Tree and branch nodes 3-2 and leaf nodes 3-2

creating rules on a branch node 3-6 described 3-2 inheriting from a root node 3-6 matching according to leaf node priority 3-6 performing application matching on a leaf node 3-6 propagating rules 3-6 understanding rule inheritance 3-6 using 3-4 post data maximum size 4-1 precedence rules for application matching 5-2 for content lifetime 9-1 predefined acceleration policies defined 2-1 priority for leaf nodes on the Policy Tree 3-6 production copy of acceleration policy 2-6 protocol parameter HTTP request data type 4-9 protocols and supported types 4-1 proxy override rules defining parameters 8-5 proxy rules defined 8-1 defining parameters 8-1, 8-3 proxying rules and Always proxy requests for this node option 8-4 example 8-6 processing HTTP requests 4-2 processing responses 4-2 See also, proxy override rules. See also, proxy rules. publishing acceleration policies 2-10 pv tags using with the Intelligent Browser Referencing feature 7-2

Q
query parameter data types, supporting 4-15 query parameter HTTP request data type 4-6 query parameters for assembly using value substitution 7-11 query parameters for variation rules processing when ambiguous 6-5

R
random value substitutions conflicting with ESI markup 7-14 referrer data types, supporting 4-16 referrer parameter HTTP request data type 4-9 regular expressions supporting 4-15

Policy Management Guide for the BIG-IP WebAccelerator System

Index - 5

Index

request header matching criteria parameter described 10-4 specifying for cache invalidation 10-4 request restrictions and post data size 4-1 requests managing 2-6 requirements servicing client requests 4-1, 4-2 resources saving using variation rules 6-2 response codes S codes defined 4-26 serving content from Hot Cache 4-27 serving content from Smart Cache 4-26 response headers classifying responses 4-12 viewing X-PvInfo response headers 4-1, 4-25 response status codes basing caching behavior on 11-2 responses and the Rewrite Engine 4-13 caching 4-2 classifying 4-12 processing 4-1 sending ESI headers 9-3 responses cached rules basing response codes 11-2 defined 11-1 example 11-3 Rewrite Engine applying rewrite scripts 4-13 rewrite scripts managing responses 4-13 root node and inheritence 3-6 defined 3-6 rule inheritance understanding 3-6 rules inheriting through a branch node 3-6

creating 2-8 defined 2-2 importing 2-9 Smart Cache and response codes 4-26 source definitions for assembly rules 7-12 SSL certificates for the MultiConnect feature 7-6 stand-in period settings defined 9-5 defining for max-age directive 4-23 status codes cashing responses 11-2 structured parameters in request headers 4-10 subdomains and MultiConnect feature 7-5 Subject Alternative Name entries for MultiConnect feature 7-6 supported HTTP protocols 4-1 surrogate targeting 4-24 Surrogate-Control headers and ESI page assembly 4-22 and supported directives 4-22 system-wide maximum age settings and max age ESI Surrogate-Control header directive 4-23

T
target definitions defined 7-12 for assembly rules 7-12 target URLs configuring substitution for assembly rules 7-12 Technical Support web site 1-3 Time to Live. See TTL. traffic analysis using hit logs 12-1 Transfer-Encoding response headers and requirements for caching response 4-3 transform utility applying to responses 4-13 troubleshooting and the MultiConnect feature 7-6 exceeding a lifetime rules Maximum Age setting 4-26 using A codes 4-28 using C codes 4-27 using G codes 4-28 using R codes 4-28 using response codes 4-26 using S codes 4-26 using U codes 4-29 using X-PvInfo response headers 4-25

S
S codes defined 4-26 S10101 response code 4-26 script tags using the Intelligent Browser Referencing feature 7-2 segment keys 4-7 and extension parameter 4-6 segment ordinals 4-8 segment parameter ordinals 4-8 segment parameters 4-7 signed acceleration policies

Index - 6

Index

TTL and caching considerations 4-2 and compiled response 9-1

X
X-PvInfo response headers and A codes 4-28 and C codes 4-27 and G codes 4-28 and R codes 4-28 and S codes 4-26 and U codes 4-29 identifying nodes 4-28 viewing 4-1, 4-25

U
UCI and acceleration rules 6-1 and variation rules 6-1, 6-4 caching HTTP request elements 6-2 defined 6-1 using variation rules for 6-2 Unique Content Identifier. See UCI. unmatched HTTP requests during application matching 5-3 unnamed parameter HTTP request data type 4-7 unnamed query parameter data types for variation rules 6-5 unnamed query parameter data types, supporting 4-16 Use HTTP lifetime headers if present option 9-2, 9-4 user agent data types, supporting 4-16 user agent parameter HTTP request data type 4-9 user-defined acceleration policies defined 2-2 publishing 2-10

V
value groups defined 6-4 example 6-4 for matching rules 6-4 value substitution parameters configuring 7-12 example 7-12 variation rules and example 6-1 and required usage 6-2 and the UCI 6-4 conflicting rule parameters 6-5 creating example 6-7 matching to multiple parameters values 6-5 using to save cache resources 6-2 using value groups 6-4

W
wa prefixes and the MultiConnect feature 7-7 WC3 log headers selecting a log format 12-2 web application acceleration policies. See acceleration policies. Welcome screen for the Configuration utility 1-3

Policy Management Guide for the BIG-IP WebAccelerator System

Index - 7

Index

Index - 8