An Overview of Telerik Fiddler

Telerik Fiddler is a web debugging proxy that's incredibly useful for developers. This post provides an overview of Telerik Fiddler.

Telerik Fiddler (or Fiddler) is a special-purpose proxy server for debugging web traffic from applications like browsers. It’s used to capture and record this web traffic and then forward it onto a web server. The server’s responses are then returned to Fiddler and then returned back to the client.

The recorded web traffic is presented through a session list in the Fiddler UI:

Nearly all programs that use web protocols support proxy servers. As a result, Fiddler can be used with most applications without need for further configuration. When Fiddler starts to capture traffic, it registers itself with the Windows Internet (WinINet) networking component and requests that all applications begin directing their requests to Fiddler.

A small set of applications do not automatically respect the Windows networking configuration and may require manual configuration in order for Fiddler to capture their traffic. Fiddler can be configured to work in these scenarios, including server-to-server (e.g. web services) and device-to-server traffic (e.g. mobile device clients). By default, Fiddler is designed to automatically chain to any upstream proxy server that was configured before it began capturing - this allows Fiddler to work in network environments where a proxy server is already in use.

Because Fiddler captures traffic from all locally-running processes, it supports a wide range of filters. These enable you to hide traffict that is not of interest to you, as well as highlighting traffic you deem interesting (using colors or font choice). Filters can be applied based on the source of the traffic (e.g. the specific client process) or based on some characteristic of the traffic itself (e.g. what hostname the traffic is bound for, or what type of content the server returned).

Fiddler supports a rich extensibility model which ranges from simple FiddlerScript (C# or JScript 10.0) to powerful extensions which can be developed using any .NET language. Fiddler also supports several special-purpose extension types. The most popular are inspectors, which enable you to inspect requests/responses. Inspectors can be built to display all response types (e.g. the HexView inspector) or tailored to support a type-specific format (e.g. the JSON inspector). If you’re a developer, you can build Fiddler’s core proxy engine into your applications using a class library named FiddlerCore.

Fiddler can decrypt HTTPS traffic and display and modify the requests that would otherwise be inscrutable to observers on the network using a man-in-the-middle decryption technique. To permit seamless debugging without security warnings, Fiddler’s root certificate may be installed in the Trusted Certificates store of the system or web browser.

A web session represents a single transaction between a client and a server. Each session appears as a single entry in the Web Sessions List in the Fiddler interface. Each session object has a request and a response, representing what the client sent to the server and what the server returned to the client. The session object also maintains a set of flags that record metadata about the session, and a timers object that stores timestamps logged in the course of processing the session.

Proxy servers are not limited to simply viewing network traffic; Fiddler got its name from its ability to “fiddle” with outbound requests and inbound responses. Manual tampering of traffic may be performed by setting a request or response breakpoint. When a breakpoint is set, Fiddler will pause the processing of the session and permit manual alteration of the request and the response.

Traffic rewriting may also be performed automatically by script or extensions running inside of Fiddler. By default, Fiddler operates in buffering mode, whereby the server’s response is completely collected before any part of it is sent to the client. If the streaming mode is instead enabled, the server’s response will be immediately returned to the client as it is downloaded. In streaming mode, response tampering is not possible.

Captured sessions can be saved in a Session Archive Zip (SAZ) file for later viewing. This compressed file format contains the full request and response, as well as flags, timers, and other metadata. A lightweight capture-only tool known as FiddlerCap may be used by non-technical users to collect a SAZ file for analysis by experts. Fiddler supports Exporter extensions that allow storing captured sessions in myriad other formats for interoperability with other tools. Similarly, Fiddler supports Importer extensions that enable Fiddler to load traffic stored in other formats, including the HTTP Archive (HAR) format used by many browsers’ developer tools.

Usage Scenarios

Some of the most common questions are of the form: “Can I use Fiddler to accomplish [x]?” While there are a huge number of scenarios for which Fiddler is useful, and a number of scenarios for which Fiddler isn’t suitable, the most common tasks fall into a few buckets. Here’s a rough guide to what you can and cannot do with Fiddler:

An Incomplete List of Things Fiddler Can Do

• View web traffic from nearly any browser, client application, or service.
• Modify any request or response, either manually or automatically.
• Decrypt HTTPS traffic to enable viewing and modification.
• Store captured traffic to an archive and reload it later, even from a different computer.
• Playback previously-captured responses to a client application, even if the server is offline.
• Debug web traffic from most PCs and devices, including macOS/Linux systems and mobile devices.
• Chain to upstream proxy servers, including the Tor network.
• Run as a reverse proxy on a server to capture traffic without reconfiguring the client computer or device.
• Grow more powerful with new features added by FiddlerScript or the .NET-based extensibility model.

An Incomplete List of Things Fiddler Cannot Do

While Fiddler is a very flexible tool, there are some things it cannot presently do. That list includes:

• Debug non-web protocol traffic.
  • Fiddler works with HTTP, HTTPS, and FTP traffic and related protocols like HTML5 WebSockets and ICY streams.
  • Fiddler cannot “see” or alter traffic that runs on other protocols like SMTP, POP3, Telnet, IRC, etc.
  • Handle huge requests or responses.
• Fiddler cannot handle requests larger than 2 GB in size.
  • Fiddler has limited ability to handle responses larger than 2 GB.
  • Fiddler uses system memory and the pagefile to hold session data. Storing large numbers of sessions or huge requests or responses can result in slow performance.
• “Magically” remove bugs in a website for you.
  • While Fiddler will identify networking problems on your behalf, it generally cannot fix them without your help. I can’t tell you how many times I’ve gotten emails asking: “What gives? I installed Fiddler but my website still has bugs!”

The above text is a modified excerpt from the book, “Debugging with Fiddler, Second Edition” by Eric Lawrence. Options for purchasing this book can be found at fiddlerbook.com.