Fiddler is an awesome tool for debugging web services. For the last 10 years, I’ve been using it virtually every working day for web service debugging in scenarios such as:

  • Capturing HTTP requests as they travel through a distributed system, which you have set up on your local development machine.
  • Intercepting and modifying HTTP requests, essentially performing a local man-in-the-middle interception. This is particularly useful if want to modify HTTP requests to simulate functionality which isn’t currently present, modify HTTP headers, etc.
  • Replaying captured requests - useful if you are debugging the way a web service behaves, given a specific request; capture the request, and replay it as many times as you need in order to debug the error.

If you’re doing any work with web services, Fiddler is definitly worth considering. Setting it up is fairly straightfoward

By default, Fiddler can update your browser proxy to route through the Fiddler proxy, which is, by default on port 8888, and will capture requests between Chrome/Firefox/Safari/etc, and your web app.

What if you’re debugging locally, and want to intercept .NET services which call other web services? i.e. Web Browser -> Web App -> Service1 -> Service2 (the one you want to debug)? This can be done by setting defaultProxy in web.config. In this case, since we want to debug Service2, we’d set defaultProxy in Service2’s web.config file.

i.e.

<configuration>
 <system.net>
  <defaultProxy>
   <proxy bypassonlocal="false" usesystemdefault="true" />
  </defaultProxy>
 </system.net>
</configuration>

With one of the distributed apps I frequently work with, I was setting, and resetting the web.config defaultProxy fairly frequently. To save some effort, I wrote a script to automate the change.