If you've ever tried to use Fiddler
to trace Http calls from within an ASP.NET application you've probably found that although Fiddler easily tracks ASP.NET page and AJAX hits against a local (as long as you don't use localhost but the NetBios machine name!) or remote Web server it doesn't work for Web Service or raw HttpWebRequest
calls. In a WinForms or Console application using the default proxy settings works just fine and Fiddler as well as other Http proxies like Charles
automatically pick up the .NET Web Service/Http requests as they run through the Windows HTTP pipeline.
But Web applications are configured a little differently. The reason for the difference in behavior is that ASP.NET (at least in IIS 7 on Vista) disables default proxy detection. As it turns out this is a good thing, because auto proxy detection usually fails in the IIS security context - NETWORK SERVICE for example doesn't have access to the registry where proxy default settings are typically are stored. The result - in the early days of ASP.NET 2.0 - was that often times when making HTTP calls the proxy lookup would hang for a few seconds before giving up and eventually processing the request with a direct connection. The result however was very, very slow operation for the first HTTP operation on a new thread inside of ASP.NET applications. There's more detail about this problem in an old post of mine here.
It looks that now on IIS 7 though this behavior no longer exists however. I suspect the default proxy settings in the web configuration files have been changed from the original settings that ASP.NET 2.0 shipped with. It's a good thing since it didn't work anyway and certainly the expected behavior for a server should be to directly connect to the Internet to retrieve HTTP data and only in special cases require proxy settings.
This change though is the reason that Fiddler or Charles no longer work directly on Web Service or straight HTTP calls using WebRequest/WebClient and if you're expecting to debug a Web Service/Http request you get Nada in these Http debuggers.
There's an easy workaround however. The easiest way to accomplish this is to explicitly specify the proxy settings in web.config:
<proxy proxyaddress="http://127.0.0.1:8888" />
You specify the proxy IP address and port as an Http Uri. These settings above are set for the default settings that Fiddler uses since both ASP.NET and Web Services Clients and Http Clients all access the system.net settings from the configuration.
Applying these settings will make HttpWebRequest, WebClient and WCF or Web Service requests (as long as they're using default ports) pick up the outbound requests and display Http request information.
Debugging Https Requests
In addition remember that if you run Https requests through these types of proxies you'll need to add the specific certificates that Fiddler and Charles install to your personal trusted certificate store. If you don't do this the requests will fail to invalid certificate errors. As an alternative you can set your Web client code to ignore certificate errors.
I'll be at DevIntersection in Vegas this fall giving sessions on ASP.NET Core with Angular and Localization. Thinking of coming? Use discount code STRAHL and save a few bucks. If you do be sure to stop by and say hello!
Other Posts you might also like