Fiddler for testers

How does Fiddler work?

Understanding the background

Fiddler sits between HTTP client and server and listens on a port. It acts as man-in-the-middle proxy.When using fiddler, the requests is being sent directly to Fiddler proxy bridge, Fiddler will forward the request to real server, Likewise, the response from server is also sent to the fiddler, fiddler will forward it to the browser. To the client browser, Fiddler claims to be the web server, and to the web server, Fiddler mimics the web browser. In this process, Fiddler intercepts and records all the incoming and outgoing messages.

What’s Fiddler used for?

1. Troubleshooting issues in your web application
2. Security testing
3. Performance evaluations
4. Debugging web traffic from most computers and devices

Commonly used Tabs in Fiddler

1.  Web Sessions
2.  Session Inspector
3.  Statistics Tab [Performance evaluation]
4.  Composer
5.  Fiddler Script

Web Sessions:

On the left-hand side, you have the Web Sessions List area. This contains any web session/HTTP proxy information captured by Fiddler along with some brief summary information for each session

Http Request or Response includes certain key information’s:

List of the all icons with Descriptions:

Sessions Inspectors:

How to work with it?

Double click on a HTTP session, the Inspectors tab on right hand will be displayed, it will allow us to visualize requests or response content in meaningful ways.

Double clicking on a session allows you to view session-specific information under the Session Inspector

Request Inspector

In the top half of the right hand side is the request what was sent to server, there we have multiple tabs of view which shows format of message and data(Headers, Text View, web forms, HexView, Auth, Cookies, Raw, JSON and XML).

Some of the Request inspectors are as follows

[RW] Headers ->Shows request headers and status.

[RW] TextView ->Shows the request body in a text box.

[RW] HexView ->Shows the request body in a hexadecimal view.

[RO] XML ->Shows the request body as an XML DOM in a tree view.

RW-> Read write, RO ->Read only

Response Inspectors

The bottom half is the response tab, this is the entire response being sent back to the client browser, it may possible be HTML page, image, JSON string, Cascading Style Sheet (CSS) and other resources, we can click textview, syntaxview, Imageview and other clickable tab to view it in different format.

Some of the Response inspectors are as follows

[RW] Transformer ->Removes GZip, DEFLATE, and CHUNKED encodings for easier debugging. Can also verify if the response is encrypted in the defined format or not

[RW] Headers ->Shows response headers and status.

[RW] TextView ->Shows the response body in a text box.

[RW] HexView ->Shows the response body in a hexadecimal view.

[RO] ImageView ->Shows the response body as an Image. Supports all .NET image formats.

[RO] XML ->Shows the response body as an XML DOM in a tree view.

[RO] Privacy ->Explains the P3P statement in the response headers, if present.

The Session Inspector tab will show you details for that web session info, including the request and response that was made. This makes it easy to monitor requests that are being sent to the browser. What’s really cool is that because Fiddler acts as a proxy, it shows you exactly what is being sent back and forth from your application.

This information can help you debug issues with your application, and can also be used for security testing to see if there are things being exposed that an attacker could make use of.

Statistics Tab:

Shows the estimated performance statistics for the selected HTTP sessions

This tab allows you to view the number of requests and information about them. Selecting multiple sessions under the Web Session list allows you to see statistics for multiple sessions aggregated together.

Thanks to all of the information available in the Statistics area, it’s a great place to start in order to profile the performance of your website. 

Analysis from the above

You should see things, like how many requests were made (67), who made the requests, the response code returned for 60 Requests-> HTTP 200 responses, 2 requests->Http 301, 2 requests->Http 302, 2 requests->Http 206, meaning everything was fine. If I had bad requests, like 404 errors, they would appear here.

Furthermore, you can quickly see that the majority of wait time for this page to load is due to may be images, etc. If it’s so, then should consider reducing the image sizes or format to reduce the amount of time it takes for website to load.

In our case Application/json takes most of the size

At the bottom of this tab there is also a Show Chart option that visually breaks down the request. This make is easier to see that in my case it is the .PNG format that is causing the longest amount of wait time for www.TestTalks.com.

Composer Tab

The Composer tab is well-named because it allows you, in a sense, to manually create (aka compose), modify and send HTTP requests. You can also take an existing web session and drag it into the Composer tab/copy and then Fiddler will reconstruct that request in its entirety, after which you can execute it.

This is useful, because it means you can change things like User agents and see if your site responds differently based on that information.

1. Highlight any web session.
2. Drag it into the Composer tab.

Expected result after the request has been executed:

1)       In Fiddler the result raw appears with status 200 (OK) (in case the request failed it ‘ll be highlighted in red) and check State field in the response->JSON. State = 0 means the request Succeeded.

State field in JSON response

1. State = 1 means ValidationErrors
2. State = 2 means ServerException
3. State = 3 means InsufficientPermissions
4. State = 4 means AccessDenied
5. State = 5 means AuthorizationTokenExpired

API Architecture

API calls Collection include mainly three things:

1. HTTP headers
2. HTTP Request (POST,GET,PUT,DELETE)
3. Status Code/ Response Code

HTTP headers - HTTP headers are always depended on your application, Mainly two:

Authorization - A token included with requests to identify the requester. This header has to be included in all requests other than the login request.

Content-Type - A standard MIME type describes the format of object data.
Content –type in most of the requests and responses will be application/json.
 

HTTP Request -  There are mainly four requests, which we used frequently: 

POST - Create or Update data

PUT - Update data

GET - Retrieve data

DELETE – Delete data
 

Status Code/Response Code - There are many status/response code, from them we can verify the response.

      200 - OK, The request was successful.
201 - This indicates the request was successful and a resource was created. It is used to confirm success of a PUT or POST request.
204 - No Content, The response is empty.
400 - The request was malformed. This happens especially with POST and PUT requests, when the data does not pass validation, or is in the wrong format.
401 – Unauthorized, Authentication failed, or user does not have permissions for the requested operation.This error indicates that you need to perform authentication before accessing the resource.
403 - Forbidden, Access denied.
404 - This response indicates that the required resource could not be found. This is generally returned to all requests which point to a URL with no corresponding resource.
405 - Method Not Allowed, requested method is not supported for the specified resource.
409 - This indicates a conflict. For instance, you are using a PUT request to create the same resource twice.
500 - Internal Server Error. When all else fails; generally, a 500 response is used when processing fails due to unanticipated circumstances on the server side, which causes the server to error out.
503 - Service Unavailable, The service is temporary unavailable.

Response Codes- Two Levels of Meaning

The first thing to know about HTTP status codes is that they are structured; the first digit indicates what kind of response it is, and the other two indicate specific handling for the response. The kinds of responses defined are:

·         1xx - Informational (also a non-final response)

·         2xx - Successful

·         3xx - Redirection

·         4xx - Client error

·         5xx - Server error