We recently found ourselves debugging code that was making web requests to another server. If we hit the server manually in a web browser, it worked fine, but when we ran it through the code simulating the request using HttpWebRequest, we weren’t getting the responses we expected.
When you are working with a browser, you can just use a tool like HttpWatch or Fiddler to snoop on the requests the browser is making and what the server sends back. However, when you are trying to debug code, there is no magic button to press to snoop on the requests and responses being generated.
Fortunately, it turns out to have HttpWebRequest use Fiddler as a proxy. When set up properly, all of your outgoing requests from the server code will route through Fiddler (which can even be running on a separate box somewhere) before being sent up to the server. This allows you to inspect the requests and response and debug much more quickly.
The first step is to download and install Fiddler. Once you have it running, Then, go to Tools -> Fiddler Options, and choose the Connections tab. Check what is set for the “Fiddler listens on port” and change it if necessary.
Clik here to view.
If you are debugging an HttpWebRequest made on your local machine, you are all set from the Fiddler side. However, if you are running Fiddler on one machine and the code on another, you’ll need to make sure that whatever port Fiddler is set to use is open on your machine’s firewall.
The next step is to modify your code to use Fiddler as a proxy. HttpWebRequest supports an object called a web proxy. All you need to do is instantiate one that points to your Fiddler instance and attach it to the web request:
HttpWebRequest myRequest = new (HttpWebRequest) WebRequest.Create("http://someserver/somepage");
myRequest.Method = "POST";
…
WebProxy myProxy = new WebProxy("http://mymachinename:8888");
myRequest.Proxy = myProxy;
…
HttpWebResponse myResponse = (HttpWebResponse) myRequest.GetResponse();
Now, when you execute the the code above, instead of sending requests directly to the intended host (“someserver” in the example above), it will send them to the Fiddler proxy running elsewhere (on “mymachinename” in the example above). It will proxy them on to the intended host, but you can now inspect the requests and responses directly without having to step through a debugger or log data.
UPDATED:
As @duncansmart pointed out in the comments, that can be accomplished without a code change at all. Just modify the web.config to specify a proxy, and it will start working immediately. Very useful if you need to debug in another environment where you cannot push code modifications easily.
<system.net>
<defaultProxy>
<proxy
usesystemdefault="true"
proxyaddress="http://mymachinename:8888"
/>
</defaultProxy>
</system.net>
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
