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
Overview
Content Tools
Apps
Reporter Replacement
com.bmc.atlassian.bmc-util-plugin-2.section.label
Tasks