Applies To:

Show Versions Show Versions

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

Using HTTP Headers to Configure Acceleration Policy Rules
Much of the WebAccelerator systems behavior is dependent on the configured rules associated with parameters in the HTTP request headers. Although important, the presence or value of HTTP response headers does not influence as many aspects of the WebAccelerator systems behavior, because the WebAccelerator system receives HTTP response headers after performing certain types of processing.
When the WebAccelerator system receives a new request from a client, it first reviews the HTTP request parameters to match it to the relevant acceleration policy. After applying the associated matching rules, it sends the request to the origin web server for content.
Before sending a response to a client, the WebAccelerator system can optionally insert an X-WA-Info response header to track how it handled the request. You cannot change these informational headers, and they do not affect processing, however, they can provide useful information for evaluating your acceleration policies. For more information, see Viewing X-WA-Info response headers.
To maintain high performance, the WebAccelerator system does not service an HTTP request unless the request meets the following conditions.
The request includes an HTTP request header that is no larger than 8192 bytes, and in the first line, identifies its method, URI, and protocol.
If the request provides the Expect request header, the value is 100-continue.
If the request provides the Content-Type request header, the value is application/x-www-form-urlencoded.
The request includes a Host request header identifying a targeted host that is mapped to an origin server at your site.
If the HTTP Host request header is missing or does not have a value, the WebAccelerator system responds to the requesting client with a 400-series error message. If the request violates any of the other conditions, the WebAccelerator system redirects the request to the origin web servers for content.
When a WebAccelerator system receives an HTTP request that meets the conditions described in Requirements for servicing requests, the WebAccelerator system processes the request as follows:
2.
If matched to a proxying rule, the WebAccelerator system sends the request to the origin web servers as required by the rule.
Proxying rules are described in Chapter 12, 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 cache.
4.
If there is no compiled response in the systems cache, the WebAccelerator system sends the request to the origin web servers for content.
5.
If it finds a compiled response in the systems cache, the WebAccelerator system looks for an associated content invalidations rule for the compiled response.
For the conditions and mechanisms that trigger a content invalidations rule, see Chapter 13, Configuring Invalidations Rules.
6.
If a content invalidations rule is triggered for the compiled response, the WebAccelerator system compares the rules effective time against the compiled responses last refreshed time. If the compiled responses last refreshed time is before the content invalidations rules triggered time, the WebAccelerator system sends the request to the origin web servers for content.
7.
If a content invalidations rule is not triggered, or if the compiled responses last refreshed time is after the invalidations rules effective time, the WebAccelerator system examines the compiled responses TTL value to see if the compiled response has expired. If it has expired, the WebAccelerator system sends the request to the origin web servers.
8.
If the compiled response has not expired, the WebAccelerator system services the request using the cached compiled response.
When the WebAccelerator system receives a response from the origin web server, it inspects the HTTP response headers, applies the acceleration rules to the response, and sends the content to the client. To ensure the most effective performance, the WebAccelerator system does not cache a response from the origin server, or forward it to the originating requestor, unless it meets the following conditions.
The first line of the response identifies the protocol, a response code that is an integer value, and a response text.
For example: HTTP/1.1 200 (OK)
If the Transfer-Encoding response header is used on the response, the value is chunked.
The response is complete, based on the method and type of data contained within the response, as follows:
HTML tags
By default, the WebAccelerator system considers a response in the form of an HTML page complete only if it contains both beginning and ending HTML tags.
Content-Length response header
If a response is anything other than an HTML page, or if you have overridden the default behavior described in the previous bullet point, the WebAccelerator system considers content complete only if the response body size matches the value specified on the Content-Length response header.
Chunked transfer coding
The WebAccelerator system accepts chunked responses that omit the final zero-length 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
If the WebAccelerator system receives a response from the origin server that does not conform to these conditions, it does not cache the response before sending it to the client.
In most cases, the default values for the predefined acceleration policies are sufficient, but you can fine-tune the WebAccelerator systems behavior by creating a user-defined acceleration policy and modifying the HTTP request data type parameters. When you specify or modify an HTTP data type parameter for an acceleration policy rule, you define specific HTTP data type parameter criteria that the WebAccelerator system uses to manage HTTP requests. When specifying parameter criteria, you designate the following information within a rule.
Parameter identity
This can include one or more of the following criteria:
Parameter value or state
This can include one or more of the following parameter state and value:
Parameter is present in the HTTP request and matches the defined value provided in the form of a regular expression
Parameter is present in the HTTP request and does not match the specified value provided in the form of a regular expression
WebAccelerator system action
Where you specify the following criteria:
The action that the WebAccelerator system performs, which is dictated by the rules in the associated acceleration policy
For example, if you specify a rule that the WebAccelerator system performs an action when a request does not match a configured parameter, the rule triggers if the parameter in the request is a different value than you specified, or if the value is empty (null). The WebAccelerator system does not perform the specified action if the parameter does not appear in the request.
You cannot configure rules based on all HTTP data types parameters; you can only specify the parameters that the WebAccelerator system uses when processing HTTP requests.
The HTTP data type parameters that the WebAccelerator system uses when processing HTTP requests, are defined as follows.
Note: To specify that the parameter name is case-sensitive, enable the Values are case sensitive setting when configuring the parameter options.
A rule that uses the host parameter is based on the value provided for the HTTP Host request header field. This header field describes the DNS name that the HTTP request is using. For example, for the following URL the host equates to HOST: www.siterequest.com.
A rule that uses the path parameter is based on the path portion of the URI. The path is defined as everything in the URL after the host and up to the end of the URL, or up to the question mark, (whichever comes first). For example:
Table 8.1 Path example
A rule that uses the extension parameter is based on the value that follows the far-right period, in the far-right segment key of the URL path.
Note: Segment keys, the text preceding the semicolon and preceding the question mark in the third URL, are described in Path segment.
For example, in the following URLs, gif, jpg, and jsp are all extensions:
A rule that uses the query parameter is based on a particular query parameter that you identify by name, and for which you provide a value to match against. The value is usually literal and must appear on the query parameter in the request, or a regular expression that matches the requests query parameter value. The query parameter can be in a request that uses GET, HEAD, or POST methods.
You can also create a rule that matches the identified query parameter when it is provided with an empty value, or when it is absent from the request. For example, in the following URL the action query parameter provides an empty value:
An unnamed query parameter is a query parameter that has no equal sign. That is, only the query parameter value is provided in the URL of the request. For example, the following URL includes two unnamed query parameters that have the value of dog and cat:
A rule that uses the unnamed query parameter specifies the ordinal of the parameter, instead of a parameter name. The ordinal is the position of the unnamed query parameter in the query parameter portion of the URL. You count ordinals from left to right, starting with 1. In the previous URL, dog is in ordinal 1 and unnamed, cat is in ordinal 2 and unnamed, and src is in ordinal 3 and named magic.
Figure 8.1 Query parameter: ordinal 1=dog (unnamed); ordinal 2=cat (unnamed); ordinal 3=src (named magic)
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).
Figure 8.3 Query parameter: ordinal 1=dog (empty); ordinal 2=src (named magic); ordinal 3 (absent)
A rule that uses the path segment parameter identifies one of the following values:
A segment is the portion of a URI path that is delimited by a forward slash (/). For example, in the path: /apps/search/full/complex.jsp, apps, search, full, and complex.jsp all represent path segments. Further, each of these values are also the segment key, or the name of the segment.
A segment parameter is the value in a URL path that appears after the segment key. Segment parameters are delimited by semicolons. For example, magic, shop, and act are all segment parameters for their respective path segments in the following path:
You must also indicate in the rule, which way you are counting ordinals in the path: from the left or the right (you always count starting at 1). For the example shown, /full;magic, the ordinals for this path are as show in Table 8.2.
A rule that uses the cookie parameter is based on a particular cookie that you identify by name, and for which you provide a value to match against. Usually the value is literal and must appear on the cookie in the request, or a regular expression that must match the requests cookie that appears on the cookie HTTP request headers. These are the same names you use to set the cookies, using the HTTP SET-COOKIE response headers.
You can also create a rule that matches when the identified cookie is provided with an empty string or when it is absent from the request. For example, in the following string, the following REPEAT cookie is empty:
In the following string, the USER cookie is present and the REPEAT cookie is absent:
A rule that uses the user agent parameter is based on the value provided for the HTTP USER_AGENT in the request header, which identifies the browser that sent the request. For example, the following USER_AGENT request header indicates that the requesting browser is IE 5.01 running on Windows NT 5.0:
You do not typically base rules on the USER_AGENT request header, unless your site behaves differently depending on the browser in use.
A rule that uses the referrer parameter is based on the value provided for the HTTP REFERER in the request header. (Note the misspelling of REFERER. This spelling is defined for this request header in all versions of the HTTP specification.)
This header provides the URL location that referred the client to the page that the client is requesting. That is, REFERER provides the URL that contains the hyperlink that the user clicked to request the page. For example:
You do not typically base rules on the REFERER request header, unless you want your sites behavior to be dependent on the specific referrer. For example, one implementation would be for sites that provide different branding for their pages based on the users web portal or search engine.
A rule that uses the protocol parameter is based on whether the request uses the HTTP or HTTPS protocol. For example, the following URL uses the HTTP protocol:
A rule that uses the method parameter is based on whether the request used the GET, HEAD, or POST method.
A rule that uses the header parameter is based on a particular header that you identify by name, and for which you provide a value to match against. You can use an HTTP request data type header parameter to create rules based on any request header, other than one of the recognized HTTP request data types.
The HTTP request data type header parameter you use can be standard HTTP request header fields such as AUTHORIZATION, CACHE-CONTROL, and FROM. They can also be user or acceleration defined headers in the form of a structured parameter.
Accept: text/html, image/*
Accept-Encoding: gzip
Accept-Language: en-us
CSP-Gadget-Realm-User-Pref: NM=5,PD=true,R=3326
The format of a structured parameter in a request is similar to that used for a cookie, with a header name that you choose, followed by a series of name=value pairs separated by commas. The header name is not case-sensitive and in this structure, the semicolons (;) are special characters. The parser ignores anything after a semicolon until it reaches the subsequent comma. For example, following are valid header structured parameters:
CSP-Global-Gadget-Pref: AT=0
CSP-Gadget-Realm-User-Pref: NM=5,PD=true,R=3326
CSP-User-Pref: E2KU=chi,E2KD=ops%u002esiterequest%u002enet,E2KM=chi
CSP-Gateway-Specific-Config: PT-User-Name=chi,PT-User-ID=212,PT-Class-ID=43
Standards: type=SOAP;SOAP-ENV:mustUnderstand="1",version=1.2
In the last line, the parser ignores SOAP-ENV:mustUnderstand="1", because it follows a semicolon. Since version=1.2 follows the command, the parser reads it as a name=value pair. If you have metadata that you want to include in the header, but want the WebAccelerator system to ignore, put it after a semicolon.
If you specify a header as a structured parameter when creating a rule, the WebAccelerator system parses it into name=value pairs when it examines the request. If you do not specify it as a structured parameter, the WebAccelerator system processes it like a normal header, and treats everything after the colon (:) as the value. To define a header as a structured parameter when you are creating or editing a rule, you specify the name using the following syntax:
headername
Is the name of the header.
parmname
Is the name of the parameter with the value that you want to affect the rule.
Using the CSP-Global-Gadget-Pref header as an example, if you want the WebAccelerator system to evaluate the value for AT to determine if a configured rule should apply, specify the name of the header parameter as follows:
If you want the WebAccelerator system to evaluate the entire string without assigning meaning to name=value pairs, specify the name of the header parameter as follows:
You can create a rule that matches when the identified header is provided with an empty value, or when it is absent from the request.
In the following example, the WebAccelerator system considers Standards:release, empty and considers Standards:SOAP-ENV absent, because it is ignored:
Standards: type=SOAP;SOAP-ENV:mustUnderstand="1",release=,version=1.2
A rule that uses the client IP parameter is based on the IP address of the client making the request. The IP address, however, may not always be the address of the client that originated the request.
For example, if the client goes through a proxy server, the IP address is the IP address of the proxy server, rather than the client IP address that originated the request. If several clients use a specific proxy server, they all appear to come from the same IP address.
Unlike the HTTP request data types, a matching rule based on content type is specific to the content type parameter that the WebAccelerator system generates for a response. You specify the regular expression that you want a response's content type to match.
Response headers have no effect on application matching, variation, or invalidations rules. The WebAccelerator system evaluates response headers associated with caching after it compiles, but before it caches, the response. Once the WebAccelerator system begins the compilation and assembly process, it then examines existing response headers that influence assembly.
Note: If you configure proxying rules based on HTTP response header parameters, you can use them only in terms of how the WebAccelerator system caches the responses, because the WebAccelerator system has already sent the request to the origin web servers when it reviews the response headers.
After the WebAccelerator system receives a response from the origin server, and before it performs application matching, it classifies the response based on the object types that are defined on the Object Types screen. The WebAccelerator system bases this classification on the first item it finds, in the following order:
The responses Content-Type header, unless it is an ambiguous MIME type
For example, if the extension in the file name field of the responses Content-Disposition header is empty, the WebAccelerator system looks at the responses Content-Disposition headers file extension in the extension field. If that has an extension, the WebAccelerator system attempts to match it to a defined object type. If there is no match, the WebAccelerator system assigns an object type of other and uses the settings for other. The WebAccelerator system examines the information in the Content-Type header only if there is no extension in the file name or extension fields of the Content-Disposition header.
If the WebAccelerator system finds a match to an object type, it classifies the response with that object type, group, and category, and uses the associated settings for compression. The object type and group under which the response is classified is also included in the X-WA-Info response header. For more information, see Viewing X-WA-Info response headers.
Important: If you have defined a compression setting for an object from the Object Types screen, it overrides any compression setting configured for an assembly rule for the responses matched node.
Once it classifies the response by object type, the WebAccelerator system appends it as follows: group.objectType. The WebAccelerator system then matches the response to a node of a Policy Tree in an acceleration policy (the first matching process was for the request), using the new content type. In many cases, this content type is the same as the content type for the request, and the WebAccelerator system matches the response to the same node as the request.
Note: The WebAccelerator system also matches the response to the same node as the request if there is no Content Type parameter specified in a matching rule.
Unlike the HTTP request data types, you do not base a matching rule directly on the value of an HTTP response data type. Instead, you base the rule on the content type parameter that the WebAccelerator system generates, by specifying the regular expression that you want a request or responses content type to match, or not to match.
The WebAccelerator system compiles the response, and determines if it can cache it by looking for a responses cached rule for the node that matches the response. If the response is cacheable, the WebAccelerator system caches a copy of the response.
The Enable Compression setting (configured from the Object Types screen) for the object type under which the response was classified. The options for this setting are:
Policy Controlled
The WebAccelerator system uses the compression settings configured in the acceleration policys assembly rules.
None
The WebAccelerator system never compresses the response. This option overrides the compression setting in the acceleration policys assembly rules. Select this option only if you want the WebAccelerator system to ignore assembly rules for the specified object type.
When the WebAccelerator system performs pattern matching based on regular expressions, it assumes all regular expressions are in the form of ^expression$, even if you do not explicitly set the beginning of line (^) and end of line ($) indicators. For substring searches, you enter *expression.* as a regular expression.
The string that the WebAccelerator system matches is dependent on the HTTP data type for which you are providing the regular expression. Before the WebAccelerator system attempts to match information in an HTTP request to the HTTP request data type parameters, it translates any escaped characters (such as %2F or %2E) back to their regular form, such as (/ or .,).
The HTTP Cache-Control version 1.1 header specification identifies general-header field directives for all caching mechanisms along the request/response chain, and is used to prevent caching behavior from adversely interfering with the request or the response. (For additional information, see sections 13 and 14 of the HTTP/1.1 specification at http://www.w3.org/Protocols/rfc2616/rfc2616.html.)
Directives can appear in response or request headers, and certain directives can appear in either type of header. The HTTP Cache-Control general-header field directives typically override any default caching algorithms.
By default, the majority of the WebAccelerator systems acceleration policies are configured to cache responses and ignore the following HTTP Cache-Control headers no-cache directives.
You can configure the WebAccelerator system to honor no-cache directives. However, doing so may result in a noticeable increase in the traffic sent to the origin web server, depending on how many users send no-cache directives in requests.
Important: For images and documents that use the origin web servers Cache-Control: Private directive (such as Microsoft® SharePoint and Microsoft® Outlook Web Access), the Ignore no-cache HTTP headers in response check box is clear by default to ensure privacy. If you select the Ignore no-cache HTTP headers in response check box for items that use the origin web server Cache-Control: Private directive, privacy could be compromised.
The WebAccelerator system uses the HTTP Cache-Control headers max-age directives 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.
Important: The HTTP Cache-Control headers max-age directive is not the same as a lifetime rules Maximum Age for WebAccelerator system Cache Settings. The max-age directive defines a TTL for content. The lifetime rules Maximum Age setting is a boundary beyond which, for example, the max-age directive cannot surpass.
Before sending a response to a client, the WebAccelerator system can optionally insert an X-WA-Info response header that includes specific codes, which describe the properties and history of the object. The X-WA-Info response header is for informational purposes only and provides a way for you to assess the effectiveness of your acceleration policy rules.
The code is divided into fields by the period ( . ) delimiter. Each field begins with a letter code, followed by one or more letters or numbers. The object type and group under which the response is classified are also included in the X-WA-Info response header.
The object type is preceded by OT and the group is preceded by OG, as in the following example:
You can view X-WA-Info response headers by:
The S code is the first field of the X-WA-Info response header. This field code indicates whether the object in the HTTP response was served from the systems cache, or was sent to the original web server for content.
The C code is the second field of the X-WA-Info response header, and it indicates the acceleration policy that the WebAccelerator system applied to the request.
The A code is the third field of the X-WA-Info 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.
The R code is the fourth field of the X-WA-Info 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 in the URL path is not considered a response application match; however, a request application match appears in the A field.
A 0 (zero) R code in the X-WA-Info response header indicates that the WebAccelerator response matching did not override the decision made in the initial request match (A-code).
The U code is the fifth field of the X-WA-Info response header and is a hexadecimal cache ID number. The U code identifies where cached objects are stored in the cache.
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)