Understanding Telerik Fiddler as a Proxy

Understanding how Fiddler Classic and Fiddler Everywhere operates as a web debugging proxy will enable you to see what’s transmitted on the network.

Given the ubiquitous nature of the Internet, many applications are built to assume network connectivity. That’s because a connection to the web can greatly expand the capabilities of an application through the integration of remote data and services. However, this integration is often error-prone; services can become unavailable and data can take a long time to transfer over slow networks. In fact, many bugs can be attributed to conditions relating to the underlying network. In these situations, it’s useful to have a utility that’s able to help you debug the problem; a utility to monitor the network traffic (HTTP or HTTPS) that occurs between your application and the services it relies upon.

Enter Fiddler Classic and Fiddler Everywhere 

What is Telerik Fiddler?

Fiddler Classic and fiddler Everywhere are special-purpose proxy server tools for debugging web traffic from applications like browsers. They're used to capture and record this web traffic and then forward it onto a web server. The server’s responses are then returned to the Fiddler tool and then returned back to the client. The recorded web traffic is presented through a session list in Fiddler's web debugging 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.

“What is a proxy?”

If you had asked me this question back in the early 1990s, I would have likely replied, “It’s that thing that kills your Internet connection, right?” Back in the day, if I found myself with a proxy configured on my machine then I’d sometimes see broken images on webpages. This would be followed by some cursing and many presses of the F5 key. Obviously, things have improved since then. However, the question remains a good one to ask, especially for developers writing applications that will support them.

Section 2.3 of the HTTP specification defines a proxy as:

a message-forwarding agent that is selected by the client, usually via local configuration rules, to receive requests for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface

The phrase, “selected by the client” in the description (above) is a key characteristic; a proxy is designated by a user agent (UA) to convey messages to “origin server” (i.e. google.com). It’s also specialised because it may perform actions on messages that are received. (More on this later.)

Consider this classic (and very funny) scene from the American sitcom, I Love Lucy:

In this scene, when a chocolate travels down the conveyor belt, it’s observed, picked up, wrapped, and then placed back. This is a good way of thinking about how a proxy works. Here, the assembly workers (Lucy and Ethel) represents proxies, a chocolate represents a message, and the conveyor belt represents the network. It’s a brilliant scene because the concepts of network latency and reliability are also personified.

This scene doesn’t represent a network in all its aspects. For example, it only represents outbound traffic. Let’s not forget that HTTP is a request-response protocol. What about inbound traffic? For this, we would have to imagine chocolates simultaneously travelling in the opposite direction. The assembly worker would modify and forward the chocolates in the same manner as before. When this occurs with a network, a proxy is defined as a “reverse proxy” or “gateway.” In other words, an origin server for outbound messages; it translates requests and forwards them inbound.

Telerik Fiddler as a Proxy

Both Fiddler Classic and Fiddler Everywhere are web debugging proxies. That means they act as an intermediary and can troubleshoot the traffic that’s sent between a user agent (i.e. Google Chrome) and the network.

As mentioned above, nearly all programs that use web protocols support integration with a proxy, and Fiddler can be used with most applications without the need for further configuration.

In the most common scenario where Fiddler is the only proxy that’s configured to operate on the network, the architecture becomes a little simpler:

Many web developers will use Fiddler in this manner; to record web traffic that’s generated by a browser to see what was transmitted. Since Fiddler is a proxy, it may process this web traffic before forwarding it upstream. This includes responding to messages on behalf of the origin server. The HTTP specification enables proxies to do this. In fact, Fiddler can be configured to respond to messages that match criteria you define through the AutoResponder. The feature may be configured to serve local files (acting as a cache) or perform actions for messages it receives:

The AutoResponder feature has been updated and renamed to Rule Builder as of July 2021.

The AutoResponder supports a useful development scenario when resources and/or services may be unavailable. It may be used to mock API responses from a service. The AutoResponder may also be configured with a latency setting to simulate a more realistic response time.

The HTTP specification enables proxies to transform messages and their payloads (see section 5.7.2). In the example I cited (above), this is represented by Lucy and Ethel wrapping the individual chocolates as they travel along the conveyor belt. Fiddler is capable of transforming messages as they are intercepted. For example, I can add/remove HTTP headers and modify message payloads.

The transformation of messages is made possible through custom rules written in FiddlerScript. FiddlerScript is one of the most powerful features in Fiddler; it can be used to enhance Fiddler’s UI, add new features, and modify messages. It can even change various characteristics of the network or client as messages are transmitted. For example, I can write FiddlerScript to simulate conditions of the browser (i.e. no cookies) or reroute traffic.

Eric Lawrence has written a great article, Understanding FiddlerScript, where he describes its available functions. He’s also published a list of FiddlerScript “recipes”: Fiddler Web Debugger - Script Samples.

The More You Know

Understanding how Fiddler operates as a web debugging proxy will enable you to target scenarios where you’re interested in seeing what’s transmitted on the network. Once you have Fiddler configured correctly, you’ll be able to use its large set of features.

To get started, why not try one of the Fiddler tools and kick the tires for yourself? Take advantage of the 30-day trial offered for Fiddler Everywhere, which runs across Windows, macOS, and Linux.