Contact   •   Products   •   Search

Rick Strahl's Web Log

Wind, waves, code and everything in between...
ASP.NET • C# • HTML5 • JavaScript • AngularJs

Debugging Http or Web Services Calls from ASP.NET with Fiddler


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 or WebClient 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:

<system.net>
  <defaultProxy>
    <proxy  proxyaddress="http://127.0.0.1:8888" />      
  </defaultProxy>
</system.net>

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.

Make Donation
Posted in ASP.NET  WCF  Web Services  


Feedback for this Post

 
# Debugging Http or Web Services Calls from ASP.NET with Fiddler
by DotNetKicks.com March 14, 2008 @ 12:46am
You've been kicked (a good thing) - Trackback from DotNetKicks.com
# re: Debugging Http or Web Services Calls from ASP.NET with Fiddler
by Mike Spencer March 12, 2009 @ 5:29am
I found a little nugget about fiddler and localhost, say for use with the VS development server.
If you use
http://localhost./site/page.aspx
(note the period) fiddler will trace it.
# re: Debugging Http or Web Services Calls from ASP.NET with Fiddler
by Marc Beooks March 12, 2009 @ 2:09pm
I remind everyone that if you set cookies to a domain for any reason, you have to have at least one DOT to prevent setting TLD cookies, so you should probably set an entry in the C:\Windows\System32\drivers\etc\hosts file
127.0.0.1 dev.example.com

So you can safely set cookies against the example.com domain (where example.com is approriate).
# re: Debugging Http or Web Services Calls from ASP.NET with Fiddler
by Pete Haas April 13, 2009 @ 9:27am
Great info, now I'm able to see what my .asmx web services are doing. Thank you.
# re: Debugging Http or Web Services Calls from ASP.NET with Fiddler
by Doug August 02, 2009 @ 8:54am
Thanks so much. You rock.
# re: Debugging Http or Web Services Calls from ASP.NET with Fiddler
by ajit goel August 18, 2009 @ 12:23pm
Thanks Rick;
That works however I start getting a lot of timeouts in my client application. Any workarounds that you know of??

Kind Regards;
Ajit Goel
# I have a win32 .net application doing requests to a https site.
by StoreIntegrator March 10, 2011 @ 12:00am
Hi,

I have a win32 .net application doing requests to a https site. However, even with http I do not get any data in Fiddler. A regular browser session is recorded however.

I have set up all:

<configuration>
<startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/></startup>
<system.net>
<defaultProxy>
<proxy proxyaddress="http://127.0.0.1:8888" />
</defaultProxy>
</system.net>
</configuration>

HttpWebRequest httpWebRequest = (HttpWebRequest)WebRequest.Create(url);
httpWebRequest.Proxy = WebRequest.GetSystemWebProxy();

Even this does not work:
//string localHost = "v4a004";// "127.0.0.1";
//WebRequest.DefaultWebProxy = new WebProxy(localHost, 8888);

What do I wrong?

J.
# re: Debugging Http or Web Services Calls from ASP.NET with Fiddler
by Rick Strahl March 10, 2011 @ 10:01am
@StoreIntegrator - you don't have to set up a custom proxy if proxy settings are made in your .config file. In fact that'll likely break the proxy connection. https requests have to be configured in Fiddler so that you can see decrypted HTTPS traffic - go to the options tab and set up the Fiddler certifcate. The help file has more info on how to do this.
# re: Debugging Http or Web Services Calls from ASP.NET with Fiddler
by russ August 31, 2011 @ 6:12pm
Another approach to see what is 'going over the wire'. The system.net classes have trace statements built in that you can switch on in your webconfig.

    <system.diagnostics>
        <trace autoflush="true" />
            <sources>
                <source name="System.Net" maxdatasize="1024">
                    <listeners>
                        <add name="MyTraceFile"/>
                    </listeners>
                </source>
            </sources>
 
            <sharedListeners>
                <add
                  name="MyTraceFile"
                  type="System.Diagnostics.TextWriterTraceListener"
                  initializeData="System.Net.trace.log"
                />
            </sharedListeners>
 
            <switches>
                <add name="System.Net" value="Verbose" />
            </switches>
 
    </system.diagnostics>


There a good article on it here: http://blogs.msdn.com/b/dgorti/archive/2005/09/18/471003.aspx

..and if nlog is your thing, you can send the trace statements to a an nlog NLogTraceListener: http://nlog-project.org/2010/09/02/routing-system-diagnostics-trace-and-system-diagnostics-tracesource-logs-through-nlog.html
 


West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2014