Applies To:

Show Versions Show Versions

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

Much of the WebAccelerator systems behavior is dependent on the parameters that it finds in HTTP request and response headers, based on the configured rules associated with those parameters.
Although important, the presence or value of HTTP response headers do not influence as many aspects of the WebAccelerator systems behavior as the HTTP request headers, because the WebAccelerator system receives HTTP response headers after performing certain types of processing. For example, a response header cannot affect the UCI that the WebAccelerator system generates for the request and assigns to the response, however, an ESI Surrogate-Control response header always affects assembly. For more information, see Using ESI Surrogate-Control headers.
Before sending the response to a client, the WebAccelerator system also enters an informational X-PvInfo response header to the response to describe 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.
The process begins when the WebAccelerator system receives a new request from a client and reviews the HTTP request parameters to find the relevant acceleration policy. Once it finds the relevant policy, the WebAccelerator system applies the associated matching rules, and sends the request to the origin web server for content. To maintain high performance, the WebAccelerator system does not service an HTTP request unless the request meets the following conditions.
The request must include an HTTP request header that is no larger than 8192 bytes and must identify in the first line, its method, URI, and protocol.
If the request provides the Expect request header, the value must be 100-continue.
If the request provides the Content-Type request header, the value must be application/x-www-form-urlencoded.
The request must include a Host request header that identifies a targeted host that is mapped to an origin server at your site.
If the HTTP Host request header is missing, or the WebAccelerator system does not know its 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 processing.
When a WebAccelerator system receives an HTTP request that meets the conditions described in Servicing HTTP client requests, the WebAccelerator system processes the request as follows:
1.
The WebAccelerator system performs application matching against the request and retrieves the associated acceleration rules.
2.
If the WebAccelerator system matches a proxying rule to the request, it sends the request to the origin web servers as required by the rule. Proxying rules are described in Chapter 9, 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 determines whether there is an associated content invalidations rule for the compiled response. For the conditions and mechanisms that trigger a content invalidations rule, see Chapter 11, Configuring Invalidations Rules.
6.
If a content invalidations rule is triggered for the compiled response, the WebAccelerator system examines 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 your 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 must identify 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 must be chunked.
The WebAccelerator system must consider the response content complete. The WebAccelerator system uses different methods to determine if content is complete, based on the 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, theWebAccelerator 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 must not exceed the value of the maxResponseDataSize parameter in the WebAccelerator systems configuration file. By default, this value is 2MB.
If the WebAccelerator system receives a response from the origin server that does not conform to these conditions, the WebAccelerator system will not cache the response and will redirect the response to the original requesting client.
The HTTP request data type parameters, which are specified within the matching rules and acceleration rules of an acceleration policy, dictate how the WebAccelerator system processes an HTTP request. For example, a rule can specify that if an HTTP request matches a certain HTTP request data type parameter, either the WebAccelerator system sends the request to the origin web server, or that the WebAccelerator system substitutes a certain value when providing a response to the client.
In most cases, the default values for the pre-defined 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 request data type parameter, you designate the following information.
The value or required state of the parameter for the WebAccelerator system to find a match. This can include one or more of the following:
Parameter is present in the HTTP request and matches the specified 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.
What action that the WebAccelerator system performs, which is dictated by the rules in the associated acceleration policy
For example, if you specify in a rule that dictates that the WebAccelerator system performs a certain action when a request does not match a configured parameter, then the rule triggers the action 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 request data types parameters; you can only specify the parameters that the WebAccelerator system uses when processing HTTP requests. Table 5.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 HTTP request data type parameter, protocol, 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 HTTP request data type parameter, host, 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, in the following URL:
A rule that uses the HTTP request data type parameter, path, 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, the following URL paths:
A rule that uses the HTTP request data type parameter, extension, 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 HTTP request data type parameter, method, is based on whether the request used the GET or POST method.
A rule that uses the HTTP request data type parameter, 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 parameter, unnamed query, 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).
The HTTP request data type parameter, path segment, is used to identify one of the following values provided:
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 5.2.
When you specify a segments ordinal for a rule, you must also identify the ordinal of the element within the segment on which the rule is based. When you count segment parameter ordinals, you always left-to-right in the path, and the segment key is always ordinal 0. For example, in the following segment:
the segment key is complex.jsp and its ordinal is 0. Segment parameters shop and act have ordinals 1 and 2 respectively.
A rule that uses the HTTP request data type parameter, cookie, 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.
The names of the cookies that you identify must match the names that appear on the cookie HTTP request headers and are the same names you used 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:
A rule that uses the HTTP request data type parameter, user agent, is based on the value provided for the HTTP USER_AGENT in the request header. This header 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 HTTP request data type parameter, referrer, 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 HTTP request data type parameter, header, 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 5.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 meta data 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
When a rule is based on the HTTP request data type parameter, client IP , the WebAccelerator system looks at 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.
Response headers influence processing that occurs only after the response has exited the Rewrite Engine. Response headers have no effect on application matching, variation, or invalidations rules. The WebAccelerator system evaluates response headers that affect caching after it compiles, but before it caches, the content. Once the WebAccelerator system begins the compilation and assembly process, it then examines existing response headers that affect assembly.
You can configure assembly, proxying, lifetime, or responses cached rules to affect the WebAccelerator systems behavior based on response headers. It is, however, important to note that if you configure proxying rules for this purpose, you can use them only in terms of how the proxying rules affect the WebAccelerator systems ability to cache the response, 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 only examines at the information in the Content-Type header 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: The compression settings defined for the object override the assembly rules compression settings for the responses matched node. You define object types and groups from the Object Types screen and the WebAccelerator system stores these settings in its globalfragments.xml file. For specific information about how to configure object types, see the Changing Default Settings chapter in the Configuration Guide for the BIG-IP® WebAcceleratorTM System.
Once the WebAccelerator system classifies the response by object type, it generates a content type, by appending the object type to the group to which the object type belongs as follows: group.objectType. The WebAccelerator system then performs application matching to the response (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. The WebAccelerator system also matches the response to the same node as the request, if the Content Type parameter is not specified in a matching rule. After the WebAccelerator system matches the response to a node, it applies the associated acceleration policy rules to the response.
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 clarifying the response, the WebAccelerator system uses the Rewrite Engine to run any associated response rewrite scripts, defined by one of the following:
In most cases, an associated rewrite script is defined in the assembly rules, not the object type, However, if a rewrite script is defined for the object type, the WebAccelerator system uses the object types rewrite script and ignores the rewrite script defined in the acceleration policys assembly rules.
After the WebAccelerator system runs the rewrite script, it 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 cache-able, the WebAccelerator system caches a copy of the response.
Once the WebAccelerator system has applied associated response rewrite scripts, compiled, and cached the response, it assembles the response using the following information:
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.
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 .,).
http://www.siterequest.com/apps/search.jsp?value=computer
For example, 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:
The value set for the HTTP USER_AGENT request header.
The value set for the HTTP REFERER request header.
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.
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 to the following:
You can begin a pattern with the * character, which is the same as using: .*
For example, the expression G.+P.* matches to the following:
Do not begin a pattern with the + character. For example, do not use +Plan
For example, the expression G.?P.* matches to the following:
Do not begin a pattern with the ? character. For example, do not use ?Plan
For example, the expression C[AHR] matches to the following:
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 headers that you can use to control web entities, such as the WebAccelerator system. (For additional information, see sections 13 and 14 of the HTTP/1.1 specification at http://www.w3.org/Protocols/rfc2616/rfc2616.html.)
HTTP Cache-Control headers can appear on requests sent by clients and on responses sent by the origin web servers. The HTTP Cache-Control general-header field specifies 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. Some directives can appear only in response headers, and some can appear only in 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.
If you disable the Ignore no-cache HTTP headers in the response option in the HTTP Lifetime Header section of the lifetime rule screen, the WebAccelerator system uses the cache response directives that it receives from the origin web server. The origin web servers cache response directives are organized in two groups:
no-cache
These are directives that prompt the WebAccelerator system to not cache a response. You can enable the lifetime rules Ignore no-cache HTTP headers in the request option to prompt the WebAccelerator system to ignore the HTTP Cache-Control headers no-cache directives. Doing so may result in a noticeable drop in the traffic sent to the origin web server, depending on how many users send no-cache directives in their requests.
max-age
These are directives that the WebAccelerator system uses to help determine the TTL value for compiled response.
The HTTP Cache-Control headers no-cache directives prompt the WebAccelerator system to send a request to the origin web servers, and also dictate whether the WebAccelerator system should cache the response. The no-cache directives are described in Table 5.5.
Table 5.5 HTTP Cache-Control headers no-cache directives
If the pragma general-header field specifies no-cache, the WebAccelerator system does not cache the response.
If Cache-Control general-header field specifies no-cache, the WebAccelerator system does not cache the response.
If Cache-Control general-header field specifies no-store, the WebAccelerator system does not cache the response.
If Cache-Control general-header field specifies private, the WebAccelerator system does not cache the response.
For more information about this directive, see Section 14.9.1 of the HTTP 1.1 specification: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1
For HTTP Cache-Control headers, the WebAccelerator system uses the value for the directives defined in Table 5.6, 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.
The max-age directives are described in Table 5.6.
Table 5.6 HTTP Cache-Control headers max age directives
The WebAccelerator system bases the TTL on the current time, plus the value specified for the 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 Cache-Control headers max-age directive. Values for this directive are expressed in seconds.
The WebAccelerator system uses the TTL provided for Cache-Control headers entity-header field. Values for this field are expressed in Coordinated Universal Time (UTC time).
To avoid potential issues, it is important to ensure that that the WebAccelerator system is properly synchronized with the origin web server, therefore, F5 Networks highly recommends that you configure a Network Time Protocol (NTP) server.
For information about configuring NTP on the BIG-IP system, refer to the TMOS Management Guide for BIG-IP Systems, which is available on the Technical Support web site, https://support.f5.com.
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 the the value of the Maximum Age setting for the lifetime rules WebAccelerator system Cache Settings. You use the HTTP Cache-Control headers max-age directive to define a TTL for content. The lifetime rules Maximum Age setting is a boundary condition beyond which, for example, the HTTP Cache-Control headers max-age directive cannot surpass. For more information about lifetime rule parameters, see Configuring a lifetime rule example.
In general, freshness calculations for HTTP headers are based on the date or age value received in the HTTP response, as defined in section 13.2.3 of the HTTP version 1.1 specification: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.3
However, the WebAccelerator system assumes that the values for date and age are 0, so it bases all age calculations on the time that it receives a response from the origin web server.
The time delay between when a response leaves the origin web server and it is received by the WebAccelerator system.
In most cases, these issues are negligible, however, to ensure that the WebAccelerator system maintains proper synchronization with the origin web server, F5 Networks highly recommends that you configure a Network Time Protocol (NTP) server. For information about configuring the NTP server, see the Configuration and Maintenance Tasks chapter in the Configuration Guide for the BIG-IP® WebAcceleratorTM System.
If the client sends an HTTP request header that prevents the WebAccelerator system from serving the content from its cache, the WebAccelerator system sends the request to the origin web server. This event prompts the WebAccelerator system to refresh the corresponding content that it has cached, even if that content has not yet expired.
When using HTTP Cache-Control headers, the WebAccelerator system uses the cache request directives described in Table 5.7.
If the pragma general-header field includes the no-cache directive, the WebAccelerator system sends the request to the origin web servers.
If Cache-Control specifies no-cache, then the WebAccelerator system sends the request to the origin web servers.
If Cache-Control specifies no-store, the WebAccelerator system sends the request to the origin web server.
If the max-age value for the Cache-Control header is less than the current age of the cached content, the WebAccelerator sends the request to the origin web server.
curr_time is the time that the request is received by the WebAccelerator system.
min_fresh_time is the time specified by this directive.
content_TTL is the time to live value set for the compiled response that corresponds to the request.
If you want the WebAccelerator system to ignore HTTP request no-cache headers and to serve responses from cache, in accordance with the configured lifetime rules, you can enable the lifetime rules Ignore no-cache HTTP headers in the request option.
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 erver 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.
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 a lifetime rule example.
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 are 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 a lifetime rule example.
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 systems cache setting options.
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 Using 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. 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 object type and group under which the response is classified is 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® WebAcceleratorTM System.
You can view X-PvInfo response headers by:
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 cache, or was sent to the original web server. The S codes are defined in Table 5.8.
The WebAccelerator system was unable to determine if a response was cached or sent to the origin web server for content.
Request was sent to the origin web server, because it was for new content.
The WebAccelerator system caches the response from the origin web server for future requests, before responding to the request. The WebAccelerator system will respond to future request for this content, from cache.
Response was sent to the origin web server, because the cached content had expired.
When cached content exceeds the maximum age setting, the WebAccelerator system sends the next request to the origin web server for new content. After revalidating the content, the WebAccelerator system serves future requests from cache, until the maximum age is once again exceeded.
Response was sent to the origin web server, in accordance with an acceleration policy.
When the WebAccelerator system matches a request to a node with an acceleration rule set to always proxy, the WebAccelerator system will send that request to the origin web server, rather than serving it from cache.
Response was sent to the origin web server, because of specific HTTP or web service methods.
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. In addition, if the WebAccelerator system matches a request to a node with a no-cache directive, the WebAccelerator system will send the request to the origin server and will not save the response to cache.
Response was sent to the origin web server because the cached content was invalidated.
Cache invalidation can be conducted through manual invalidations, through direct XML messaging over HTTPS on port 8443, or prompted by an acceleration rule parameter. 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 sent to the origin web server because the response required authentication from the origin web server.
If the WebAccelerator system matches a request over an NTLM-authenticated connection to a node with an acceleration rule configured that does not allow cached NTLM-authenticated content, it sends that request to the origin server for content, and it does not cache the response.
Response was sent to the origin web server, because the response contained large multimedia objects.
Large multimedia objects often cannot be optimized. Such content is typically composed of large files that are already compressed and too large to cache. The WebAccelerator system can be configured to recognize these objects and to send them directly to the origin web server for content.
When a response exceeds the value 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.
When the WebAccelerator system's license is expired it does not match and apply acceleration policies to requests or responses.
This indicates that the response was served from memory without requiring specific assembly processing by the WebAccelerator system. This is the most efficient and fastest response method.
The A code is the fourth 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.
On the Main tab of the navigation pane, expand WebAccelerator and click Applications.
The Applications screen opens in a new window.
2.
On the Main tab of the navigation pane in the new window, click Policies.
The Policies screen opens, displaying the existing acceleration policies.
3.
Click the name of the acceleration policy for which you want to view the nodes ID.
The Policy Editor screen opens.
4.
On the Policy Tree, place your cursor on a node.
The ID appears in parentheses below the cursor.
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 P code is the third field of the X-PvInfo response header. This field is always populated with an L for live production acceleration policy.
The R code is the fifth 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 8, 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 sixth 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 seventh 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)