If you do any web application develeopment, you’ve probably run into the situation of needing to see the HTTP requests/responses when troubleshooting issues. In general, there are two types of request/response scenarios that you typically deal with:
- Web browser / web server
- Web server / web server
Web browser / web server includes standard web page retrieval as well as AJAX content retrieval (HTML and JSON). Web server / web server includes RPC-style communications such as SOAP, REST, XML, etc. In this post I’d like to demonstrate how you can use Fiddler to monitor and debug both types of scenarios. In both scenarios, Fiddler works by behaving as a proxy “server” between the client and server, thereby allowing you to view both the of both the request and response (Fig. 1 below shows an example of using Fiddler to capture request/response traffic between a web browser and google.com).
Web browser / web server
As shown in Fig 1. above, Fiddler allows to us capture and inspect the request/response traffic between web browsers and web servers. The configuration steps for this are pretty straightforward:
- Install Fiddler if you haven’t already and run it.
- On the File menu, make sure that Capture Traffic is selected.
- That’s it! All web browser traffic (including AJAX calls) will now be captured in Fiddler, so fiddle away!
How does this work? A quick glance at the Proxy Settings screen in Control Panel | Internet Options | Connections | LAN settings | Advanced reveals the answer (Fig. 2).As the image shows, there is now a “proxy server” (Fiddler) configured on the machine, to which the web browser will send all requests. Fiddler captures the details of the request, retrieves the content from the requested URL, captures the details of the response, and then returns the response to the browser. Crafty!
Web server / web server
Although the end goal with this scenario is the same (capture request/response traffic), there’s some additional configuration required. This is because, unlike web browsers, .NET doesn’t automatically honor the Control Panel proxy settings. Fortunately, .NET allows us to add a setting to the <system.net> element in the application’s web.config file (or app.config file for a Windows or console application) that will instruct .NET to do just that:
<system.net> <defaultProxy> <proxy usesystemdefault="True" /> </defaultProxy> </system.net>
With this setting in place, .NET will route all web service requests through the default proxy, which, while Fiddler is running, is Fiddler (remember Fig. 2 above?).
One additional item to note: In both scenarios, if the traffic that you’re wanting to monitor is traffic to a server on your machine (i.e. “localhost”), you’ll find that the traffic doesn’t get captured even with these configurations in place. This is because web browsers (or at least IE) and the .NET Framework are configured to ignore proxy server settings when the requested URL is for “localhost” (see this FAQ on the Fiddler website for more info). The easiest workaround to this is to use “localhost.” (notice the “.”) as the URL. This URL gets around the “localhost” issue but will still resolve to your local server. In Visual Studio, you can configure this URL in the Web tab of the web project’s properties, as shown in Fig 3. below (Note: the port 2232 listed is because this app is being developed using the Visual Studio development server. This has nothing to do with Fiddler configuration. The appropriate port for your app will depend on your environment).