Applies To:

Show Versions Show Versions

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

Much of the WebAccelerator systems behavior is dependent on the information that it finds in the HTTP request headers. The WebAccelerator system uses the HTTP request header information to perform application matching, and to apply specific acceleration polices.
In addition to HTTP headers, the WebAccelerator system also uses HTTP response headers to perform specific caching and assembly processes. Although important, the presence or value of a HTTP response headers does 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 headers always affects assembly. For more information, see Using ESI Surrogate-Control headers.
Before sending a response to a client, the WebAccelerator system also enters an informational XPvInfo response header to the response to describe how it handled the response. 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.
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 defined in the globalfragment.xml file. 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 an object type in the globalfragment.xml file. 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 in the globalfragment.xml file, it classifies the response with that object type, group, and category, and uses the associated settings for compression. The compression settings in the globalfragment.xml file override the assembly rules compression settings for the responses matched node.
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.
Note: 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.
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. See Classifying HTTP response data types, for more information.
After the WebAccelerator system matches the response to a node, it applies the associated acceleration policy rules to the response.
Note: For more information about classifying responses under object types and modifying the globalfragment.xml file to add or change types or settings, see the Administrator Guide for the BIG-IP® WebAccelerator System.
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 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 has applied associated response rewrite scripts, compiled, and cached the response, it assembles the response using the following information:
The compression setting in the globalfragment.xml file for the object type under which the response was classified. The compression setting can be set as:
none
The WebAccelerator system never compresses the response. This setting overrides the compression setting in the acceleration policys assembly rules.
wa
The WebAccelerator system compresses the response if it ever sends it to another WebAccelerator system, but never compresses the response when sent to a browser client. This setting overrides the compression setting in the acceleration policys assembly rules.
policyControlled
The WebAccelerator system defaults to the setting in the acceleration policys assembly rules.
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.
The WebAccelerator system evaluates any response headers that affect caching after it compiles, but before it caches, content. Once the WebAccelerator system begins the compilation and assembly process, it examines response headers that affect assembly, such as the ESI Surrogate-Control header. 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.
If you want a response header to affect the WebAccelerator systems behavior, you can use the following rules with the noted exceptions:
Assembly
Noted exception: Use assembly rules, unless you have enabled the Do Not Rewrite setting, because the response has already exited the Rewrite Engine when the WebAccelerator system reviews the response headers.
Proxying
Noted exception: Use proxying rules, only in terms of how proxying rules affects 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.
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 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.
For more information about using ESI to define page assembly, see Appendix C, Assembling Content with Edge Side Includes.
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.
See Appendix C, Assembling Content with Edge Side Includes, for more information.
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.
You can also specify max-age for HTML fragments using the max-age argument in an esi:inline tag. See esi:inline tags, for more information.
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 Using HTTP/1.1 Cache-Control Headers.
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. For more information, see Using Edge Side Include (ESI).
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:
The object types and groups defined for the WebAccelerator system are located in the config/wa/globalfragment.xml global configuration fragment file. 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.)
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 B.1.
Response was served from an unknown source.
The WebAccelerator system was unable to determine if a response was cached or sent to the origin web server for content.
Response was served from Smart Cache (memory).
Response was served from Smart Cache (disk).
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 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 will send that request to the origin server for content and it will not cache the response.
The A code is the fourth field of the X-PvInfo response header, and identifies to which node in 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 a table of user-defined and pre-defined 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 will appear 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.

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)