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 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 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.
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.
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.
Filtering the Results
Sifting through hundreds of requests as you navigate your application can be daunting. Minimizing the requests that you don’t want to see can become invaluable. There are two key rules that you can add that will filter the results. They are:
- Hide all 200s — This rule will remove all of the successful web requests. (An HTTP status code of 200 means success.)This is handy when you’re just trying to walk around the application looking for problems and don’t want to have to look through all of the successes to find the missing files, content expiration intervals that aren’t properly set, etc.
- Hide Image Requests — In some ways more valuable than hiding the successful requests. Since there’s rarely debugging that you’re trying to do on how images come down you can hide the image requests.
Common Observations with Fiddler
Once you’ve filtered the results you’re left with the unenviable task of figuring out what the results mean. If you’re tracking down the details of what cookies and form postings are traveling back and forth then it’s simply a matter of walking through the details. However, what if you’re looking at the general health of the application? What do you do with the results that you find? The following sections quickly discuss each HTTP status that you can get back, what it means, and what to do about it.
301 — Moved Permanently
This HTTP status means that a redirect was used – and that the redirect told the browser that the redirect would remain in effect indefinitely. The URL that the web browser asked for has permanently moved to a new location. This may mean that your application is referring to a directory on the web site without a final slash. So if the reference is http://www.thorprojects.com/blog the reference should be http://www.thorprojects.com/blog/ because blog isn’t a file it’s a directory.
302 — Object Moved
This type of status is a temporary redirect. This is the kind of redirect that most developers are familiar with. It tells the web browser that the object has temporarily moved to a new location. These are normal for applications that post back to the same page, validate the input, perform the operation, and then redirect the user to another page. These generally don’t represent a problem unless there are a lot of them.
304 — Not Modified
This type of status indicates that the web browser asked the server if the image had been modified since the browser had cached it. The browser sent a request for the file but indicated in the request that it had a cached copy and that the web server shouldn’t bother sending it back unless it changed. This typically indicates that the cache control headers aren’t present in the responses the browser is receiving. As a result it caches the response but has to check with the web server to see if its cache is still valid. This can be a performance problem. Since not a lot of data is transmitted it doesn’t have a huge impact on overall bandwidth, however, because there can be many of these requests the latency of each call to check whether an image has changed or not can add up to a significant wait time for the user. By setting caching headers in the response that the browser receives these 304 statuses can all but be eliminated.
400 — Bad Request
This status code means that the web server didn’t understand the request from the client. Although this occurs rarely it can be a problem if it’s occurring frequently. This typically points to components integrated into the web server, such as ISAPI filters, which are mangling the request but can sometimes point to poorly encoded data in the request.
404 — Not Found
500 — Server Error
This status message is a bit more ominous than the others here. It’s more ominous because it means that the server wasn’t able to complete the processing of the request. This can indicate a greater server problem or at the very least instability that should be addressed. As with other errors it may be hidden in an embedded object and can be easily missed.
502 — Connection Issue
This status message indicates that a connection message couldn’t be made to the server. This could mean that the name wasn’t translated or that there are problems in the underlying transport of packets to the server. Either case indicates a broader networking issue. You’ll need to make sure that you have thoroughly tested the underlying network before continuing to debug the issue.
Fiddler is the electronic equivalent of an X-Ray that can get into the traffic going between your web application and the web server to make sure that everything is OK. Fiddler can tell you what was wrong in a specific interaction and can show you at a glance what problems there are with the overall conversation. It’s an invaluable tool for anyone who develops web applications — no matter whether that development is in .NET, Java, Cold Fusion, or some other language.
About the Author
Robert Bogue, MCSE (NT4/W2K), MCSA:Security, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He was recently honored to become a Microsoft MVP for Microsoft Commerce Server and before that Microsoft Windows Servers-Networking. Robert blogs at http://www.thorprojects.com/blog.
# # #