I’ve been working on a couple of apps that do extensive HTTP and Web Service access over the last few days and Fiddler has been a huge help in debugging some odd problems I’ve been having. This ASP.NET Web app has both .NET and FoxPro clients talking to it and checking out the traffic and difference of the client communication was driving me nuts for a while.

One tool I continue to use all the time when working on any sort of distributed application is Fiddler. If you haven’t used Fiddler before, run, don’t walk and download this awesome little proxy that lets you easily see the content of requests made over HTTP over the network. It works great, but keep in mind it doesn’t work for Localhost (it might with a loopback adapter though – haven’t tried it) or over HTTPS in which case you have to remember to step it down to HTTP for debugging. It’s great for debugging problems in distributed applications, but is also great if you need to debug Web based applications for things like Cookies, custom headers etc. What makes Fiddler nice is that shows both content and headers and lets you easily view all of this diverse content in a somewhat intuitive way – for example, images can be previewed, XML can be viewed as a node list and you can apply viewers to any content sent or returned. If you’re building any kind of Web application sooner or later this functionality will come in REAL handy.

Fiddler works by setting up a proxy on port 8888 and then re-routing Web requests through it. It does this by basically changing IE’s proxy settings on the fly.

If you’re using a .NET client though you will have to configure the client in order for Fiddler to be able to see the communication. By default the .NET HttpWebRequest uses direct connections – meaning it doesn’t check or use for any proxies in the system and will thus not be picked up by Fiddler once it’s started.

If you’re using .NET you have to tell the .NET HTTP clients to use a proxy object. .NET allows you to custom configure a proxy using the Proxy property. The Proxy object is available both on lower level objects like HttpWebRequest as well as on higher level objects like a Web Services proxy.

You can configure a Proxy object manually by creating a new WebProxy object:

WebRequest.Proxy = new WebProxy("127.0.0.1:8888",true);

or probably the better choice: You can use the default proxy which reads the Internet Explorer settings for the current user:

WebRequest.Proxy = WebProxy.GetDefaultProxy();

You can apply the same logic to a Web Service client’s Proxy property as well.

If you’re using the MSSOAP Toolkit, you also have to do some custom configuration. You also need to set the Proxy server using the appropriate ConnectorProperty:

THISFORM.oNet = CREATEOBJECT("MSSOAP.SoapClient30")

THISFORM.oNet.MSSOAPInit(lcWSDLURL)

thisform.oNet.ConnectorProperty("ProxyServer")="<CURRENT_USER>"

…

loNL = thisform.oNet.LoadAuthors("");

If you’re using WinInet you can use a Connection type in Interopen:

hInetConnection=;

   InternetOpen(THIS.cUserAgent,;

   THIS.nhttpconnecttype,;

   THIS.chttpproxyname,THIS.chttpproxybypass,0)

Where the ConnectType is 0 for IE Configuration, 3 for custom proxy, and 1 for direct access. Generally you’ll want to use 0. If you’re using wwHTTP in Visual FoxPro, nHttpConnectType is defaulted to 0 which maps to this WinInet setting.