Analyzing http and https traffic using fiddler

Fiddler tool can be used for analyzing HTTP and HTTPS (must be enabled from within the fiddler tool) transactions. This tool is a simple to use and by following below tips you can capture and analyze the request and network traffic causing any performance issue. Also you can send the captured logs to support team to get these analyzed if needed. It enables us to inspect all HTTP traffic, set breakpoints, and dig through the incoming or outgoing data. Using fiddler we can check reason for performance bottleneck of a web page, which cookies are being sent to server or what downloaded content is marked as cacheable etc.


Firstly you need to download and install the fiddler tool ( ) and follow the screen instructions to get this installed.

Enabling the traffic for https

  • Open Fiddler and from the top menu click on Tools -> Options and click on the HTTPS tab
  • Check the box for Decrypt HTTPS traffic and agree to any prompts to install the needed certificate for https decryption


  • Select ‘Yes’ to accept and Ignore Server Certificate errors and again click on “Yes” to install the certificate and exit out of the Fiddler options.


Capture the network traffic,

Step1. Open the Fiddler and ensure that Capture traffic is selected under the File menu or press F12.

Step2. Run your application on using any of the browsers, before running this you can make sure that you do not open any other application or browse any site so that it captures the traffic for your application only. You can remove the existing session data by clicking Remove All Sessions.

Step3.  After capturing the data, you can save it to an archive (*.saz)

Analyzing the captured traffic (Important facts)

1.Below are important tabs in fiddler

Statistics – Statistics about selected session. This is one most important section which has high level summary of the request and response times.

Filters – Filter out the http/https traffic logging

Inspectors – One can view/modify request/responses for security testing or general functionality testing. Inspectors can be used to modify request/response, break on requests remove caching etc.

Request Builder – create/build http request using existing previous requests

Timeline – Time map of all requests of a

Auto Responder – replay previously captured or generated traffic when network connection is down during demo etc.

2.Various HTTP status codes and their meaning

200 – The request has succeeded

204 – The server has fulfilled the request but does not need to return an entity-body

206 – The server has fulfilled the partial GET request for the resource and response and must include the header

301 – Moved Permanently

302 – Found, The requested resource resides temporarily under a different URI

303 – The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource

307 – The requested resource resides temporarily under a different URI
304 – If the client has performed a conditional GET request (If-Modified-Since, If-None-Match) and access is allowed, but the document has not been modified, the server should respond with this status code.

401 – The request requires user authentication

3.Two key factors in improving the speed of your Web applications

  • Try reducing the number of request/response round trips –
  • Try reducing the number of bytes transferred between the server and the client

HTTP caching is of the best ways to reduce round trips and bytes transferred. To enhance performance, Microsoft Internet Explorer and other Web clients maintain a local cache of resources downloaded from remote Web servers. When a resource is needed by the client, there are three possible actions

  • Send a plain HTTP request to the remote Web server asking for a resource
  • Send a conditional HTTP request to the origin server asking for the resource only if it differs from the locally cached version
  • Use a locally cached version of the resource, if a cached copy is available

We need to control request/response cache headers for better performance

Cache-Related Request Headers – Pragma: no-cache, If-Modified-Since: datetime, If-None-Match: etagvalue

Cache-Related Response Headers – Generally, the cacheability of an HTTP response is controlled by headers sent in the response. The optional Cache-Control  and Expires headers are the primary mechanisms for a Web server to indicate to a proxy or a client how content may be cached. Expires header contains date or 0 or -1. Cache-Control Header contains public, private, no-cache, no-store, max-age:#seconds, must-revalidate.

Leave a Reply

Your email address will not be published. Required fields are marked *