Application Acceleration and Optimization Guide vA5(1.0), Cisco 4700 Series Application Control Engine Appliance
Configuring an Optimization HTTP Parameter Map
Downloads: This chapterpdf (PDF - 304.0KB) The complete bookPDF (PDF - 4.47MB) | Feedback

Configuring an Optimization HTTP Parameter Map

Table Of Contents

Configuring an Optimization HTTP Parameter Map

Optimization HTTP Parameter Map Configuration Quick Start

Creating an Optimization HTTP Parameter Map

Configuring AppScope Performance Rate Parameters

Defining a String to Sort Requests for AppScope Reporting

Specifying Base File Anonymity Level

Controlling the Rebasing of Base Files

Specifying a Canonical URL Regular Expression

Configuring Static and Adaptive Cache Parameters

Modifying the Cache Key

Modifying the Canonical URL Portion of the Cache Key

Modifying the Query Parameter Part of a URL in the Cache Key

Configuring Time-Based Cache Object Expiration

Specifying Load-based Expiration for Cache Objects

Overriding Cache Requests or Response Headers

Specifying the Default Scripting Language on Condensed Content Pages

Specifying Delta Optimization Operating Parameters

Setting Cacheable Content and Objects for Delta Optimization

Specifying Delta Optimization Mode

Specifying the Freshness Period of Objects in the Client Browser

Removing Meta Elements from Documents

Bypassing FlashForward

Identifying HTTP Response Codes to Ignore

Setting the Parameter Summary Value of a Transaction Log Entry

Setting the Maximum Size of HTTP POST Data

Specifying a Server Header String

Controlling the Display of UTF-8 Characters

Where to Go Next


Configuring an Optimization HTTP Parameter Map


This chapter describes how to configure parameters on the Cisco 4700 Series Application Control Engine (ACE) appliance that adjust or control several optimization technologies based on the selections made in an associated action list. You can specify an optional optimization HTTP parameter list in an optimization HTTP policy map to identify the association between the action list and the parameter map. The optimization HTTP action list defines what to do while the optimization HTTP parameter map defines the specific details about how to accomplish the action.

This chapter contains the following major sections:

Optimization HTTP Parameter Map Configuration Quick Start

Creating an Optimization HTTP Parameter Map

Configuring AppScope Performance Rate Parameters

Specifying Base File Anonymity Level

Controlling the Rebasing of Base Files

Specifying a Canonical URL Regular Expression

Configuring Static and Adaptive Cache Parameters

Specifying the Default Scripting Language on Condensed Content Pages

Specifying Delta Optimization Operating Parameters

Specifying the Freshness Period of Objects in the Client Browser

Removing Meta Elements from Documents

Bypassing FlashForward

Identifying HTTP Response Codes to Ignore

Setting the Parameter Summary Value of a Transaction Log Entry

Setting the Maximum Size of HTTP POST Data

Specifying a Server Header String

Controlling the Display of UTF-8 Characters

Where to Go Next

Optimization HTTP Parameter Map Configuration Quick Start

Table 3-1 provides a quick overview of the steps required to configure an application acceleration and optimization parameter map. Each step includes the CLI command or a reference to the procedure required to complete the task. For a complete description of each feature and all the options associated with the CLI commands, see the sections following Table 3-1.

Table 3-1 Optimization HTTP Parameter Map Configuration Quick Start 

Task and Command Example

1. If you are operating in multiple contexts, observe the CLI prompt to verify that you are operating in the desired context. If necessary, change to the correct context.

host1/Admin# changeto C1
host1/C1#
 
        

The rest of the examples in this table use the Admin context unless otherwise specified. For details on creating contexts, see the Administration Guide, Cisco ACE Application Control Engine.

2. Enter global configuration mode.

host1/Admin# config
host1/Admin(config)#

3. Create an optimization HTTP parameter map.

host1/Admin(config)# parameter-map type optimization http 
OPTIMIZE_PARAM_MAP
host1/Admin(config-parammap-optmz)#

4. Configure application acceleration and optimization parameters in the parameter map as required. For example, enter:

host1/Admin(config-parammap-optmz)# canonical-url 
$(1)/$http_query_param(category)
host1/Admin(config-parammap-optmz)# cache key-modifier 
http://www$(1)
host1/Admin(config-parammap-optmz)# cache parameter 
$http_query_param(version)
host1/Admin(config-parammap-optmz)# delta all-user
host1/Admin(config-parammap-optmz)# basefile anonymous-level 25
host1/Admin(config-parammap-optmz)# exit
host1/Admin(config)#

5. Create a Layer 7 HTTP optimization policy map to associate an existing action list and parameter map and to configure the specified actions. see Chapter 4, Configuring a Traffic Policy for HTTP Optimization for details.

host/Admin(config)# policy-map type optimization http first-match 
L7OPTIMIZATION_POLICY
host/Admin(config-pmap-optmz)# class L7SLBCLASS
host1/Admin(config-pmap-optmz-c)#
host1/Admin(config-pmap-optmz-c)# action ACT_LIST1 parameter 
OPTIMIZE_PARAM_MAP
host1/Admin(config-pmap-optmz-c)# exit

6. (Optional) Save your configuration changes to Flash memory.

host1/Admin# copy running-config startup-config

Creating an Optimization HTTP Parameter Map

You can configure a parameter map to specify optimization-related commands that pertain to application acceleration and optimization functions performed by the ACE. A parameter map groups the functions that adjust or control the actions specified in an associated action list.

After you configure the parameter map, associate it with an action list in a policy map. For details about associating a parameter map with an action list in a policy map, see Chapter 4, Configuring a Traffic Policy for HTTP Optimization.

To create an optimization HTTP parameter map so that you can configure specific application acceleration and optimization functions, use the parameter-map type optimization http command in global configuration mode.

The syntax of this command is as follows:

parameter-map type optimization http map_name

For the map_name argument, enter a unique name as an unquoted text string with no spaces and a maximum of 64 alphanumeric characters.

For example, to create an optimization HTTP parameter map, enter:

host1/Admin(config)# parameter-map type optimization http 
OPTIMIZE_PARAM_MAP
host1/Admin(config-parammap-optmz)#
 
   

To remove the parameter map from the configuration, enter:

host1/Admin(config)# no parameter-map type optimization http 
OPTIMIZE_PARAM_MAP
 
   

Use one or more of the commands in the sections in this chapter to define the optimization HTTP parameter map.

You can provide a brief summary of the optimization HTTP parameter map by using the description command in parameter map optimization configuration mode. The syntax of this command is as follows:

description text

For the text argument, enter an unquoted text string with a maximum of 240 alphanumeric characters including spaces.

For example, to specify a description of an optimization HTTP parameter map, enter the following command:

host1/Admin(config)# parameter-map type optimization http 
OPTIMIZE_PARAM_MAP
host1/Admin(config-parammap-optmz)# description optimization-type 
parameter map
 
   

To remove the description from the optimization HTTP parameter map, enter:

host1/Admin(config-parammap-optmz)# no description
 
   

Configuring AppScope Performance Rate Parameters

To control the AppScope features of the optional Cisco AVS 3180A Management Station that measure application acceleration and optimization performance, use the appscope optimize-rate-percent command in parameter map optimization configuration mode.

To configure the ACE to upload the statistical log information to the optional Cisco AVS 3180A Management Station, use the appscope-log now command in optimize mode (see Chapter 5, Configuring Global Optimization Settings).


Note See Appendix A, Using the Optional Cisco AVS 3180A Management Station for Reporting, for details on AppScope running on a Cisco AVS 3180A Management Station.

The syntax of this command is as follows:

appscope optimize-rate-percent value passthru-rate-percent value

The keywords, arguments, and options are:

value—Specifies the percentage of all requests (or sessions) to be sampled for performance with acceleration (optimization) applied. All applicable optimizations for the class will be performed. Valid values are from 0 to 100 percent. The default is 10 percent. This value plus the passthru-rate-percent value must not exceed 100.

passthru-rate-percent valueSpecifies the percentage of all requests (or sessions) to be sampled for performance without optimization. No optimizations for the class will be performed. Valid values are from 0 to 100 percent. The default is 10 percent. This value plus the optimize-rate-percent value must not exceed 100.

For example, to specify a percentage of all requests (or sessions) to be sampled for performance with acceleration and without optimization applied by AppScope, enter:

host1/Admin(config-parammap-optmz)# appscope optimize-rate-percent 50 
passthru-rate-percent 50

To revert to the default rate AppScope performance rate settings of 10 percent, enter:

host1/Admin(config-parammap-optmz)# no appscope optimize-rate-percent 
50 passthru-rate-percent 50

Defining a String to Sort Requests for AppScope Reporting

To define a string to sort requests for AppScope reporting, use the request-grouping-string command in parameter map optimization configuration mode. The string can contain a URL regular expression that defines a set of URLs in which URLs that differ only by their query parameters are to be treated as separate URLs in AppScope reports.

Typically, in an AppScope report organized by URL, matching URLs that differ only in their query parameters are treated as the same URL and are not listed on separate lines. Use the request-grouping-string command to specify that all URL variations based on query parameters are to be treated as separate URLs for reporting purposes. Each variation will appear on a separate line in the report.

The syntax for this command is as follows:

request-grouping-string string

The string argument contains a URL regular expression that defines a set of URLs. The maximum string value is 255 characters. The string can contain the parameter expander functions listed in Table 3-3.

For example, to define a string that is used to make the URLs http://server/catalog.asp?region=asia and http://server/catalog.asp?region=america into two separate reporting categories, enter:

host1/Admin(config-parammap-optmz)# request-grouping-string 
http_query_param(region)
 
   

To remove a request grouping string, enter:

host1/Admin(config-parammap-optmz)# no request-grouping-string

Specifying Base File Anonymity Level

The ACE incorporates an anonymous base file feature to address user privacy concerns. This feature, which is an all-user delta optimization option for the delta command (see the "Specifying Delta Optimization Operating Parameters" section), enables customers to use the ACE to deliver personalized confidential content such as online trading accounts, banking statements, and business accounts. Typically, customers use this feature with SSL to enable secure and private condensed content delivery.

For details on base file anonymity level, see Chapter 1, Application Acceleration and Optimization Overview.

By default, the base file anonymity level is disabled. To define the base file anonymity level for the all-user delta optimization method, use the basefile anonymous-level command in parameter map optimization configuration mode.

The syntax for this command is as follows:

basefile anonymous-level value

The value argument specifies the base file anonymity level for the all-user delta optimization method. Valid values are from 0 to 50. The default is a value of 0 (disables anonymity).

For example, to specify a base file anonymity level of 25, enter:

host1/Admin(config-parammap-optmz)# basefile anonymous-level 25
 
   

To revert to the default base file anonymity level of 0, enter:

host1/Admin(config-parammap-optmz)# no basefile anonymous-level

Controlling the Rebasing of Base Files

Rebasing refers to the process of updating the base file that is used for generating deltas between subsequent content retrievals. Because the base content of a site often changes over a period of time, the size of the generated deltas can grow relatively large. To maintain the effectiveness of the delta optimization process, the base files are automatically updated as required.

To control the rebasing of base files by the ACE, use the rebase command in parameter map optimization configuration mode.

Smart Rebasing enables the ACE to instantly rebase URLs when appropriate and to maintain a copy of the old base page so that subsequent requests for it can be fulfilled. This function improves overall ACE performance and content acceleration because it ensures that delta optimization occurs at all times, even when a rebase occurs.

For details on Smart Rebasing, see Chapter 1, Application Acceleration and Optimization Overview.

The syntax for this command is as follows:

rebase {delta-percent value | flashforward-percent value | history-size value | modification-cooloff-period value | reset-period value}

The arguments, keywords, and options are:

delta-percent value—Specifies the delta threshold at which rebasing is triggered. This number represents the size of a page delta relative to the page total size, expressed as a percentage. Valid values are from 0 to 10000 percent. The default threshold is 50 percent.

flashforward-percent value—Specifies a rebase, based on the percent of FlashForwarded URLs in the response. Rebasing is triggered when the difference between the percentages of FlashForwarded URLs in the delta response and the base file exceed the threshold. Valid values are from 0 to 10000 percent. The default is 50 percent. The flashforward-percent keyword provides a threshold control for rebasing based on the percent of FlashForwarded URLs in the response. Where the delta-percent keyword triggers rebasing when the delta response size exceeds the threshold as a percentage of the base file size; the flashforward-percent keyword triggers rebasing when the difference between the percentages of FlashForwarded URLs in the delta response and the base file exceed the threshold.

history-size value—Controls how much history is stored before resetting. Once the sample collection reaches the specified history size, the ACE resets all rebase control parameters to zero and starts over. This keyword prevents the base file from becoming too rigid. That is, if a base file has served approximately one million pages, then it would take another half million unfavorable responses before the base file can be rebased. Valid values are from 10 to 2147483647 pages. The default value for this parameter is 1000 pages.

modification-cooloff-period value—Specifies the time, in seconds, after the last modification before performing a rebase. Valid values are from 1 to 14400 seconds (four hours).The default is 14400 seconds.

reset-period value—Specifies the period for performing a meta data refresh Valid values are from 1 to 900 seconds (15 minutes). The default is 900 seconds.

For example, to specify a rebase, based on a percentage of 1000 FlashForwarded URLs in the response, enter:

host1/Admin(config-parammap-optmz)# rebase flashforward-percent 1000
 
   

To revert to a default rebase setting, enter:

host1/Admin(config-parammap-optmz)# no rebase flashforward-percent 

Specifying a Canonical URL Regular Expression

The canonical URL function in a parameter map is used to specify a base file selection policy. The canonical URL function specifies a regular expression that is used to match a variety of actual URLs. All matched URLs share a single base file.

The ACE uses the canonical URL function to modify a parameterized request to eliminate the question mark (?) and the characters that follow to identify the general part of the URL. This general URL is then used to create the base file. The ACE uses the canonical URL to map multiple parameterized URLs to a single canonical URL.

For details on the canonical URL function, see Chapter 1, Application Acceleration and Optimization Overview.

To specify a string containing a canonical URL regular expression that defines a set of URLs to which the parameter map applies, use the canonical-url command in parameter map optimization configuration mode. At least one URL must be specified by using the canonical-url command.

The syntax for this command is as follows:

canonical-url parameter-expander-function

The parameter-expander-function argument specifies parameter expander functions that evaluate to strings. The maximum string value is 255 characters. Table 3-3 lists the parameter expander functions that you can use.

For example, to specify a string that contains a canonical URL regular expression, enter:

host1/Admin(config-parammap-optmz)# canonical-url 
$(1)/$http_query_param(category)
 
   

To delete the string that contains a canonical URL regular expression, enter:

host1/Admin(config-parammap-optmz)# no canonical-url

Configuring Static and Adaptive Cache Parameters

This section describes how to configure both static and dynamic adaptive caching in a parameter map. If a traffic class is found that matches a request, its cache policy is inspected and applied to that object.

There are two aspects of all cached objects:

The key under which the object is cached. The key is controlled by the parameter map commands canonical-url (described in the "Specifying a Canonical URL Regular Expression" section), cache key-modifier, and cache parameter. For details about the cache key-modifier and cache parameter commands, see the "Modifying the Cache Key" section.

The expiration behavior of the cached content. The cache content expiration can be a time-based expiration or a load-based expiration. For details about configuring the expiration setting, see the "Configuring Time-Based Cache Object Expiration" and "Specifying Load-based Expiration for Cache Objects" sections.

For details about dynamic caching, see Chapter 1, Application Acceleration and Optimization Overview.

This section contains the following topics:

Modifying the Cache Key

Configuring Time-Based Cache Object Expiration

Specifying Load-based Expiration for Cache Objects

Overriding Cache Requests or Response Headers

Modifying the Cache Key

The cache object key is the unique identifier that is used to identify a cached object to be served to the client, replacing a trip to the origin server.

The HTTP protocol is not session based; each request for every page and dependent object is entirely autonomous with no state preserved between requests. This situation forces web application developers to use session tracking techniques like cookies. It is sometimes necessary to include more in the cache key than simply the URL.

The key that the ACE uses for any given requesting URL comprises one or more of the following two components, which are shown in Figure 3-1:

Canonical URL—The URL portion up to a question mark (?). The canonical URL can be modified by the cache key-modifier command.

Query parameters—The URL portion after a question mark (?). Query parameters can be modified by the cache parameter command, which can be used to include selected query parameters, a cookie value, an HTTP header value, or other values.

You can modify the cache key by defining the following commands in optimization parameter mode:

cache key-modifier

cache parameter

Figure 3-1 How the Cache Key is Formed from a URL

This section contains the following topics:

Modifying the Canonical URL Portion of the Cache Key

Modifying the Query Parameter Part of a URL in the Cache Key

Modifying the Canonical URL Portion of the Cache Key

You can modify the canonical form of a URL—that is, the portion before the question mark (?)—for use in forming the cache key, by using the cache key-modifier command in parameter map optimization configuration mode. This command specifies a regular expression containing embedded variables that are expanded by the ACE. You can include zero or more instances of the (number) variable, as described in Table 3-3.

The expanded string that results from the cache key-modifier command replaces the default canonical URL portion of the cache key. If you do not specify the cache key-modifier command, the canonical URL is used as the default value for the URL portion of the cache key (there may also be a query parameter portion).

The following example uses the cache key-modifier command to strip out the portion of a URL added by a content delivery network (CDN):

host1/Admin(config)# class-map type http loadbalance match-any 
Example1_Classmap
host1/Admin(config-cmap-http-lb)# match http url 
.*mycdn\.net.*www(.*\.gif)
host1/Admin(config-cmap-http-lb)# exit
host1/Admin(config)# parameter-map type optimization http 
OPTIMIZE_PARAM_MAP1
host1/Admin(config-parammap-optmz)# cache key-modifier http://www$(1)
host1/Admin(config-parammap-optmz)# exit
host/Admin(config)# policy-map type optimization http first-match 
L7OPTIMIZATION_POLICY
host/Admin(config-pmap-optmz)# class Example1_Classmap
host1/Admin(config-pmap-optmz-c)# action ACT_LIST1 parameter 
OPTIMIZE_PARAM_MAP1
 
   

The match http url command in the Example1_Classmap class map specifies a regular expression that identifies URLs for which this traffic class is to be used. The regular expression defines the following sequence: Start with any number of any characters, up to the literal mycdn.net, followed by any sequence of characters up to the literal www, followed by a subexpression group (in parentheses) that ends the URL.

The subexpression group in the regular expression is any sequence of characters followed by the literal .gif, which must end the string. The subexpression group can be expanded by using the (number) syntax. The group is the first and only subexpression, so it can be referenced by (1).

The cache key-modifier command replaces the original URL with a new string that begins with "http://www" and ends with the value of subexpression group 1 from the previous line. The effect is to strip out the portion of the URL that was used for redirection to a CDN.

The cache key-modifier command transforms a matched URL such as the following:

http://a188.g.mycdn.net/f/188/920/1d/www.mysite.com/images/logo.gif
 
   

to this string:

http://www.mysite.com/images/logo.gif
 
   

The syntax for the command is as follows:

cache key-modifier {string parameter_expander_function}

The arguments are:

string—A regular expression. Enter an unquoted text string with no spaces and a maximum of 255 alphanumeric characters. Alternatively, you can enter a text string with spaces if you enclose the entire string in quotation marks ("). The ACE supports the use of regular expressions for matching string expressions. Table 3-2 lists the supported characters that you can use for matching string expressions.

parameter_expander_function—A parameter expander function that evaluate to strings. The maximum string value is 255 characters. Table 3-3 lists the parameter expander functions that you can use.

For example, enter:

host1/Admin(config-parammap-optmz)# cache key-modifier http://www$(1)
 
   

To remove a cache key modifier, enter:

host1/Admin(config-parammap-optmz)# no cache key-modifier

Table 3-2 Special Characters for Matching String Expressions 

Convention
Description

.

One of any character.

.*

Zero or more of any character.

\.

Period (escaped).

[charset]

Match any single character from the range.

[^charset]

Do not match any character in the range. All other characters represent themselves.

()

Expression grouping.

(expr1 | expr2)

OR of expressions.

(expr)*

0 or more of expression.

(expr)+

1 or more of expression.

expr{m,n}

Repeat the expression between m and n times, where m and n from 1 to 255.

expr{m}

Match the expression exactly m times. The range for m is from 1 to 255.

expr{m,}

Match the expression m or more times. The range for m is from 1 to 255.

\a

Alert (ASCII 7).

\b

Backspace (ASCII 8).

\f

Form-feed (ASCII 12).

\n

New line (ascii 10).

\r

Carriage return (ASCII 13).

\t

Tab (ASCII 9).

\v

Vertical tab (ASCII 11).

\0

Null (ASCII 0).

\\

Backslash.

\x##

Any ASCII character as specified in two-digit hexadecimal notation.


Table 3-3 Parameter Expander Functions 

Variable
Description
$(number)

Expands to the corresponding matching subexpression (by number) in the URL pattern. Subexpressions are marked in a URL pattern using parentheses (). The numbering of the subexpressions begins with 1 and is the number of the left-parenthesis "(" counting from the left. You can specify any positive integer for the number. $(0) matches the entire URL. For example, if the URL pattern is ((http://server/.*)/(.*)/)a.jsp, and the URL that matched it is the following:

http://server/main/sub/a.jsp?category=shoes&session=99999, then the following are correct:

$(0) = http://server/main/sub/a.jsp

$(1) = http://server/main/sub/

$(2) = http://server/main

$(3) = sub

If the specified subexpression does not exist in the URL pattern, then the variable expands to the empty string.

$http_query_string()

Expands to the value of the whole query string in the URL. For example, if the URL is

http://myhost/dothis?param1=value1&param2=value2

then the following is correct:

$http_query_string() = param1=value1&param2=value2

This function applies to both GET and POST requests.

$http_query_param(query- 
param-name)
 
        

this obsolete syntax is also supported:

$param(query-param-name)

Expands to the value of the named query parameter (case sensitive). For example, if the URL is

http://server/main/sub/a.jsp?category=shoes&session=99999

then the following are correct:

$http_query_param(category) = shoes

$http_query_param(session) = 99999

If the specified parameter does not exist in the query, then the variable expands to the empty string. This function applies to both GET and POST requests.

$http_cookie(cookie-name)

Evaluates to the value of the named cookie. For example, $http_cookie(cookiexyz). The cookie name is case sensitive.

$http_header(request-header-name)

Evaluates to the value of the specified HTTP request header. In the case of multivalued headers, it is the single representation as specified in the HTTP specification. For example, $http_header(user-agent). The HTTP header name is not case sensitive.

$http_method()

Evaluates to the HTTP method used for the request, such as GET or POST.

Boolean Functions:

$http_query_param_present 
(query-param-name)
$http_query_param_notpresent 
(query-param-name)
$http_cookie_present(cookie- 
name)
$http_cookie_notpresent(cookie- 
name)
$http_header_present(request- 
header-name)
$http_header_notpresent(request-h
eader-name)
$http_method_present(method-name)
$http_method_notpresent(method- 
name)

Evaluates to a Boolean value: True or False, depending on the presence or absence of the element in the request. The elements are a specific query parameter (query-param-name), a specific cookie (cookie-name), a specific request header (request-header-name), or a specific HTTP method (method-name). All identifiers are case sensitive except for the HTTP request header name.


Modifying the Query Parameter Part of a URL in the Cache Key

The cache parameter command modifies the query parameter part of a URL—that is, the portion after the question mark (?)—for use in forming the cache key. This command specifies an expression that includes one or more parameter expander functions if you want to modify the parameter portion of the cache key.

The cache parameter command specifies one or more parameter expander functions that evaluate to strings. These strings are appended to the canonical URL to form the last portion of the cache key. The parameter expander functions are listed in Table 3-3.

The string specified in the cache parameter command replaces the default query parameter that is used in the cache key. If the cache parameter command is not specified, the query parameter portion of the URL is used as the default value for this portion of the cache key. The canonical URL, which could be possibly modified by entering the cache key-modifier command, is the first part of the cache key.

The following example shows how to use the cache parameter command to create a different instance of the dynamically cached page for each value of the "version" query parameter:

host1/Admin(config)# class-map type http loadbalance match-any 
Example2_Classmap
host1/Admin(config-cmap-http-lb)# match http url 
.*dyncache/page3\.asp.*
host1/Admin(config-cmap-http-lb)# exit
host1/Admin(config)# parameter-map type optimization http 
OPTIMIZE_PARAM_MAP2
host1/Admin(config-parammap-optmz)# cache parameter 
$http_query_param(version)
host1/Admin(config-parammap-optmz)# exit
host/Admin(config)# policy-map type optimization http first-match 
L7OPTIMIZATION_POLICY
host/Admin(config-pmap-optmz)# class Example2_Classmap
host1/Admin(config-pmap-optmz-c)# action ACT_LIST2 parameter 
OPTIMIZE_PARAM_MAP2
 
   

The match http url command in the Example2_Classmap class map specifies a regular expression that identifies URLs for which this traffic class is to be used. The sequence is to start with any number of any characters, up to the literal dyncache/page3.asp, followed by any sequence of characters up to the end of the URL.

The cache parameter command sets the value of the query parameter portion of the cache key to the value of $http_query_param(version). The default value of the query parameter portion of the cache key is the entire query parameter portion of the URL.

This configuration extracts from a matched URL such as the following:

http:www.mysite.com/dyncache/page3.asp?session=nqyfxe46&m=int&version=12
 
   

the 12 string, which is the value of the version parameter. This string is appended to the URL portion of the cache key to form the complete cache key.

The syntax for the command is as follows:

cache parameter parameter_expander_function

The parameter-expander-function argument specifies a parameter expander function that evaluates to strings. Use the forwardslash (/) character when combining multiple parameter expander functions (for example, cache parameter $http_cookie(ID)/$http_query_param(category)). The maximum string value is 255 characters. Table 3-3 lists the parameter expander functions that you can use.

For example, to set the value of the query parameter portion of the cache key, enter:

host1/Admin(config-parammap-optmz)# cache parameter $http_query_param 
(version)
 
   

To remove a cache parameter, enter:

host1/Admin(config-parammap-optmz)# no cache parameter

Configuring Time-Based Cache Object Expiration

To define the ACE cache freshness settings, use the cache ttl command in parameter map optimization configuration mode. This command sets the maximum time (max keyword) or the minimum time (min keyword) in seconds that an object without an explicit expiration time should be considered fresh. The percent keyword sets the percent of an object's age at which an embedded object without an explicit expiration time is considered fresh.

To control the period of time that objects in the client's browser remain fresh, use the expires-setting command in parameter map optimization configuration mode. For more information, see the "Specifying the Freshness Period of Objects in the Client Browser" section.

The syntax for this command is as follows:

cache ttl {min time | max time | percent value}

The keywords, arguments, and options are:

min time—Specifies the minimum time in seconds that an object without an explicit expiration time should be considered fresh. The min keyword specifies the minimum time that the content can be cached for, which corresponds to the life of the content. For example, for a new item that is valid for 3 hours, this value would be 3 x 60 x 60 = 10800 seconds. For static caching (the flashforward-object action), this value should normally be 0. For dynamic caching (the cache dynamic action), this value should be set to indicate how long the ACE should cache the page. Valid values are from 0 to 2147483647 seconds. The default is 0.

max time—Specifies the maximum time in seconds that an object without an explicit expiration time should be considered fresh. The max keyword determines how the ACE handles the case when the object has passed its cache minimum time-to-live value.Valid values are from 0 to 2147483647 seconds. The default is 300 seconds.

percent value—Specifies the percentage of an object's age at which an embedded object without an explicit expiration time is considered fresh. Valid values are from 0 to 100 percent. The default is 0 percent.

For example, to specify a minimum time-to-live (TTL) value of 1000 seconds that the content can be cached for, enter:

host1/Admin(config-parammap-optmz)# cache ttl min 1000
 
   

To revert to a default cache TTL value, enter:

host1/Admin(config-parammap-optmz)# no cache ttl min 

Specifying Load-based Expiration for Cache Objects

You can use performance assurance with a load-based expiration to set when an object in the cache can expire (excluding the natural process of cache pruning). In this case, the origin server's load determines when the object expires.

This type of expiration allows you to dynamically increase the TTL of cached responses if the current response time (average computed over a short time window) from the origin servers is larger than the average response time (average computed over a longer time window) by a threshold amount. Similarly, the TTL is dynamically decreased if the reverse holds true. The starting value for the cache TTL is the cache ttl min value (see the "Configuring Time-Based Cache Object Expiration" section), or 0 if not specified. The purpose of a moving average-based calculation is to allow the cache to respond to trends in usage patterns, smoothing out uncharacteristic spikes.

To control a load-based expiration for the cache, use the server-load command in parameter map optimization configuration mode.

The syntax for this command is as follows:

server-load {trigger-percent value | ttl-change-percent value}

The keywords, options, and arguments are:

trigger-percent value—Defines the threshold that triggers a change in the cache TTL. This keyword enables the ACE to monitor the server load in real time and make intelligent closed loop content expiration decisions so that site performance is maximized and existing hardware resources are used most efficiently, even during periods of peak traffic load. Valid values are from 0 to 100 percent. The default is 20 percent.

ttl-change-percent value—Defines the percentage by which the cache TTL is increased or decreased in response to a change in the server load. For example, if this value is set to 20, the current TTL for a particular response is 300 seconds, and if the current server response time exceeds the trigger threshold, then the cache TTL for the response is raised to 360 seconds (which is a 20 percent increase). Valid values are from 0 to 100 percent. The default is 20 percent.

For example, to specify a threshold trigger of 50 percent, enter:

host1/Admin(config-parammap-optmz)# server-load trigger-percent 50
 
   

To revert to a default setting of 20 percent, enter:

host1/Admin(config-parammap-optmz)# no server-load trigger-percent 

Overriding Cache Requests or Response Headers

To override client request headers (primarily for embedded objects), use the cache-policy request command in parameter map optimization configuration mode.

The syntax for this command is as follows:

cache-policy request {override-all | override-cache-ctl-no-cache}

The keywords are:

override-all—Specifies that all cache request headers are ignored.

override-cache-ctl-no-cacheOverrides the Cache-Control: no cache HTTP header from a request. This keyword is used for a flashforward-object command action (see Chapter 2, Configuring an Optimization HTTP Action List). Typically, if a cache control request header states that there is no cache, the ACE will not cache this object. The override-cache-ctl-no-cache keyword instructs the ACE to ignore the Cache-Control: no cache header from the request side.

For example, to instruct the ACE that all cache request headers are ignored, enter:

host1/Admin(config-parammap-optmz)# cache-policy request override-all
 
   

To remove a cache policy request selection, enter:

host1/Admin(config-parammap-optmz)# no cache-policy request 
override-all
 
   

To override origin server response headers (primarily for embedded objects), use the cache-policy response command in parameter map optimization configuration mode.

The syntax for this command is as follows:

cache-policy response {override-all | override-cache-ctl-private}

The keywords are:

override-all—Specifies that all cache response headers are ignored.

override-cache-ctl-private—Overrides the Cache-Control: private HTTP header from a response. This keyword is used for a flashforward-object command action (see Chapter 2, Configuring an Optimization HTTP Action List) and is equivalent to static object caching. Typically, if a cache control response header states that it is private, the response headers will make the object not cacheable. The override-cache-ctl-private keyword instructs the ACE to ignore the Cache-Control: private HTTP header from a response.

For example, to instruct the ACE that all cache response headers are ignored, enter:

host1/Admin(config-parammap-optmz)# cache-policy response override-all
 
   

To remove a cache policy response selection, enter:

host1/Admin(config-parammap-optmz)# no cache-policy response 
override-all

Specifying the Default Scripting Language on Condensed Content Pages

To configure the ACE to recognize the scripting language used on condensed content pages, either JavaScript or Visual Basic, use the clientscript-default command in parameter map optimization configuration mode.

The syntax for this command is as follows:

clientscript-default {javascript | vbscript}

The keywords are:

javascript—Sets the default scripting language to JavaScript (default).

vbscript—Sets the default scripting language to Visual Basic.

For example, to set the default scripting language to Visual Basic, enter:

host1/Admin(config-parammap-optmz)# clientscript-default vbscript
 
   

To revert to the default JavaScript scripting language, enter:

host1/Admin(config-parammap-optmz)# no clientscript-default vbscript

Specifying Delta Optimization Operating Parameters

The ACE applies several optimization technologies to accelerate web application performance. You can configure the delta optimization operating parameters that affect how the ACE handles cacheable content and objects. You can also control the delta optimization mode to determine whether the web pages to be condensed are common to all users or personalized for each individual user.

This section contains the following topics:

Setting Cacheable Content and Objects for Delta Optimization

Specifying Delta Optimization Mode

Setting Cacheable Content and Objects for Delta Optimization

To configure the delta optimization operating parameters on the ACE, use the delta command in parameter map optimization configuration mode.

The syntax for this command is as follows:

delta {cacheable-content | exclude {iframes | mime-type mime-type | non-ascii | scripts} | first-visit | page-size {min value | max value}

The keywords and options are:

cacheable-content—Enables the delta optimization of the cacheable content. Typically, the ACE detects cacheable content and prevents its delta optimization.

exclude—Defines the cacheable objects that should not be delta optimized.

iframes—Specifies that Inline frames (IFRAME tags) should not be delta optimized.

mime-type mime-type—Specifies the Multipurpose Internet Mail Extension (MIME)-type messages that should not be delta optimized (such as image/Jpeg, text/html, application/msword, and audio/mpeg).

non-ascii—Specifies that non-ACII data should not to be delta optimized. Specify this keyword if the content has UTF8 characters (see the "Controlling the Display of UTF-8 Characters" section). This excludes such characters from Delta optimization but the rest of that page can still be delta optimized.

scripts—Specifies that JavaScript should not to be delta optimized.

first-visit—Enables delta optimization on the first visit to a web page.

page-size—Sets the minimum and maximum page size, in bytes, for delta optimization.

min value—Specifies the minimum page size, in bytes, for delta optimization. Valid values are from 1 to 250000 bytes. The default is 1024 bytes.

max value—Specifies the maximum page size, in bytes, for delta optimization. Valid values are from 1024 to 250000 bytes. The default is 250000 bytes.

For example, to specify the MIME-type messages that should not be delta optimized, enter:

host1/Admin(config-parammap-optmz)# delta exclude mime-type audio/mpeg
 
   

To disable a delta optimization operating parameter on the ACE, enter:

host1/Admin(config-parammap-optmz)# no delta exclude mime-type 
audio/mpeg

Specifying Delta Optimization Mode

Delta optimization mode specifies whether the web pages to be condensed are common to all users or personalized for individual users, which determines what kind of page deltas are generated by the ACE.

The ACE supports two delta optimization modes:

All-user mode

Per-user mode

For details on each delta optimization mode, see Chapter 1, Application Acceleration and Optimization Overview.

To control the delta optimization mode used by the ACE, use the other delta command in parameter map optimization configuration mode (see the "Setting Cacheable Content and Objects for Delta Optimization"section).

The syntax for this command is as follows:

delta {all-user | per-user}

The keyword are:

all-user—Specifies that the corresponding URLs are to be condensed by using the All-user delta optimization mode. This is the default.

per-user—Specifies that the corresponding URLs are to be condensed by using the Per-user delta optimization mode.

For example, to specify that the corresponding URLs are to be delta optimized using the Per-user mode, enter:

host1/Admin(config-parammap-optmz)# delta per-user
 
   

To revert to the default All-user delta optimization mode, enter:

host1/Admin(config-parammap-optmz)# no delta per-user

Specifying the Freshness Period of Objects in the Client Browser

To control the period of time that objects in the client's browser remain fresh, use the expires-setting command in parameter map optimization configuration mode. The expires-setting command instructs the ACE to insert an Expires response header with a time value for an object. It is not necessary to configure this command when specifying the flashforward command in an action list because, in this case, the ACE always inserts a long time value in the Expires header for the transformed object. The expires-setting command is typically used when you are not using FlashForward but want to achieve the FlashForward affect by making all of the embedded objects perceived as being fresh by the browser.

For details on FlashForward, see Chapter 1, Application Acceleration and Optimization Overview).

The syntax for this command is as follows:

expires-setting {cachettl | time-to-live seconds | unmodified}

The keywords and options are:

cachettl—Sets the freshness similar to FlashForwarded objects and uses the minimum and maximum settings configured by the cache ttl command (if set). See the "Configuring Time-Based Cache Object Expiration" section.

time-to-live seconds—The duration that objects in the client's browser remain fresh. Valid entries are from 0 to 2147483647 seconds.

unmodified—Disables browser object freshness control (default).

For example, to specify that the ACE use the settings configured by the cache ttl command, enter:

host1/Admin(config-parammap-optmz)# expires-setting cachettl
 
   

To remove an expiration setting, enter:

host1/Admin(config-parammap-optmz)# no expires-setting cachettl

Removing Meta Elements from Documents

By default, the ACE includes HTML Meta elements in documents. To configure the ACE to remove HTML Meta elements from documents to prevent them from being condensed, use the extract meta command in parameter map optimization configuration mode.

The syntax for this command is as follows:

extract meta

For example, to remove HTML Meta elements from documents, enter:

host1/Admin(config-parammap-optmz)# extract meta
 
   

To include HTML Meta elements in documents, enter:

host1/Admin(config-parammap-optmz)# no extract meta

Bypassing FlashForward

FlashForward object acceleration extends the ACE's bandwidth usage reduction and download acceleration benefits to objects that are embedded within HTML pages. This feature combines local object storage with dynamic renaming of embedded objects to enforce object freshness within the parent HTML page. For details on FlashForward, see Chapter 1, Application Acceleration and Optimization Overview.

To configure the ACE to bypass FlashForward for stale embedded objects, use the flashforward refresh-policy command in parameter map optimization configuration mode.

The syntax for this command is as follows:

flashforward refresh-policy {all | direct}

The keywords are:

all—Allows FlashForward to indirectly refresh embedded objects (default)

direct—Bypasses FlashForward for stale embedded objects so that they are directly refreshed.

Request headers that the ACE sends to the origin server for stale embedded objects (indirect GET) may not be accepted by the origin server and may cause errors. In this case, specify direct to prevent this behavior.


Note By default, FlashForward is disabled. You must enabled it by specifying the following commands in action list optimization mode: flashforward and flashforward-object (for embedded objects). See Chapter 2, Configuring an Optimization HTTP Action List.

For example, to bypass FlashForward for stale embedded objects, enter:

host1/Admin(config-parammap-optmz)# flashforward refresh-policy direct
 
   

To revert to the default of allowing FlashForward to indirectly refresh embedded objects, enter:

host1/Admin(config-parammap-optmz)# no flashforward refresh-policy

Identifying HTTP Response Codes to Ignore

You can specify a comma-separated list of HTTP response codes for which the response body must not be read (ignored) by using the ignore-server-content command in parameter map optimization configuration mode. For example, a response code value of 302 directs the ACE to ignore the response body in the case of a 302 (redirect) response from the origin server.

The syntax of this command is as follows:

ignore-server-content value

The value argument specifies the response code as an unquoted text string with a maximum of 64 alphanumeric characters.

For example, to specify a response code value of 302 to ignore, enter:

host1/Admin(config-parammap-optmz)# ignore-server-content 302
 
   

To remove one or more response codes to ignore, enter:

host1/Admin(config-parammap-optmz)# no ignore-server-content

Setting the Parameter Summary Value of a Transaction Log Entry

To set the maximum number of bytes that are logged for each parameter value in the parameter summary of a transaction log entry in the statistics log, use the parameter-summary command in parameter map optimization configuration mode.

The syntax of this command is as follows:

parameter-summary parameter-value-limit bytes

The bytes argument sets the maximum number of bytes that are logged for each parameter value in the parameter summary of a transaction log entry in the statistical log. If a parameter value is longer than this limit, it is truncated at the specified parameter limit. Valid values are from 0 to 10,000 bytes. The default is 100 bytes.

For example, to specify a value of 5000 bytes as the parameter summary value, enter:

host1/Admin(config-parammap-optmz)# parameter-summary 
parameter-value-limit 5000
 
   

To revert to the default of 100 bytes as the parameter summary value, enter:

host1/Admin(config-parammap-optmz)# no parameter-summary 
parameter-value-limit

Setting the Maximum Size of HTTP POST Data

An HTTP POST can send a very large (effectively unlimited) amount of data; in an extreme case, the client can just keep sending a stream of data for the server to handle. In order to parse and inspect the POST data, the ACE needs to load the data into a buffer in memory.

There are two types of standard HTTP form POST operations. They are distinguished by the value in the Content-Type header:

application/x-www-form-urlencoded—This type of POST represents the majority of all HTTP POSTs. This is just a standard POST of a web page form.

multipart/form-data—This type of POST is much less common. Its main purpose is to allow browser users to upload files to a website or application. For example, if you use a web-based email program, and you want to attach a file to an e-mail that you are sending, the upload of the file is done by using this type of POST. Another usage (even less common) of this type of POST is to send binary data (for example, from a custom browser plugin, or from a nonbrowser HTTP client).

To set the maximum number of kilobytes of the POST data to scan for parameters for the purpose of logging transaction parameters in the statistics log, use the post-content-buffer-limit command in parameter map optimization configuration mode.

The syntax for this command is as follows:

post-content-buffer-limit value

The value argument specifies the buffer size for the POST data. Valid values are from 0 to 1000 KB. The default is 40 KB. Parameters beyond this limit will not be logged by the ACE.

For example, to specify a buffer size of 1000 KB, enter:

host1/Admin(config-parammap-optmz)# post-content-buffer-limit 1000
 
   

To revert to the default buffer size of 40K, enter:

host1/Admin(config-parammap-optmz)# no post-content-buffer-limit 
 
   

Specifying a Server Header String

To define a user-specified string to be sent in the server header for an HTTP response, use the server-header command in parameter map optimization configuration mode. This command provide you with a method to uniquely tag the context or URL match statement by setting server header value to a particular string. The server header string can be used in cases where a particular URL is not being transmitted to the correct target context or the match statement.

The syntax for the command is as follows:

server-header string

The string argument defines a particular string in the server header. Enter a quoted text strin. A maximum of 64 alphanumeric characters are allowed.

For example, to specify a string to be sent in the server header, enter:

host1/Admin(config-parammap-optmz)# server-header "Header from Admin 
Context"
 
   

To delete the server header string, enter:

host1/Admin(config-parammap-optmz)# no server-header

Controlling the Display of UTF-8 Characters

UTF-8 (8-bit Unicode Transformation Format) is a variable-length character encoding for Unicode. The UTF-8 character set is an international standard that allows web pages to display non-ASCII or non-English multibyte characters. It is able to represent any universal character in the Unicode standard and is backward compatible with ASCII.

To determine how many UTF-8 characters on a page constitute a UTF-8 character set page for purposes of UTF-8 detection, use the utf8 threshold command in parameter map optimization configuration mode. This threshold adjusts the detection of multibyte UTF-8 character set pages.

The syntax for the command is as follows:

utf8 threshold value

The value argument specifies the number of UTF-8 characters on a page that constitute a UTF-8 character set page. Valid values are from 1 to 1,000,000 characters. The default is 5 characters.

For example, to specify a value of 1000 UTF-8 characters on a page, enter:

host1/Admin(config-parammap-optmz)# utf8 threshold 1000
 
   

To disable the UTF-8 threshold, enter:

host1/Admin(config-parammap-optmz)# no utf8 threshold

Where to Go Next

Proceed to Chapter 4, Configuring a Traffic Policy for HTTP Optimization, to configure a traffic policy for server load-balancing and application acceleration.