Fiddler Can Make Debugging Easy

Building web applications is hard work. There are so many things that can go wrong, so many technologies to learn, and so many issues that remain undiscovered because everything is designed to allow things to continue to work even when they're not quite right. All of our fault tolerant design begins to work against us.

Most people remain unaware of precisely how their web application is interacting with the web browsers that their clients have installed. If analytics are present on the site then the number of requests ending in a 404 status (File not found) may be logged but identifying precisely why the client was requesting a page in the first place may be difficult or impossible.

This is where Fiddler, a free tool, can simplify the process substantially. Fiddler is a transparent proxy that automatically adds itself to the WININET chain so that it can see every request being made. It logs those requests and the responses to allow you to see what is working and what isn't working.

In this article we'll walk through installing and running Fiddler, as well as some of the common problems that Fiddler will expose for you to resolve.

Installing Fiddler

Installing fiddler couldn't be easier. Simply go to http://www.fiddlertool.com/ and click the download link and download Fiddler. Run the installer and follow the wizard. Like most programs with a Windows installer, Fiddler can be installed with just a few mouse clicks.

Once the installation has completed you'll have a single item — Fiddler — added into the start menu.

Running Fiddler

Running Fiddler is as easy as selecting it's icon in the start menu. When Fiddler starts up it will check to make sure that the version that you have is the current version of the software. It will then start capturing events. (It often starts capturing before it checks for a new version — adding its check for a current version to the capture log.) Figure 1 shows the Fiddler window right after startup.

Related Articles

If at this point you make a request via Internet Explorer or Mozilla FireFox and you'll instantly see a list of the web requests that are being made. This list will continue to grow until you turn off capturing (in the File menu) or clear all of the events (in the Edit menu). Perhaps the first thing to notice is that there are a lot of requests happening &mash many of which that you might never have thought about or considered. Figure 2 shows some of the requests that occurred opening the Developer.com home page.

Fiddler is helpful in two ways, the first way you've already seen. Requests are instantly logged and displayed in summary. However, this just tells you overall what happened it doesn't allow you to dig into the details to understand what is happening with each request. That's why you need to dig into the Session Inspector.

Session Inspector

By simply clicking on one of the sessions in the session list on the left the right hand side of the screen will show you the estimated performance statistics for the session. While this information isn't particularly helpful, the information on the other tabs can be. By clicking the Session Inspector tab you'll see the contents of the request that you sent. The headers button is pressed down by default so you'll see all of the headers in the request. Figure 3 shows the detail of one request made to Developer.com.

This is useful for several reasons, not the least of which is the Cookies that are being transmitted. This is a reliable way to ensure that the browser is transmitting back the cookies your web site may need. For instance, Figure 3 shows a cookie being transmitted to retrieve the Cascading Style Sheet (CSS).

In the bottom half of the right hand side is the response. This is the entire response being sent back to the client browser. By clicking the Headers button you'll see the headers transmitted with the response. This is important because it includes cache directives, cookies, and additional information about the response. This can be used to see whether your web page is transmitting cookies back to the client.

You can also click the text view button to see text type files that are returned or image view for the images that are returned. This allows you to see specifically what was returned to the browser before it was interpreted. This is a much more convenient view than hitting view source on each page you come to — changing the request you're looking at is as simple as clicking on a new request on the left hand side. In addition, since all requests are logged any redirect that you get — that you wouldn't be able to do a show source on in Internet Explorer will also be visible. Figure 4 shows the image view of the request for the EARTHWEB logo.

Of course, with all this information it's easy to become overwhelmed. Just opening the home page of developer.com my browser issued more than 100 requests. Because of this it may make sense to add some filtering so that you can focus on the results that you need.