How can I trace the HttpClient request using fiddler or any other tool?

I am using HttpClient for sending out request to one of the web api service that I don't have access to and I need to trace the actual request stream getting to the server from my client. Is there a way I can hookup the Fiddler to listen to the requests?

I am using the System.Net.Http.HttpClient class for sending out request.

Update: trying to improve this question now as I could not get what I was looking for. I am using a .Net Client application to connect to a Web Service hosted on my own IIS over HTTP channel. I have done the fiddler debugging earlier with a Website hosted on my IIS and watching the traffic generated between my browser and the WebSite. But when it comes to watching the traffic generated by a .Net client program talking to the web service using HttpClient class, strangely the fiddler does not seem to be able to tap that traffic and does not show anything. Is .Net HttpClient bypassing the WinInet API to connect to the service which results in the fiddler not able to watch the traffic?

If you are connecting with a url like http://localhost:1234 change it to http://localhost.fiddler:1234/ and the requests from HttpClient should then become visible in Fiddler.

Generally speaking, simply starting Fiddler before your application is sufficient. You haven't explained what you've tried so far.

• If it doesn't just work, read: http://fiddlerbook.com/fiddler/help/hookup.asp#Q-DOTNET
• If your target URL is localhost or 127.0.0.1, read: http://fiddlerbook.com/fiddler/help/hookup.asp#Q-LocalTraffic
• If your code is running in IIS or ASP.NET, read: http://fiddlerbook.com/fiddler/help/hookup.asp#Q-IIS

IIS does not use the proxy setting in Internet Option because it runs under a different user identity (default is ApplicationPoolIdentity). @EricLaw has provided a good pointer regarding the problem of capturing traffic of IIS/ASP.NET.

Instead of configuring IIS to use my login account, I edit web.config to force HTTPClient to use proxy, like following.

<configuration>
  <system.net>
    <defaultProxy enabled="true" useDefaultCredentials="true">
      <proxy proxyaddress="http://127.0.0.1:8888"/>
    </defaultProxy>
  </system.net>
</configuration>

Here is the detail of usage from MSDN.

If the .NET application is running in your current user account, add the following content inside the configuration section:

<configuration>
 <system.net>
  <defaultProxy>
   <proxy bypassonlocal="false" usesystemdefault="true" />
  </defaultProxy>
 </system.net>
</configuration>

Note: Important: Regardless of other settings, .NET will always bypass the Fiddler proxy for URLs containing localhost. So, rather than using localhost, change your code to refer to the machine name. For instance:

This URL will not appear in Fiddler:

http://localhost/X509SignCodeService/X509SigningService.asmx

This URL will appear in Fiddler:

http://mymachine/X509SignCodeService/X509SigningService.asmx

For those who have the same problem with a .NET Core app and use Fiddler (should work for other tools too, but haven't checked this).

You need to know the port Fiddler listens to:

Then run (as Administrator on Windows):

netsh winhttp set proxy 127.0.0.1:<the port>

To remove the proxy, run:

netsh winhttp reset proxy

The source of wisdom you can find here. Works with localhost.

Use HttpTracer - a library built to capture Http requests/responses. You won't need to configure a proxy, it's as easy as passing an instance of the handler into HttpClient: new HttpClient(new HttpTracerHandler()). Try it out, it's been invaluable for us on the Xamarin side and for S2S purposes in ASP.NET.

all request to IIS are logged in logging directory (iis manager > iis server > logging) default is: %SystemDrive%\inetpub\logs\LogFiles

At the end of line there is status of the request.