Applies To:

Show Versions Show Versions

Manual Chapter: Using HTTP Headers to Configure
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Using HTTP Headers to Configure Acceleration Policy Rules
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.
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.
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.
When a WebAccelerator system receives an HTTP request that meets the conditions described in Requirements for servicing requests, the WebAccelerator system processes the request as follows:
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.
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 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.
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 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
WebAccelerator system action
Where you specify the following criteria:
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.
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.
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.
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.
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:
Table 4.2 Path example
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.
For example, in the following URLs, gif, jpg, and jsp are all extensions:
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.
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:
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:
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.
In the following URL, ordinal 3 is absent (dog is in ordinal 1 and src is in ordinal 2).
A rule that uses the path segment parameter identifies one of the following values:
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.
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:
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.
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.
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.
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:
In the following string, the USER cookie is present and the REPEAT cookie is absent:
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:
You do not typically base rules on the USER_AGENT request header, unless your site behaves differently depending on the browser in use.
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:
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.
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:
A rule that uses the method parameter is based on whether the request used the GET or POST method.
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.
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.
Accept: text/html, image/*
Accept-Encoding: gzip
Accept-Language: en-us
CSP-Gadget-Realm-User-Pref: NM=5,PD=true,R=3326
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
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:
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:
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
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.
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.
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.
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.
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 responses Content-Type header, unless it is an ambiguous MIME type
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.
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.
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.
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 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.
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.
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 .,).
The WebAccelerator system matches the following HTTP Host request header:
http://www.siterequest.com/apps/search.jsp?value=computer
The WebAccelerator system matches the following value set for the action query parameter:
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:
If you specify parameter ordinal 1, the WebAccelerator system matches to:
The value set for the HTTP USER_AGENT request header
The value set for the HTTP REFERER request header
REFERER: http://www.siterequest.com?action=display
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
Note that the WebAccelerator system assumes that the beginning and end of line meta characters exist for every regular expression it sees.
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:
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.
For example, the expression G.+P.* matches the following:
Do not begin a pattern with the + character. For example, do not use +Plan
For example, the expression G.?P.* matches the following:
Do not begin a pattern with the ? character. For example, do not use ?Plan
Matches a set of characters. You can list the characters in the set using a string made of the characters to match.
For example, the expression C[AHR] matches the following:
You can also provide a range of characters using a dash. For example, the expression AA[0-9]+ matches the following:
To match any alphanumeric character, both upper- and lower-case, use the following expression:
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:
For example, the expression AA(12)+CV matches the following:
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:
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.
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.
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.
1.
In the navigation pane, expand WebAccelerator and click Policies.
The Policies screen displays a list of existing acceleration policies.
4.
From the Matching Rules list, choose Acceleration Rules.
5.
Click Lifetime.
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.
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.
Table 4.7 HTTP Cache-Control headers max age directives
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
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
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.
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:
Note: See Using surrogate targeting, 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.
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:
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.
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:
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.
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.
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.
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.
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.
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.
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:
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.
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.
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:
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.)
Note: For more information about how the WebAccelerator system classifies objects, see Classifying responses. 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:
Using the WebAccelerator systems hit log
For more information about the hit logs, see Chapter 12, Specifying Log Formats for Hit Logs.
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.
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.
Indicates that the response was served from disk because it required specific assembly processing by the WebAccelerator system, in accordance to an acceleration policy.
Response was served from the origin web server, because the request was for new content.
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.
Response was served from the origin web server, because the cached content had expired.
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.
Response was served from the origin web server, as dictated by an acceleration policy rule.
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.
Response was served from the origin web server, because of specific HTTP or web service methods.
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.
Response was served from the origin web server because the cached content was invalidated.
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.
Response was served from the WebAccelerator system's Smart Cache, because the expired content is still valid.
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.
Response was served from the origin web server, because the response contained large multimedia objects.
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.
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.
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.
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.
1.
In the navigation pane, expand WebAccelerator and click Policies.
The Policies screen displays a list of existing acceleration policies.
3.
Place your cursor on a node.
The ID appears in parentheses below the cursor and above the Policy Tree function toolbar.
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.
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.
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.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)