Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
Markdown Monster - The Markdown Editor for Windows

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


:P
On this page:

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:

 

and follow the instructions in the Learn more… options.

You essentially have to export the Fiddler root and install it into the Root Certificate store. When you click the Decrypt Https checkbox a dialog will pop up asking whether you want to trust the Fiddler Root. If you do Fiddler will install the certificate into your root store for you and you’ll be able to decrypt HTTPS content that way.

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.

Posted in WCF  .NET  Web Services  

The Voices of Reason


 

Michel Schep
January 14, 2009

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

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

The Luddite Developer
January 14, 2009

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

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

ParanoidPenguin
January 14, 2009

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

"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?

Denis
January 14, 2009

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

Using ipv4.fiddler as the host name is sometimes useful as well.

Jeff
January 14, 2009

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


Marc Brooks
January 14, 2009

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

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

Rick Strahl
January 14, 2009

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

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

Harry M
January 14, 2009

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

HTTPAnalyzer is great for this, but unfortunately its not free :(

Nick Berardi
January 14, 2009

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

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.

DotNetShoutout
January 14, 2009

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

Thank you for submitting this cool story - Trackback from DotNetShoutout

Kevin Read
January 14, 2009

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

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.

redsquare
January 15, 2009

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


Yaron Naveh
January 15, 2009

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

In case when all proxy utilities fail one can also use tcpmon (or equivalent) to follow the sent/received messages.

Rick Strahl
January 15, 2009

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

@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

Burned by DotNetBurner.com - hot .net content! DotNetBurner

#.think.in
January 18, 2009

# #.think.in infoDose #16 (12th Jan - 16th Jan)

#.think.in infoDose #16 (12th Jan - 16th Jan)

Guy kolbis
January 20, 2009

# What Gives? Fiddler Not Capturing Local Address

I have grown to love working with fiddler. Fiddler is a debugging proxy that allows you to monitor HTTP

its coding time
January 24, 2009

# My Developer's Toolbox

My Developer's Toolbox

Kerem Kusmezer
January 26, 2009

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

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>

Rick Strahl
January 26, 2009

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

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

Rich Larson
February 03, 2009

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

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

Scott Mitchell
February 12, 2009

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

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.

Raj
February 21, 2009

# About REST web service in C#

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

Tom Leonard
February 26, 2009

# Wanted to pass on a 'dooooh' that prevented me from using for Web Service traffic

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

Rama
May 25, 2009

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

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

Rick Strahl
May 25, 2009

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

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

Chris Wigley
June 09, 2009

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

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.

Rick Strahl
June 09, 2009

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

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

Eric Lawrence
September 29, 2009

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

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.

Rick Strahl
September 30, 2009

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

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

JK
February 13, 2010

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

Does fiddler work with .net console applications? Added the proxy 127.0.0.1:8888 etc etc and still nothing from Fiddler?

JK
February 15, 2010

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

oops, had an extra request.Proxy = null; in there.

Adam Coyne
March 18, 2010

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

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.

Nick W
May 19, 2010

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

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.

Tom
June 21, 2010

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

You can also use http://ipv4.fiddler/my/path instead of 127.0.0.1. For ipv6, use ipv6.. ;-)

Jim Gorman
July 13, 2010

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

Thanks a lot, Rick.

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

Much appreciated.

Karthikeyankomar
September 21, 2010

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

Dude..thanks for the proxy info that you had mentioned.It helped me.

Mike
November 01, 2010

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

Have you use Fiddler to test http traffic out of any browser?

Michael
April 05, 2011

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

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?

dave
September 27, 2011

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

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.

Monish Nagisetty
October 18, 2011

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

Dave,

Did you try setting bypasslocal to false?

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

Thanks
Monish

da
November 11, 2011

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

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?

Hemant
December 25, 2011

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

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.

Rick Strahl
December 26, 2011

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

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

Mahesh
June 21, 2014

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

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?

Ravikanth
October 20, 2015

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

how can i create a proxy for specific application instead of creating a system level proxy,because when i use this i am not able to access HTTPS sites.is there any other way to do.

Rick Strahl
October 23, 2015

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

Fiddler installs as a system level proxy, but you have to configure Fiddler to capture https connections by installing a certificate. Go to Tools | Options and follow the SSL configuration prompts to create and install the intermediary certificate. After you do that Fiddler will work with most SSL connections.

Daniel
November 09, 2017

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

@Michael I am most certainly seeing this "run as different user" behavior and am still struggling with it actually. In a system that I do not control, I have to logon as one DOMAIN1\user1 but run an application as a different DOMAIN2\user2. The result is that Fiddler is not seeing that application's traffic!

I tried "run as different user" on Fiddler, too, but this doesn't change Fiddler's behavior to ignore traffic from that application.

Is there a way to workaround this?


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