Using variables in Watchpoint filters


Watchpoint filters allow logical streams of object requests to be 'carved' out of from the main flow of requests. These filters are defined by using a filter expression that matches HTTP request headers.

All standard Boolean logic, parentheses and ordered comparisons are recognized. In addition, regular expression matching and basic string matching (using special operators) provide the necessary means to define extremely complex criteria. All string-based operations provide control over case  sensitivity. HTTP-specific abilities have been added through the IP Address facilities and the URL or cookie parameter query ability. The key to the grammar is the use of the following variables:

These variables represent placeholders for the actual data being evaluated. Variables might be compared against literal values or against each other.

Static variables

Static variables are predefined names of fields that are guaranteed to be available in the data. In an expression you can use the following static variables.

Static variables for composing Watchpoint filters

Static Variable

Description

browser

Freeform comment describing the browser types used in an HTTP request. This is the HTTP user agent header.

bytes

Number of bytes transferred during an HTTP request or response.

clean_uri_stem

File path portion of the URL found after the host and port number of an HTTP request. This does not include request

parameters.

client_ip

Client IPv4 address recorded in an HTTP request represented in dotted quad notation.

client_port

Client TCP port number recorded in an HTTP request. This is an integer number in the range between 0 and 65535.

cookie_string

Cookie string found in HTTP request and response headers. This is a string that might include multiple cookies.

e2e_time

The end-to-end time, measured by the time of the last byte that ep16 saw the server send the client minus the byte where

the request started. (this doesn't include latency in the first SYN, but the syn-ack and syn are included if this object was

part of a new tcp connection) . Time is measured in milliseconds.

errors_per_page

This is applicable to page expressions only. It represents the total number of objects that had a completion code of 3 or

higher within a single page.

host

Host portion of the URL captured in an HTTP request represented as a string. Protocol and port number might be present.

host_time

This is the delay between the end of the request, and the first byte of the object. Effectively, this is how long the host thinks about the object. Time is measured in milliseconds.

http_method

HTTP method recorded in an HTTP request. Represented as a string, will always be one of these methods: GET, HEAD, or POST.

http_status

HTTP status code returned in the HTTP response. Integer from 100 to 599.

http_version

HTTP protocol version used in an HTTP response. Represented by a string, normally one of (HTTP/0.9, HTTP/1.0, HTTP/1.1).

kbytes

Number of kilobytes transferred during an HTTP request or response.

mime_type

String that represents the content type header found in an HTTP response. There are no restrictions on the mime-types supported.

nw_time

This represents the delay induced by network data transfer is milliseconds.

objects_per_page

This is applicable to page expressions only. It represents the total number of objects within a single page.

post_query_string

String that contains name value pairs posted in an HTTP request.

referrer

Referrer portion of the HTTP request represented as a string.

server_ip

Server IPv4 address recorded in an HTTP request represented in dotted quad notation.

server_port

Server TCP port number recorded in an HTTP request. This is an integer number in the range between 0 and 65535.

ssl_time

Integer that represents in milliseconds the amount of time spent handling SSL negotiations.

tcp_ooo

Out of order frames as seen from the server to the client. A high number would be an indication of questionable network performance.

tcp_retrans

This is the number of times a server or client retransmits a packet that it's already transmitted - connotes packet loss or a poor connection.

tcp_rtt

The average latency in milliseconds between a TCP frame seen by the server, and the associated ack from the client.

throughput

This represents the bit transfer rate for an HTTP request in terms of bits per second.

uri_query_string

Request parameters found after the '?' in an HTTP request.

uri_stem

File path portion of the URL found after the host and port number of an HTTP request. This does not include request parameters.

Dynamic variables

Dynamic variables are the result of an expression that retrieves a subset of the variable's contents for evaluation. Examples of variables that are known to contain name-value pairs are uri-query and cookie. The name-value pairs contained within these variables are dynamic by nature, due to the fact that they cannot be predefined. Access to them is provided in the grammar by adding the key name, quoted and in parentheses, to the end of the variable name:

cookie("sessionID")

At run-time, this expression is replaced with the value of the sessionID cookie. In this way, you can use the value of a cookie parameter or URI parameter in the same way as static variables. The simple existence of a parameter might be determined by the HASKEY modifier:

cookie HASKEY "sessionID"

Dynamic variables for composing Watchpoint filters

Dynamic Variable

Description

cookie("x")

This dynamic accessor allows the individual cookies in an HTTP header to be addressed individually by name.

post_query("x")

This dynamic accessor allows the individual parameters within a post header to be addressed individually by parameter name.

uri_query("x")

This dynamic accessor allows the individual parameters in the query portion of a URI to be addressed individually by parameter name.

Indexed variables

Indexed variables are variables that have array type elements that might be indexed.

These variables index the path elements of a URI using '/' as delimiters. The index range is 0 to n from the first element or 0 to n from the last element. The following example shows sample notation:

From start: uri_stem_path[i]
From end: uri_stem_path[last-i]

Indexed variables for composing Watchpoint filters

Indexed Variable

Description

uri_stem_path[i]

This dynamic accessor allows specific path elements within a URL to be addressed by position starting from the first position '0'. Alternately, the path elements can be addressed from the last position by using the 'last' keyword.

For example, uri_stem_path[last-i]

uri_stem_path_param[i]("x")

This dynamic accessor allows specific path elements parameters within a URL to be addressed by position and by name. Specifying an index of '0' will result in a parameter addressing of all path elements.

Related topic

Filter-expression-examples

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*