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
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.
| |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.
| |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.
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.
| || |If the Transfer-Encoding
response header is used on the response, the value is chunked.
| || |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
| || |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.
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.
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:
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
, 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
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
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).
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
, 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
, 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
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
, and FROM
. They can also be user or acceleration defined headers in the form of a structured parameter.
Accept: text/html, image/*
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:
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:
| || |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:
In the following example, the WebAccelerator system considers Standards:release
, empty and
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.
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
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
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.
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 (/
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
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
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
Important: The HTTP Cache-Control
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
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:
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.
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.
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.
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
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).
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.