The HTTP request data type parameters, which are specified within the
matching and acceleration rules of an acceleration policy, dictate how the WebAccelerator system processes an HTTP request. For example, a rule can specify that if an HTTP request matches a certain HTTP request data type parameter, either the WebAccelerator system sends the request to the origin server, or that the WebAccelerator system substitutes a certain value when providing a response to the client.
In most cases, the default values for the pre-defined 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. You cannot customize all HTTP request data types parameters; you can only customize the parameters that the WebAccelerator system uses when processing HTTP requests. For an overview of the parameters that you can change, see Table 5.1
For example, if you specify in a rule that dictates that the WebAccelerator
system performs a certain action when a request does not match a configured parameter, then the rule triggers the action 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.
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 (/
outlines the HTTP data type parameters that you can view and configure for various matching and acceleration rules.
A rule that uses the protocol HTTP request data type 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 host HTTP request data type parameter is based on the
value provided for the HTTP HOST
request header. This header describes the DNS name that the HTTP request is using. For example, the following URL:
Results in the following HTTP HOST
A rule that uses the path HTTP request data type 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, the following URL paths:
A rule that uses the extension HTTP request data type parameter is based on
the value that follows the far-right period, in the far-right segment key.
For example, in the following URLs, gif
, and jsp
are all extensions:
A rule that uses the query parameter HTTP request data type 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 must match the requests query parameter value. The query parameter can be in a request that uses GET or POST methods.
You can 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 ordinal 1, and cat
is ordinal 2.
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).
In a path, 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 a value that appears after the segment key in a path
segment. 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 how you are counting within the path: from the left
or the right (always count starting from 1). For the example shown, /full;magic
, the ordinals for this path are as show in Table 5.2
Once you have identified a segments ordinal, you must identify the ordinal
of the element within the segment, on which the rule is based. Counting is always left-to-right, and the segment key is always ordinal 0
. For example, in the following segment:
The segment key is complex.jsp
and its ordinal is 0
. Segment parameters shop
have ordinals 1
A rule that uses the cookie HTTP request data type 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.
The names of the cookies that you identify must match the names that
appear on the cookie HTTP request headers and are the same names you used to set the cookies, using the HTTP SET-COOKIE
You can 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:
A rule that uses the user agent HTTP request data type parameter is based on
the value provided for the HTTP USER_AGENT
in the request header. This header 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 HTTP request data type parameters 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 header HTTP request data type parameters is based on a
particular header that you identify by name, and for which you provide a value to match against. You can use header HTTP request data type parameters to create rules based on any request header, other than one of the recognized HTTP request data types that are listed in Table 5.1
The HTTP request data type parameters 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. For example, following are examples of HTTP request data type parameters:
Accept: text/html, image/*
The last header in the example depicts a structured parameter. If you
specified this header as a structured parameter when creating the rule, the WebAccelerator system parses it into name=value
pairs when it examines the request. If you did 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.
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 meta data that you want to include in the header, but want the WebAccelerator system to ignore, put it after a semicolon.
| || |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 the 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 When a rule uses the client IP HTTP request data type parameters, the
WebAccelerator system looks at 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 would
be 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.
| |From the Add Parameter
list on the Matching Rules screen, select a parameter, and then click the Add
button. The parameter options display.
Before the WebAccelerator system performs application matching, it
classifies the request or response by object type. For requests, the WebAccelerator system bases the classification on the requests file extension. For responses, the WebAccelerator system bases the classification on the first information present, in the following order:
| || |The Content-Type
header in the response, unless it is an ambiguous MIME type.
Once the WebAccelerator system classifies the request or 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
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.
| |From the Add Parameter
list, select Content Type
and click the Add
button. The Content Type parameter options display.
| |In the Value(s)
box, type a regular expression that you want to match or not to match.
| |Check the Match if not yet classified
check box if you want an object to match to the node, even if it is not classified in the /config/wa/globalfragment.xml
file. (For more information about classifying responses, see Classifying responses