Applies To:

Show Versions Show Versions

Manual Chapter: Policy Management Guide for the BIG-IP WebAccelerator Module: B - Processing HTTP Response Headers
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


B

Processing HTTP Response Headers


Understanding HTTP response headers

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.

Classifying responses

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:

  • The file extension from the file name field in the Content-Disposition header in the response.
  • The file extension from the extension field in the Content-Disposition header in the response.
  • The Content-Type header in the response, unless it is an ambiguous MIME type.
  • The extension of the path in the request.

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.

Rewriting and assembling responses

After clarifying the response, the WebAccelerator system uses the Rewrite Engine to run any associated rewrite scripts, defined by one of the following:

  • The response's object type.
  • The assembly rules for the node to which the response matched.

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:

  • The assembly rules specified for the node that matches the response.
  • The compression setting in the globalfragment.xml file for the object type under which the response was classified. The compression setting can be either:
    • none
      The WebAccelerator system never compresses the response. This setting overrides the compression setting in the 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 assembly rules.
    • policyControlled
      The WebAccelerator system defaults to the setting in the 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 parameter substitution and lifetime rules in effect for the node, and then sends the response to the client.

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® WebAcceleratorTM Module.

Using rules to affect response header processing

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:

  • Responses cached
  • Assembly
    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
    Only in terms of how proxying rules affects the cache-ability of the response, because the WebAccelerator system has already sent the request to the origin servers at the time it reviews the response headers.
  • Lifetime

Response headers have no effect on application matching, variation, or invalidations rules.

Using ESI Surrogate-Control 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 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:

Surrogate-Capabilities: wa="ESI/1.0"

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 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 .

Supported Surrogate-Control directives

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:

  • Content
  • No-store
  • Max-age

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.

Content directive

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:

Surrogate-Control: content="ESI/1.0"

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.

No-store directive

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.

Max-age directive

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.

Note

For more information, see Specifying the stand-in period , located in Chapter 10.

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.

Overriding HTTP Cache-Control headers

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.

Using surrogate targeting

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:

Surrogate-Control: max-age=3600+600;wa,max-age=3600

This example is parsed as follows:

  • 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 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) .

Viewing X-PvInfo response headers

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.

  • If the WebAccelerator system served the response from cache.
  • To what application the WebAccelerator system matched the response.
  • To what node in the Request Type Hierarchy tree the WebAccelerator system matched the response.
  • How the WebAccelerator system classified the response in the globalfragment.xml file.

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.

Defining the Snnnnn code

The Snnnnn codes included in an X-PvInfo response header specify from where the response was served, and are defined as follows:

  • S10101
    The response was served from the WebAccelerator system's memory cache.
  • S10102
    The response was served from the WebAccelerator system's disk cache.
  • S10201
    The response is the first fetch from the origin server for the specified content. The content is now in the WebAccelerator system's disk cache.
  • S10203
    The response is sent from an origin server based on an acceleration policy.

Defining the Annn code

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:

OT/msword,OG/documents

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 .

To view a node's ID in an acceleration policy

  1. On the Main tab of the navigation pane, click Policies.
    The Policies screen opens, displaying a list of acceleration policies.
  2. Click View next to the acceleration policy for which you want to view the node's ID.
    The Policy Editor screen opens.
  3. From the Request Type Hierarchy tree, place your cursor above a node.
    The ID appears in a pop-up screen, in parentheses.



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)