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

March 14, 2008 • from Maui, Hawaii • 8 comments

On this page:

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.

The Voices of Reason

Mike Spencer
March 12, 2009

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

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.

Marc Beooks
March 12, 2009

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

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).

Pete Haas
April 13, 2009

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

Great info, now I'm able to see what my .asmx web services are doing. Thank you.

Doug
August 02, 2009

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

Thanks so much. You rock.

ajit goel
August 18, 2009

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

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

StoreIntegrator
March 10, 2011

# I have a win32 .net application doing requests to a https site.

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.

Rick Strahl
March 10, 2011

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

@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.

russ
August 31, 2011

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

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

Rick Strahl's Weblog