April 24, 2019
Hot Topics:

Fiddler Can Make Debugging Easy

  • September 12, 2006
  • By Robert Bogue
  • Send Email »
  • More Articles »

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.

If I turn on both Hide all 200s and Hide Image Requests I get one session logged in fiddler. It has a 302 meaning that the object has moved. If I remove the Hide all 200s option and leave the hide image requests, I get a total of 14 requests (which aren't images). These requests include the main page, style sheets, JavaScript, and some requests to fetch ad content. Looking for the virtual needle in a field of haystacks is much easier once you reduce the search down to just one haystack. Figure 5 shows a refresh of the Developer.com home page after turning on Hide Image Requests and clearing the sessions.

Click here for larger image

Fewer is better when you're trying to sift through data to find what you want.

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

This status message is the most infamous status on the Internet. It means that the web server couldn't find the content that was requested. If this is the main page that the user has requested this will be obvious as they get a 404 page. However, if it's for a JavaScript file, a CSS file, or other supporting files for the page, the user may not know anything is wrong. The best solution here is to track down the references and update them.

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.

# # #

Page 2 of 2

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date