Much of the WebAccelerator system's behavior is dependent on the information that it finds in the HTTP requests and HTTP request headers. The WebAccelerator system uses the information it finds in the HTTP requests for application matching, and most acceleration polices are based on the HTTP request data values.
Although important, HTTP response headers do not influence as many aspects of the WebAccelerator system's behavior because the WebAccelerator system receives HTTP response headers after performing certain types of processing. For example, the presence or value of a response header cannot affect the UCI that the WebAccelerator system generates for the request and assigns to the response. The WebAccelerator system also inserts several information headers into the response headers to describe how it handled a response. You cannot change these informational headers, and they do not affect processing, however, they can provide useful information if you must evaluate your acceleration policies.
When 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 global configuration fragment file.
To classify the response, the WebAccelerator system views the response header and bases the object-type classification on the first information it finds, in the following order:
For example, if the extension in the file name field of the Content-Disposition header is empty, the WebAccelerator system looks at the Content-Disposition header's 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 looks 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 setting in the globalfragment.xml file override the compression settings specified in the assembly rules for the node of the response.
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 for the second time (the first was matching the request to a node), using the new content type. In many cases, this content type is the same as the content type for the request, in which case 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 any matching rules. See Classifying HTTP response data types , located in Chapter 5, for more information.
After the WebAccelerator system matches the response to a node, it applies the associated acceleration policy to handle the response.
After clarifying the response, the WebAccelerator system uses the Rewrite Engine to run any associated 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 type's rewrite script and ignores the rewrite script defined for the assembly policy.
After the Rewrite Engine processes the response, the WebAccelerator system compiles the response, and determines if it is cache-able by looking for a responses cached rule for the node that matches the response. If it is cache-able, the WebAccelerator system caches a copy of the response.
The WebAccelerator system then assembles the response using the following information:
If the response includes an ESI Surrogate-Control header, the WebAccelerator system performs ESI processing as part of the assembly and applies any associated parameter substitution and lifetime rules in effect for the node, and then sends the response to the client.
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 any 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. See Using ESI Surrogate-Control headers .
If you want a response header to affect the WebAccelerator system's behavior, you can use the following rules:
Response headers have no effect on application matching, variation, or invalidations rules.
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 system's 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, and identifies the WebAccelerator system as an ESI 1.0 compliant device, as follows:
The response that the origin server returns must contain an ESI Surrogate-Control response header if there is any ESI markup used in the response. The ESI specification that defines the Surrogate-Control response header is available on the web at the http://www.esi.org/architecture_spec_1-0.html site.
For more information about using ESI to define page assembly, see Appendix D, Assembling Content with Edge Side Includes .
The 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:
The Surrogate-Control header can contain one of these directives, or more separated by a comma (,).
The WebAccelerator system ignores any unsupported directives defined in the Surrogate-Control response header.
The content directive (always specified as a name=value pair) is required if an HTTP response contains ESI markup. The origin server must include, at a minimum, a content directive header with 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 D, Assembling Content with Edge Side Includes for more information.
The no-store directive is always specified as the string no-store. For example: Surrogate-Control: content="ESI/1.0",no-store
If the Surrogate-Control header contains the no-store directive, the WebAccelerator system does not cache the response.
Expressed in seconds, the max-age directive specifies how long to cache content. For example, the value max-age=3600 indicates that the content should be cached for 1 hour. The WebAccelerator system uses this value as the compiled response's 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.
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 an ESI 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 , located in Chapter 10.
The exception to this rule is that you can use a lifetime rule to direct the WebAccelerator system to ignore the ESI max-age directive. For information about configuring lifetime rules, see Using lifetime rules , located in Chapter 10.
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:
This example is parsed as follows:
The device token in this example is wa. The wa device token was defined to the origin servers in the ESI Surrogate-Capability request header that the WebAccelerator system added to the request before it sent the request to the origin servers.
The WebAccelerator system always uses a device token of wa in the ESI 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 Snnnnn and Annn codes. You can review these headers to find out how the WebAccelerator system processed the response.
The X-PvInfo response header is for informational purposes only and provides a way for you to assess how your acceleration policy rules are working. To view headers, perform a packet capture of the page or use an HTTP viewer utility like HttpWatch, HTTP Analyzer, or Live Headers.
The Snnnnn codes included in an X-PvInfo response header specify from where the response was served, and are defined as follows:
The Annn codes included in an X-PvInfo response header specify to which node in the Request Type Hierarchy tree the request was matched and what rules the WebAccelerator system applied to the request. The nnn portion of the code refers to the ID of the node defined in the acceleration policy.
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 specified Annn node.
For more information about how the WebAccelerator system classifies objects, see Classifying responses .