Applies To:

Show Versions Show Versions

Manual Chapter: Policy Management Guide for the BIG-IP WebAccelerator Module: 5 - Configuring HTTP Data Types
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


5

Configuring HTTP Data Types


Specifying HTTP request data type parameters

The HTTP request data type parameters, which are specified within the rules of an acceleration policy, dictate how the WebAccelerator system processes an HTTP request. For example, an HTTP request data type parameter can specify that if a HTTP request matches a certain parameter, the WebAccelerator system sends the HTTP request to the origin server, or that the WebAccelerator system substitutes a certain value when providing a response to the client.

Note

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

In most cases, the default values for the pre-defined acceleration policies are sufficient, but you can fine-tune the WebAccelerator system's 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 specific parameters that you can change see Table 5.1 .

When you specify or modify a parameter for an HTTP request data type, you identify the following information.

  • Identity of the parameter, which can include one or more of the following:
    • The parameter type
    • The name of the parameter
    • The location of the parameter in the HTTP request.
  • The parameter's required value or state for the WebAccelerator system to find a match, from one of the following options:
    • Present in the HTTP request and matches the specified value provided in the form of a regular expression
    • Present in the HTTP request and does not match the specified value, provided in the form of a regular expression
    • Present in the HTTP request, but has no value (is an empty string)
    • Not present in the HTTP request
  • The action that the WebAccelerator system takes if the state or value of the parameter is met. This includes:
    • Whether the WebAccelerator system performs an action on a match or a no match.
    • What action that the WebAccelerator system performs, which is dictated by the rules in the associated acceleration policy.

If you specify that an action is triggered by the request not matching a certain parameter, that action is triggered if the parameter in the request is a different value or is empty (null). The action is not triggered if the parameter does not appear in the request.

Configuring HTTP data parameters

The following table outlines the HTTP data parameters that you can view and configure. The WebAccelerator system uses these parameters for the matching and caching rules it applies when processing HTTP requests.

Note

Lifetime rules, described in Chapter 10, , and responses cached rules, described in Chapter 13, , do not use HTTP data type parameters.
Table 5.1 HTTP request data type parameters
Parameters
Matching Rules
Variation Rules
Assembly Rules
Proxying Rules
Invalidations Rules
Connections Rules
Protocol
x
x
 
x
x
x
Host
x
x
 
x
x
x
Path
x
     
x
x
Extension
x
     
x
x
Method
x
x
 
x
x
x
Query parameter
x
x
x
x
x
x
Unnamed query parameter
x
x
x
x
x
x
Path segment
x
x
x
x
x
x
Cookie
x
x
 
x
x
x
User Agent
x
x
 
x
x
x
Referrer
x
x
 
x
x
x
Header
x
x
 
x
x
x
Client IP
x
x
 
x
x
x

The HTTP data type parameters are defined as follows.

Protocol

A rule that uses the Protocol HTTP request data type parameter is based on the protocol used for the request. You can define caching behavior based on the HTTP and HTTPS protocols.

For example, the following URL uses the HTTP protocol:

http://www.siterequest.com/apps/srch.jsp?value=computers

For example, the following URL uses the HTTPS protocol:

https://www.siterequest.com/apps/srch.jsp?value=computers

Host

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:

http://www.siterequest.com/apps/srch.jsp?value=computers

Results in the following HTTP HOST request header:

HOST: www.siterequest.com

Path

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:

http://www.siterequest.com/apps/srch.jsp?value=computers

http://www.siterequest.com/apps/magic.jsp

Equate to the following paths, respectively:

/apps/srch.jsp

/apps/magic.jsp

Extension

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. Segment keys (the text following 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:

http://www.siterequest.com/images/up.gif

http://www.siterequest.com/images/down.jpg

http://www.siterequest.com/apps/psrch.jsp;sID=AAyB23?src=magic

Method

A rule that uses the Method HTTP request data type parameter is based on the method that is used for the request. You can use the Method parameter to define caching behavior based on the GET and POST methods.

Query parameter

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 request's 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:

http://www.siterequest.com/apps/srch.jsp?action=&src=magic

Note

To specify that the parameter name is case-sensitive, check the Values are case sensitive check box when configuring the parameter options.

Unnamed query parameter

Unnamed query parameters are query parameters that have no equal sign. That is, only the query parameter value is provided on the request.

For example, the following URL includes two unnamed query parameters that have the value of dog and cat:

http://www.siterequest.com/apps/srch.jsp?dog&cat&src=magic

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 cat is an ordinal 2.

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, ordinal 1 provides an empty value.

http://www.f5.com/apps/srch.jsp?&cat&src=magic

In the following URL, ordinal 3 is absent (dog is in ordinal 1 and src is in ordinal 2).

http://www.f5.com/apps/srch.jsp?dog&src=magic

Note

To specify that the parameter name is case-sensitive, enable the Values are case sensitive setting when configuring the parameter options.

Path segment

The Path Segment HTTP request data type parameter is used to identify one of the following values provided:

  • Segment key
  • Segment parameter
Note

To specify that the parameter name is case-sensitive, enable the Values are case sensitive setting when configuring the parameter options.

Segment keys

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.

Segment parameters

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 for the following path:

/apps/search/full;magic/complex.jsp;shop;act

To specify segment parameters, you must also identify:

  • Segment ordinals
  • Segment parameter ordinals
Segment ordinals

To identify a segment, you must provide an ordinal that identifies the location of the segment in the path:

/apps/search/full;magic/complex.jsp;shop;act

You must indicate how you are counting within the path: from the left or the right (always count starting from 1).

For the example used here, /full;magic, the ordinals for this path are as show in Table 5.2 , depending on how you count.

Table 5.2 Segment ordinals example
Ordinal
Numbering Selection
3
Numbering Left-to-Right in the Full Path
2
Numbering Right-to-Left in the Full Path

Segment parameter ordinals

Once you have identified a segment's 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:

/complex.jsp;shop;act

The segment key is complex.jsp and its ordinal is 0. Segment parameters shop and act have ordinals 1 and 2 respectively.

Cookies

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 request's 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:

COOKIE: REPEAT=

In the following string, the REPEAT cookie is absent:

COOKIE: USER=334A5E4

Note

To specify that the parameter name is case-sensitive, enable the Values are case sensitive setting when configuring the parameter options.

User Agent

A rule that uses the User Agent HTTP request data type parameter is based on the value provided for the HTTP USER_AGENT 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:

USER_AGENT: Mozilla/4.0 (compatible; MSIE 5.01; 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.

Referrer

A rule that uses the Referrer HTTP request data type parameters is based on the value provided for the HTTP REFERER 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:

REFERER: http://www.siterequest.com/

You do not typically base rules on the REFERER request header, unless you want your site's 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 user's web portal or search engine.

Header

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%u002e
siterequest%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. Because 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:parmname

Where:

  • 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:

CSP-Global-Gadget-Pref:AT

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:

CSP-Global-Gadget-Pref

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.

Client IP

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.

To add an HTTP data type request parameter

  1. On the Main tab of the navigation pane, click Policies.
    The Policies screen opens, displaying a list of acceleration policies.
  2. Click Edit next to the acceleration policy that you want to edit.
    The Policy Editor screen opens.
  3. From the Request Type Hierarchy tree, click the node to which you want to add an HTTP data type request parameter.
  4. On the acceleration policy menu bar, click the rule for which you want to add an HTTP data type request parameter.
  5. From the Add Parameter list, select a parameter, and then click the Add button. The parameter options display.
  6. Add the parameter options as required.
  7. Click the Save button.

For a new or modified acceleration policy to be in effect for your site, you must publish it. See Publishing acceleration policies , located in Chapter 3, for more information.

To modify an HTTP data type request parameter

  1. On the Main tab of the navigation pane, click Policies.
    The Policies screen opens, displaying a list of acceleration policies.
  2. Click Edit next to the acceleration policy that you want to edit.
    The Policy Editor screen opens.
  3. From the Request Type Hierarchy tree, click the node for which you want to modify an HTTP data type request parameter.
  4. On the acceleration policy menu bar, click the rule that contains the parameter you want to modify.
  5. Click the Edit button next to the parameter you want to edit.
  6. Modify the parameter options as required.
  7. Click the Save button.

For a new or modified acceleration policy to be in effect for your site, you must publish it. See Publishing acceleration policies , located in Chapter 3, for more information.

Classifying HTTP response data types

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 request's 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.
  • The extension of the path in the request.

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.

Note

Groups and object types are defined in the global configuration fragments file. For more information, see Classifying responses .

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 response's content type to match, or not to match.

To specify a regular expression for the Content Type parameter

  1. On the Main tab of the navigation pane, click Policies.
    The Policies screen opens, displaying a list of acceleration policies.
  2. Click Edit next to the acceleration policy for which you want to specify a regular expression for the Content Type parameter.
    The Policy Editor screen opens.
  3. From the Request Type Hierarchy tree, click the node you want to modify.
  4. On the acceleration policy menu bar, click Matching.
    The Matching rules screen opens.
  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.

For a new or modified acceleration policy to be in effect for your site, you must publish it. See Publishing acceleration policies , located in Chapter 3, for more information.




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)