Page tree
Skip to end of metadata
Go to start of metadata

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 VariableDescription
browser
Freeform comment describing the browser types used in an HTTP request. This is the HTTP user agent header.
bytesNumber 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.
referrerReferrer 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_stringRequest 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 VariableDescription
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 VariableDescription
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