Applies To:

Show Versions Show Versions

Manual Chapter: Configuring HTTP Data Types
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

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.
The value or required state of the parameter for the WebAccelerator system to find a match. This can include one or more of the following:
Parameter is present in the HTTP request and matches the specified 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.
What action that the WebAccelerator system performs, which is dictated by the rules in the associated acceleration policy
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 (/ or .,).
Table 5.1 outlines the HTTP data type parameters that you can view and configure for various matching and acceleration rules.
The WebAccelerator system uses these parameters when processing HTTP requests. The HTTP data type parameters are defined as follows.
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 request header:
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, jpg, 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:
Note: To specify that the parameter name is case-sensitive, check the Values are case sensitive check box when configuring the parameter options.
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 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).
Note: To specify that the parameter name is case-sensitive, enable the Values are case sensitive setting when configuring the parameter options.
Note: To specify that the parameter name is case-sensitive, enable the Values are case sensitive setting when configuring the parameter options.
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, 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 a value that appears after the segment key in a path segment. 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 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 and act have ordinals 1 and 2 respectively.
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 response headers.
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:
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 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, CACHE-CONTROL, 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/*
Accept-Encoding: gzip
Accept-Language: en-us
CSP-Gadget-Realm-User-Pref: NM=5,PD=true,R=3326
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:
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 meta data that you want to include in the header, but want the WebAccelerator system to ignore, put it after a semicolon.
To define a header as a structured parameter when you are creating or editing 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 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:
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
Note: To specify that the parameter name is case-sensitive, enable the Values are case sensitive setting when configuring the parameter options.
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.
1.
On the Main tab of the navigation pane, expand WebAccelerator and click Applications.
The Applications screen opens in a new window.
2.
On the Main tab of the navigation pane in the new window, click Policies.
The Policies screen opens, displaying a table of user-defined and pre-defined acceleration policies.
3.
On the User-defined Acceleration Policies table, click the name of the acceleration policy that you want to edit.
The Policy Editor screen opens, displaying the Matching Rules screen.
5.
From the Add Parameter list on the Matching Rules screen, select a parameter, and then click the Add button. The parameter options display.
7.
Click the Save button.
1.
On the Main tab of the navigation pane, expand WebAccelerator and click Applications.
The Applications screen opens in a new window.
2.
On the Main tab of the navigation pane in the new window, click Policies.
The Policies screen opens, displaying a table of user-defined and pre-defined acceleration policies.
3.
On the User-defined Acceleration Policies table, click the name of the acceleration policy that you want to edit.
The Policy Editor screen opens, displaying the Matching Rules screen.
5.
Click the name of the parameter that you want to edit.
The Parameter Identity screen opens.
7.
Click the Save button.
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 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.
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.
1.
On the Main tab of the navigation pane, expand WebAccelerator and click Applications.
The Applications screen opens in a new window.
2.
On the Main tab of the navigation pane in the new window, click Policies.
The Policies screen opens, displaying a table of user-defined and pre-defined acceleration policies.
3.
On the User-defined Acceleration Policies table, click the name of the acceleration policy that you want to edit.
The Policy Editor screen opens, displaying the Matching Rules screen.
5.
From the Add Parameter list, select Content Type and click the Add button. The Content Type parameter options display.
6.
In the Value(s) area, select Value Matches or Value does not match from the list and check the box next to your selection.
7.
In the Value(s) box, type a regular expression that you want to match or not to match.
8.
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.)
9.
Click the Save button.

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)