Contact   •   Products   •   Search

Rick Strahl's Web Log

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

Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies


Http monitoring tools are essential when doing any kind of Web development whether it’s for plain Web development, Web Services or any sort of HTTP client work. When things go wrong it is often highly useful to take a look under the hood and dig into the raw HTTP request data to see what HTTP headers were sent from the client to server and what headers and responses come back. 

For plain Web development most of the time I actually use FireBug inside of FireFox, but when more detailed HTTP wire debugging is required I quickly revert to Fiddler, because it tends to provide more information and options on dealing with request data. But even more importantly, FireBug – cool and useful as it is as the Swiss Army knife for Web development debugging - is limited to life inside of FireFox, so it does nada when you need to look at content outside of the browser such as when a .NET application fires HTTP requests against a server.

One of the reasons that Fiddler works so well is because it has a nice, simple and very usable UI that makes it easy to monitor HTTP requests. It also includes a nice request builder which is great for building up requests for testing without having to run code to generate a request against a service for example. In addition there are a few handy viewers that simplify viewing common types of content.

Fiddler

Before I get into the discussion of using Fiddler with .NET HTTP clients like WCF or Web Service proxies or WebClient/HttpWebRequest objects, here are a few basic tips when using Fiddler for debugging in general:

Running Fiddler against local Addresses

If you’re using Fiddler with a localhost or 127.0.0.1 address you’ll find that Fiddler will not monitor requests. The reason for this is that local addresses typically bypass any proxies (and the network adapter in general) and so localhost or 127.0.0.1 doesn’t show up.

Luckily there’s an easy workaround for this: Instead of using a local address use the NetBios Machine name or the local IP address:

http://rasnote/weblog/default.aspx

or

http://192.168.0.104/weblog/default.aspx

And voila you have access to local addresses.

Visual Studio Web Server (Cassini)

What about the ASP.NET local Web Server (Cassini)? There’s a nasty hack for accessing Cassini requests through Fiddler:

http://127.0.0.1.:88/default.aspx

Notice the . after the 127.0.0.1 and before the port number. I’ve only had luck in using 127.0.0.1.  as the domain/address -localhost or the local machine name don’t work.

Using Fiddler with other Browsers

Fiddler works automatically with Internet Explorer. When Fiddler and IE are both open requests made in IE are automatically monitored in Fiddler (unless you explicitly turn monitoring off). You can also use Fiddler with other browsers by configuring the proxy settings manually or by running Fiddlers configuration script.

Fiddler by default uses the proxy address of 127.0.0.1 and port 8888. You can manually configure this in just about any browser. For example in FireFox you can set up the proxy settings like this:

FireFoxFiddlerSettings1

Alternately you can use Fiddler’s startup configuration script which can be fired when FireFox starts. You can set this up on the dialog above like this:

FireFoxSettings2

The full script reference looks like this:

file:///C:/Users/rstrahl/Documents/Fiddler2/Scripts/BrowserPAC.js

When set this script is set FireFox checks if Fiddler is running when it starts up and if so sets the Proxy automatically. Otherwise no proxy is set. However, unlike IE this setup will not detect when Fiddler is shut down so requests will try to use the proxy that is then no longer there. You either have to stop and restart FireFox, or alternately you can manually go to the above dialog on hit the Reload button to reload the script.

This process is not quite as smooth as it is with IE, but using the startup script is pretty easy as long as you remember to re-start FireFox to pick up the latest running status of Fiddler. I can live with that for debugging scenarios.

Getting Fiddler to work with .NET Client Requests

If you’ve run .NET client requests and tried to capture them with Fiddler you’ve probably noticed that .NET client requests don’t show up. This makes sense since proxy information must be configured somehow first in .NET as it doesn’t use the default settings that are provided through WinInet and the registry.

The scenario is as follows: You’re debugging a Web Service or a WebClient request in a client application or a test project and you would like to see what the HTTP response from the server looks like.

Most of the .NET HTTP clients – WebClient, HttpWebRequest, WCF or Web Service Clients – all have Proxy properties that you can set explicitly. In code this looks like this:

AppletService service = new AppletService();
service.Proxy = new WebProxy("127.0.0.1",8888);
WebServiceProxies.AppletService.Files[] files = service.RetrieveConfirmationList("0020575", "esa479");

Fortunately you don’t have to do this in code for every request. Instead you should preferrably use configuration file settings in the <system.net> section to configure the proxy:

<configuration>
  <system.net>
    <defaultProxy>
      <proxy  
              usesystemdefault="True"
              bypassonlocal="False" />
    </defaultProxy>
  </system.net>
</configuration>

The above reads the default system settings and uses them. So when Fiddler starts it sets the system settings and your application then can read and use these settings.

This should work fine for real client applications, however, if you’re running in a server application like ASP.NET you probably don’t want to do this because a registry lookup is required which can be really slow for a server application because it typically doesn’t have rights to access these settings.

If you need to look at HTTP client requests made by an ASP.NET application it’s best to configure the proxy explicitly by providing the proxy information in the web.config file and setting usesystemdefault=”False”

<configuration>
  <system.net>
    <defaultProxy>
      <proxy
              usesystemdefault="False"
              bypassonlocal="True" 
              proxyaddress="http://127.0.0.1:8888"              
              />
    </defaultProxy>
  </system.net>
</configuration>

This should let you see any Http requests fired from your server application i n Fiddler.

Make sure you enable All Processes in Fiddler

In Fiddler 2.x there was a change that allows filtering requests via a very unobvious status bar selection list. By default only browser requests can be tracked and all application requests are run through the proxy but don’t actually show up in Fiddler. To let your .NET applications (or any other application other than a browser including WinInet Clients) you need to make sure you set the filter to “All Applications”:

AllProcess

Clicking on the panel cycles through the options which is Web Browsers, Non-Browser, None and All Processes.

Thanks to Ryan Heaney who via Twitter pointed out this option which I completely overlooked and didn’t even find until he pointed it out. Talk about unobvious UI feature, although it’s actually nice ONCE you know where it is. It’s useful to keep other apps like feedreaders and twitter from posting to Fiddler when the setting is not set to All Processes.

The Underlying Connection was Closed

[section added 05/24/2009]

When running multiple authenticated requests with Fiddler in a .NET app you might see the following error:

The underlying connection was closed: A connection that was expected to be kept alive was closed by the server.

This is due to the fact that .NET by default closes connections after each requests, but Fiddler expects the connection to the proxy to be kept open (which is standard client proxy behavior). Typically what you’ll see is that the first request works, the next will fail with the error. If you retry the next will work, then fail again as the connection is closed on subsequent requests, re-opened when you retry.

There are two ways around this:

  • Tell .NET to keep connections open
  • Tweak the Fiddler Startup Script  to account for dropped connections

If you’re using  an HttpWebRequest object the process is fairly easy by adding adding headers to the request. You can set “Keep-Alive”,”On” or alternately explicitly force the connection to be closed with “Connection”,”close” which closes the connection completely.

WCF services can manipulate their underlying connection objects via the OperationContextScope() class, through which you can gain access to Http headers the client sends. Unfortunately, though the Connection and Keep-Alive headers cannot not be changed – WCF and only WCF controls those, so there’s no way to override the .NET behavior with these.

Luckily Fiddler is developed by a Microsoft developer who’s aware of this issue and so there’s actually a switch in the Fiddler configuration script that can be set to force Fiddler to automatically force connections closed. To do this open Fiddler’s CustomRules.js file (Rules | Customize Rules or Ctrl-R) and uncomment the following script block:

// Uncomment to reduce incidence of "unexpected socket closure" exceptions in .NET code.  
// Note that you really should also fix your .NET code to gracefully handle unexpected connection closure.
//
 if (!(((oSession.responseCode == 401) && oSession.oResponse["WWW-Authenticate"].Length > 9) || 
  ((oSession.responseCode == 407) && oSession.oResponse["Proxy-Authenticate"].Length > 9))) {
   oSession.oResponse["Connection"] = "close";
}

The above is commented in Fiddler's CustomRules.js  in the OnBeforeResponse method. Uncommenting the code above makes the successive Web Service calls work with Fiddler attached. As the comment mentions above this isn't ideal but it works - you may have to resort to a few additional conditions with NTLM Authentication as mentioned in this post:

http://blogs.newsgator.com/inbox/2006/09/fiddler_and_net.html

Monitoring HTTPS/SSL Connections

[added section 09/17/2009]

By default Fiddler doesn’t work with HTTPS/SSL requests which makes most people think that you can’t use it for SSL requests. It seems counterintuitive that an HTTP proxy should be able to decrypt SSL requests – after all it’s supposed to be secure and intractable, right? But this is possible because you’re explicitly installing a trusted certificate that can decrypt SSL traffic on your local machine.

It’s relatively straight forward to configure Fiddler to work with most SSL based sites (but not all of them if strict policy requirements are enabled on the server).

To use SSL you can enable HTTPS functionality in Tool | Options:

SSLOptions

and follow the instructions in the Learn more… options. Basically you’ll have to move the Fiddler installed client certificate from the personal store to the trusted certificate store and let Fiddler intercept the SSL requests. I highly recommend reading through the page as well as the Fiddler FAQ that describes the SSL issues and how this works in some detail.

If you want to quickly get going (pulled straight from the Fiddler page:

  1. Visit a HTTPS site with Fiddler2 running, ensure that you see the Certificate Error warning page
  2. START > RUN > CERTMGR.MSC
  3. Drag the DO_NOT_TRUST_FiddlerRoot certificate from the Personal folder to the Trusted Root Certification Authorities folder

certstore

Once you’ve done this you should be able to hit most SSL enabled sites.

Note that you probably should remove this certificate from the secure store once you’re done and add it only as needed. For more info see the Fiddler HTTPS page.

If Fiddler won’t work give Charles a Try

Fiddler is very nice when it works, but there are a few situations when I’ve had no luck with Fiddler. Specifically if you can’t explicitly set the Proxy in the client application such in a live server. When Fiddler doesn’t work or if it’s a pain to set up I fall back to Charles, which is Java based Http Proxy Monitor. It has many of the same features that Fiddler has, but it works much more transparently in that you don’t need to configure anything – Charles monitors any HTTP traffic on the wire and monitors it.

 Charles[4]

The first request above for example is a Cassini request and there’s no configuration of any sort to get Charles to monitor this request – it just works. You can view the request and response in a variety of ways. The view is not as nice as Fiddler’s split view but you can get the same information. One thing that Charles doesn’t do is auto-decode pages that are encoded with Gzip, which is kind of a bummer.

Charles is not free, but it’s worth the $50 registration to have a no-config Http Monitor that works in most environments. It’s saved my butt in a lot of situations…

Bottom line is that I still prefer Fiddler when it works because the UI is cleaner, easier to work with for many requests, easier to look at different kinds of contents and more configurable, but I keep around Charles if Fiddler doesn’t work or doesn’t work without complex configuration. In that respect Charles can be a life safer especially if you need to do some trouble shooting on a client or server machine in a hurry without having to fuck with configuration settings in the browser or configuration files.

Make Donation
Posted in WCF  .NET  Web Services  


Feedback for this Post

 
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Michel Schep January 14, 2009 @ 2:44am
Hi Rick,

Another way of using Fiddler and the ASP.NET local webserver Cassini is putting an extra line in the hosts file:

127.0.0.1 development

Now I can use http://development:<port> in stead of http://localhost:<port>
and all http traffic is shown in Fiddler.

Michel
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by The Luddite Developer January 14, 2009 @ 4:50am
RE: "If you’re using Fiddler with a localhost or 127.0.0.1 address you’ll find that Fiddler will not monitor requests."

One tip is to add a period(.) after the word localhost. This works for me.

For example:

http://localhost./mydevsite/default.aspx
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by ParanoidPenguin January 14, 2009 @ 5:35am
"This makes sense since proxy information must be configured somehow first in .NET as it doesn’t use the default settings that are provided through WinInet and the registry."

I thought that .net clients did use default settings, though perhaps this was for v2.0 onwards?
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Denis January 14, 2009 @ 6:00am
Using ipv4.fiddler as the host name is sometimes useful as well.
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Jeff January 14, 2009 @ 7:19am
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Marc Brooks January 14, 2009 @ 9:46am
If you want domain scoped cookies to work, your request's authority MUST have two dotted elements (e.g. google.com) or cookies set to the domain will be ignored. This is intentional to prevent you from setting a cookie for the entire .com domain (for example). Given this and all the other weirdnesses associated with localhost and 127.0.0.1; I ALWAYS set a hosts entry for any website I'm developing to a local host name (e.g. local.tidycats.com). That way I can guarantee that when I deploy things will be the same and as a huge benefit Fiddler and such tools do NOT consider this a local request. So, in C:\Windows\System32\drivers\etc\hosts add the line (adjusted as desired):

127.0.0.1 local.example.org
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Rick Strahl January 14, 2009 @ 9:55am
@ParanoidPenguin - I think the default setting in .NET 2.0 was indeed UseSystemDefault, but I believe that was changed in .NET 2.0 SP1 because it was causing problems for Web applications which would hang trying to get to the proxy settings. After SP1 *I think* we're back to no proxy checks and direct TCP access.

@Luddite - I've had no luck with localhost. as the domain name nor using the NetBios name. For me only 127.0.0.1. works.

@Michael - HOST mapping for localhost is a good suggestion - maybe a good idea instead of using a NETBIOS name since you can control it better. Nice tip.

@Marc - Are you sure this is the case (2 dots or no cookies)? I always test AJAX and ASP.NET locally with my NetBios name and I know for a fact that cookies are working in this scenario (otherwise my Session usage would cause apps to fall down). Agree with your point though - localhost causes all sorts of cookie carnage for me as well especially in FireFox.
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Harry M January 14, 2009 @ 10:12am
HTTPAnalyzer is great for this, but unfortunately its not free :(
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Nick Berardi January 14, 2009 @ 12:42pm
Hi Rick,

I like to use "www.somesite.com" which has a DNS entry for "127.0.0.1". I like this method better than "127.0.0.1." because it actually looks normal and is easier to type. If I remember right you can also use any address you want such as "rick.somesite.com" which will also go back to "127.0.0.1".

I wrote about this a while ago http://www.coderjournal.com/2008/03/localhost-http-debugging-with-fiddler/

Plus it is very easy to setup in your project config, and it allows you to debug multiple domains if necessary. So that is why "somesite.com" is my preferred way to force requests through fiddler. As a side not you can also add this in to your own DNS if you would like, so that the requests stay internal to your network.
# Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by DotNetShoutout January 14, 2009 @ 2:04pm
Thank you for submitting this cool story - Trackback from DotNetShoutout
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Kevin Read January 14, 2009 @ 3:07pm
Have a look at HttpFox. It's a firefox add-on which is great for examining requests/responses... all within Firefox. Since discovering it, I haven't gone back to Fiddler.
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by redsquare January 15, 2009 @ 7:25am
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Yaron Naveh January 15, 2009 @ 3:07pm
In case when all proxy utilities fail one can also use tcpmon (or equivalent) to follow the sent/received messages.
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Rick Strahl January 15, 2009 @ 3:19pm
@Yaron - yeah but I wouldn't recommend that (or something as low level as WireShark) since they provide way to much information unless you have filters pre-configured just right.

I think you'll find that Charles or WebScarab work in just about all situations and are better suited for HTTP tracking.
# Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies - DotNetBurner January 15, 2009 @ 5:07pm
Burned by DotNetBurner.com - hot .net content! DotNetBurner
# #.think.in infoDose #16 (12th Jan - 16th Jan)
by #.think.in January 18, 2009 @ 2:31pm
#.think.in infoDose #16 (12th Jan - 16th Jan)
# What Gives? Fiddler Not Capturing Local Address
by Guy kolbis January 20, 2009 @ 12:10am
I have grown to love working with fiddler. Fiddler is a debugging proxy that allows you to monitor HTTP
# My Developer's Toolbox
by its coding time January 24, 2009 @ 4:07am
My Developer's Toolbox
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Kerem Kusmezer January 26, 2009 @ 7:30pm
There is a less known feature in .Net Framework for debugging Tcp Connections since version 2.0 which can be used without using any proxy server to inspect the communication.
Just add the following lines to your app.config, and voila the tcp stack will be just traceable.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.diagnostics>
<trace autoflush="true" />
<sources>
<source name="System.Net">
<listeners>
<add name="TraceFile" />
</listeners>
</source>
</sources>
<sharedListeners>
<add
name="TraceFile"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="NetTrace.log"
/>
</sharedListeners>
<switches>
<add name="System.Net" value="Verbose" />
</switches>
</system.diagnostics>
</configuration>
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Rick Strahl January 26, 2009 @ 8:28pm
@Kerem - yes I know but the information provided by the trace handlers is much too verbose and can't just give back the actual HTTP content. While TCP tracing can be really useful, for everyday debugging of Web or Web Service requests this is too much of a pain in the ass since I need to see a lot of traces repeatedly.
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Rich Larson February 03, 2009 @ 5:19pm
Rick - I just wanted to say "Thank you SO MUCH!" I have been trying to monitor webservice calls from my local client to my local .NET Cassini server working and your "period" hack worked the charm! Thanks again!

Rich Larson
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Scott Mitchell February 12, 2009 @ 8:03am
Rick, great article on using one of the best web debugging tools! You covered quite a bit here, but there's one area that you omitted: debugging HTTPS requests. Fiddler 2.0 has built-in support for decoding the SSL traffic (assuming the feature is enabled), but you can still get exceptions that read: "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel."

This is documented in Fiddler's Known Issues section (http://www.fiddlertool.com/Fiddler/help/knownissues.asp), and addressed in other blogs (http://grootveld.com/archives/22, for instance), but would make a great addition to this piece.
# About REST web service in C#
by Raj February 21, 2009 @ 2:20am
Hi all,

I hv used WCF REST collective service. from template, It create .svc, .svc.cs and .base.svc.cs file. In which file I use my function and how I will call to my another simple default.aspx page...


Thanks



Raj
# Wanted to pass on a 'dooooh' that prevented me from using for Web Service traffic
by Tom Leonard February 26, 2009 @ 7:33am
I appreciate all the comments here but wanted to pass on a 'dooooh' that kept Fiddler from seeing my web service traffic....I struggled with this for a few hours yesterday. So while Fiddler would see all my browser traffic and just about everything else, it would not display my HttpClient traffic to a localhost web service….

This was because when I added my reference, it uses the default setting of ‘localhost’ or 127.0.0.1 rather than my machine name and it appears that clients using locahost web services bypass default proxies. In my client app, I right-clicked on my web service reference and changed Web Reference URL from
http://localhost/MeterFetchWS/FetchReadings.asmx to http://MyMachineName/MeterFetchWS/FetchReadings.asmx

Updated reference that changed the property below, and Fiddler was able to trap HttpClient traffic….Captain Obvious here....

<Setting Name="CIS_Import_Submetering_HexagramReadFetch_FetchReading" Type="(Web Service URL)" Scope="Application">
<Value Profile="(Default)">http://tleonard/MeterFetchWS/FetchReadings.asmx</Value>
</Setting>

hope this helps somebody else.....
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Rama May 25, 2009 @ 4:39am
Hi Rick
Thanks for posting such a usefull information on fidder with asp.net.
I am experiencing one problem during my test.. might be I am doing any mistakes.
I am able to view request & response fine with web pages on my local development machine... but when I am trying to test the same with remote partner web service request & response with in the same web application, getting underlying connection closed/unable to connect error. But when I tried the same connection without fidder I am getting response fine.

Can you please help me on this ?

Rama
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Rick Strahl May 25, 2009 @ 3:27pm
@Rama - Yes this has to do with .NET by default closing connections and so the proxy gets dropped. Usually this happens when on every other request - first one works, second one fails. Retry work, next one fails etc.

There's more info here:
http://www.west-wind.com/Weblog/posts/177835.aspx

Basically you can change the fiddler default script to NOT close connections after requests, or alternately set .NET to force to set Keep-Alives on.
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Chris Wigley June 09, 2009 @ 2:10pm
Rick,

Any ideas how to get Fiddler to see gzipped responses from a WCF request? I can see uncompresssed response, but I need to see the gzipped response. This is all running locally. I've got a custom Office Add-In (running in local instance of office 2007) making a request to a .svc file in a site hosted locally (on same box), so all traffic occurs on same box. Thanks in advance for any tips/suggestions.
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Rick Strahl June 09, 2009 @ 3:40pm
@Chris - not sure what you mean. Fiddler supports GZip decoding. Just double click the yellow header in the raw output to see the decoded output.
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Eric Lawrence September 29, 2009 @ 12:53pm
Thanks for the great tips!

<<This is due to the fact that .NET by default closes connections after each requests, but Fiddler expects the connection to the proxy to be kept open >>

It's actually sorta the opposite. .NET throws an exception if an upstream connection is closed without a "Connection: close" on the HTTP response. Because Fiddler often closes the client connection (changed in more recent versions) but doesn't add a "Connection: Close" header, the .NET Exception occurs.

IMO, this is a bug in the .NET Framework (RFC2616 allows idle connection closure at any time without advance notice), but it's been there forever.
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Rick Strahl September 30, 2009 @ 3:14am
Thanks for the clarification Eric. This particular issue has caused me a lot of grief and not just with Fiddler connections but also in some live server environments. It would be nice to get this fixed...
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by JK February 13, 2010 @ 10:23am
Does fiddler work with .net console applications? Added the proxy 127.0.0.1:8888 etc etc and still nothing from Fiddler?
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by JK February 15, 2010 @ 4:31pm
oops, had an extra request.Proxy = null; in there.
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Adam Coyne March 18, 2010 @ 9:55pm
I found this page while trying to use Fiddler to monitor client requests made by an ASP.NET application. Adding proxyaddress="http://127.0.0.1:8888" in web.config as you suggest above works, but it means that I have to edit web.config when I close Fiddler, or all client requests will fail since the proxy is gone.

Another (tricky) way of doing this is to specify usesystemdefault="True", and run Fiddler as SYSTEM using Sysinternals psexec: psexec.exe -i -d -s "C:\Program Files\Fiddler2\Fiddler.exe"

That enables me to see the requests and have them still work when I close Fiddler.
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Nick W May 19, 2010 @ 9:58pm
Thank you for writing this! I have been tearing my hair out trying to understand why Fiddler wasn't logging my WCF traffic when it had been working just fine previously, and I was essentially able to prove that it was hitting the proxy by forcing use of localhost:8888 as the proxy and watching it fail when Fiddler wasn't running but succeed when it was. That stupid "All Processes" button at the bottom had gotten cycled.

Also, in .NET 4, VS 2010, the newest version of Fiddler as of today (5/19/2010) and Windows 7, using 127.0.0.1.:12345 (with the dot before the colon) to connect to Cassini and have it run through Fiddler doesn't work: I get "The remote server returned an unexpected response: (502) Proxy Error ( The parameter is incorrect. )." However, localhost.:12345 (again, dot) does, and does get logged by Fiddler.
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Tom June 21, 2010 @ 4:14am
You can also use http://ipv4.fiddler/my/path instead of 127.0.0.1. For ipv6, use ipv6.. ;-)
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Jim Gorman July 13, 2010 @ 8:09am
Thanks a lot, Rick.

Your advice on 'Getting Fiddler to work with .NET Client Requests' really helped me out.

Much appreciated.
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Karthikeyankomar September 21, 2010 @ 7:59am
Dude..thanks for the proxy info that you had mentioned.It helped me.
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Mike November 01, 2010 @ 9:50am
Have you use Fiddler to test http traffic out of any browser?
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Michael April 05, 2011 @ 8:05am
Hello,
I have had some issues working with Windows 7 and Windows Server 2008. I do have a WCF services(basig binding ,WS-*) .

I am using a Windows service to host this service, but this service run as NetworkService credentials. So I am not able to capture the traffic, because the WCF is running under different credentials. In order to capture the SOAP messages, I used to run Fiddler as the same credentials the Service is running.

This can be done in Windows 7 using ALT+SHIFT+Click over Fiddler shortcut and selectiong "Run as different User". Then , I set the NetworkService credentials, and I can capture the Web traffic.

Have you ever seen this behavior?
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by dave September 27, 2011 @ 7:25am
I have Win7 and am trying to monitor webclient requests in VS2010. I checked that the "All Processes" option at the bottom of the screen was visible. I then tried the code below in the web.config file:

<configuration>
<system.net>
<defaultProxy>
<proxy
usesystemdefault="False"
bypassonlocal="True"
proxyaddress="http://127.0.0.1:.8888"
/>
</defaultProxy>
</system.net>
<system.web>
<compilation debug="true" strict="false" explicit="true" targetFramework="4.0"/>
</system.web>
</configuration>

It doesn't work. I then tried changing the proxyaddress to:

127.0.0.1.:12345

..and

localhost.:12345

...and they don't work either.
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Monish Nagisetty October 18, 2011 @ 11:05am
Dave,

Did you try setting bypasslocal to false?

http://msdn.microsoft.com/en-us/library/sa91de1e.aspx

Thanks
Monish
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by da November 11, 2011 @ 11:47am
In Fiddler2 I am getting a 502 Error for all requests. It was working initially and all of the sudden it doesnt work anymore. I and pulling my hair out over this. Where should i start to look to fix this?
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Hemant December 25, 2011 @ 11:43pm
HTTPS page don't load when I have fiddler open. When I close fiddler, i 'm able to access the https page. Any setting that I 'm missing that I should enable?

Thanks,
Hemant.
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Rick Strahl December 26, 2011 @ 8:05pm
@Hemant - you have to enable HTTPS/SSL operation in fiddler. Its on the Tools dialog and you have to install the Fiddler SSL certificate to make it work. There's more info on the link on the tools page that explains how it's done.
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Hemant January 03, 2012 @ 9:43pm
Thanks Rick, Got it working. Seems that the server I was connecting was having buggy HTTPS implementation. I have posted the solution here: http://hemant-vikram.blogspot.com/2012/01/https-spins-continuously-when-fiddler.html

Thanks Again,
Hemant.
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Sylvain Audet December 20, 2012 @ 6:06am
Merci Rick!
We needed to monitor web services calls between local IIS (.NET httpRequest) and our client's provider and your article was exactly what we needed to be able to monitor this traffic within fiddler.

Very helpful, keep up the good work! :)

Sylvain Audet
MyDevPartners.com
# re: Monitoring HTTP Output with Fiddler in .NET HTTP Clients and WCF Proxies
by Mahesh June 21, 2014 @ 2:20am
Hi all,
I have an application deployed on our app and web server which consumes different web services,wcf and MQ services from different down stream applications and I am accessing my application on my local machine,can someone help me how can I get what are all the web services or wcf Services and MQ services and request and response which are used in my application on my local machine?
 


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