Viewing Live Traffic Columns Summaries
|Product Version||1.0.0 and above|
Each Session captured by Fiddler Everywhere has multiple attributes ordered in columns. Where can I find a detailed list of the columns available in Live Traffic and the information extracted from the value of each column? How can I use them to identify HTTP-related issues, track, and debug my website performance, and leave custom comments?
This section lists the available Live Traffic columns and the type of information that they provide. Each colum can be explictly shown/hide through the more option (three vertical dots next to the column name). The column names are also identical to the filters in the Advanced Filters section.
An auto-generated identification number for the currently listed sessions.
Indicates the used protocol, which can be HTTP (Hypertext Transfer Protocol) or HTTPS (secure HTTP). The HTTPS is HTTP but with an added secure layer, which is usually TLS (or SSL). The secure layer encrypts the standard HTTP requests and responses, making them far more reliable than the plain-text HTTP.
Fiddler can decode the encrypted content, but you have to install a trust root certificate to enable this scenario. Once you install it and the HTTPS capturing is enabled, Fiddler is effectively a "man-in-the-middle" and can decode encrypted sessions by toggling Click to show decoded body / Click to show origina body button.
The column inicates the hostname and the port of the server to which the request was sent.
The column contains the URL path, file, and query string from the request.
The column indicates the version of the HTTP protocol used by the session.
- HTTP/1.1—Both the client and the server are communicating in HTTP/1.1.
- HTTP/2—Both the client and the server are communicating in HTTP/2.
- HTTP/2 + HTTP/1.1—The client uses HTTP/2 but the server response is HTTP/1.1.
- HTTP/1.1 + HTTP/2—The client uses HTTP/1.1 but the server response is HTTP/2.
Indicates the HTTP status codes of the response. A server issues the status codes in response to a client's request in the form of a three-digit number. The first digit of the status code specifies one of five standard classes of responses.
- 1xx informational response—The request was received, a continuing process.
- 2xx successful—The request was successfully received, understood, and accepted.
- 3xx redirection—Further action needs to be taken to complete the request.
- 4xx client error—The request contains bad syntax or cannot be fulfilled.
- 5xx server error—The server failed to fulfill a valid request.
The full list of all response status code is available in the HTTP/1.1 status code definition article.
The column indicates the HTTP method used by the request (GET, POST, and so on). The HTTP methods are used to set the desired action that needs to be applied to a given resource.
- GET—The GET method requests a representation of the specified resource. Requests using GET will only retrieve data.
- HEAD—The HEAD method asks for a response identical to that of a GET request, but without the response body.
- POST—The POST method is used to submit an entity to the specified resource, often causing a change in the state or side effects on the server.
- PUT—The PUT method replaces all current representations of the target resource with the request payload.
- DELETE—The DELETE method deletes the specified resource.
- CONNECT—The CONNECT method establishes a tunnel to the server identified by the target resource.
- OPTIONS—The OPTIONS method is used to describe the communication options for the target resource.
- TRACE—The TRACE method performs a message loop-back test along the path to the target resource.
- PATCH—The PATCH method is used to apply partial modifications to a resource.
Indicates the client IP that sent this Request. The IP will often show the loopback address (
0.0.0.0), but it will be different if multiple computers on the network are pointed to a single Fiddler Everywhere instance.
Indicates the server's IP address used for this Request.
Process is the local OS process from which the traffic has originated.
The following example lists sample Process values.
Process: chrome:54000 Process: outlook: 12564 Process: teams:18352
The column shows the number of bytes in the response body.
The column displays the values (if any) from the Cache-Control and Expires headers. If both headers are present, the column will display first the values from Cache-Control and then the values for the Expires header, separated by a semicolon.
The Cache-Control header contains instructions for caching (for both requests and responses).
The following example demonstrates a standard Cache-Control header.
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
The Expires header contains the date/time after which the response is considered invalid. When the Expires header has an invalid date value (for example, 0 or -1), the expiration date is in the past and the resource is already considered expired.
The following example demonstrates a standard Expires header.
Expires: Fri, 20 Apr 2020 19:00:00 GMT
In a scenario where a Cache-Control header with max-age or s-maxage is set, the value from Expires will be ignored.
The Content-Type is the header which originates from the response.
The Content-Type header is an indication of the media type of the resource. It is used with requests of the POST and PUT types where the client indicates to the server the type of data that is sent. The Content-Type header supports the media-type, charset, and boundary directives whose values are separated in the column by a semicolon. An example for a Content-Type header is
You can use different
media-type values to set the type of the passed resource explicitly. For more information, refer to the common
Renders the time when the request was issued in format HH:MM:SS:ms.
Renders the date when the request was issued in format MM:DD:YYYY.
Marks the duration of the session (from ClientConnected to ServerGotResponse events) in milisseconds.
Comments is the field for showing the custom comment.
This column will have a value only if the comment was previously added, for example, when looking into a list of shared sessions with already added comments, or when you explicitly add a comment through Comment in the context menu.