Get Live Help
The Show parameters in URLs check box controls whether the parameter section of URLs that are monitored by the appliance is included in the URLs stored in the database.
with parameters included, are stored in the database as:
and with parameters excluded, are stored in the database as:
If you are monitoring web sites that use parameters in a widespread manner, you may want to clear this check box, so that these parameters do not keep appearing in the URLs recorded in the database.
During the monitoring of traffic, the Show HTTP request methods in URL check box allows you to control the display of the HTTP request method (GET, POST) in the URLs recorded by the system. By default this option is enabled, but for upgrades this option is disabled. For example, the Resource List would contain the following URLs if this option is enabled:
For a single web page, there could be several different URLs that now appear in the metric database. This may or may not be desired, depending on the application being monitored. For users who are monitoring SharePoint®, it is recommended that this option should be enabled.
Select the POSTs with no content-type should be handled as XML check box to monitor applications where XML content is transmitted in POST requests with a blank content-type HTTP header. The system can then parse the XML according to the Variable Rules you have constructed for XML variables. If your application always has correct content-type HTTP headers, then you would not need to enable this option.
In some network environments, the appliance may be placed in a position where it is monitoring traffic going into a HTTP proxy server that supports dynamic switching to a tunneled protocol. One of the most common cases, is that of a SSL tunnel opened inside of a normal HTTP connection. The appliance supports monitoring this type of tunneling and creates special entries in the Hit resource list to track when these events occur.
The following provides the general sequence of events for an SSL tunnel created through such a proxy:
The client sends HTTP CONNECT to proxy. The CONNECT specifies the final destination host and port (for example, CONNECT www.quest.com:443).
NOTE: Once the client switches to SSL, the appliance begins monitoring and decrypting the SSL traffic, sent over a proxy, which is being sent over the HTTP connection if the administrator has configured a private key for the proxy server. For the appliance’s SSL decryption to work inside of the tunnel, all the end-point hosts must be using this same private key.
This HTTP CONNECT method is unique from all other HTTP methods in that it does not specify a resource with a full URL. To keep track of how often these tunneled connections are being started, the appliance creates an artificial URL to represent the above operation. This artificial URL has the format:
From the above example, this would translate to:
The above statement /CONNECT_TO_host:port URL appears in the appliance’s Hit resource list for each unique tunneled host/port.