views:

104

answers:

5

I know you are all going to answer "use a debugging proxy server like Fiddler" but it's not that simple.

Here's my situation: I have some code that runs on a server, in an ASP.NET page code-behind (aspx.cs), which (among other things) establishes a connection to another server, grabs some stuff, and then formats it and returns it to the browser.

The problem is that the other server is doing the wrong thing, and so I want to be able to pass a debugging flag into the page (via the query string, e.g. ?debug=true) so that it will print out the completely raw HTTP request that it is sending to the other server so I can see what the heck is wrong. This code is running in several places so I want to be able to just pass in this flag on dev, staging, or production and just see the request, without having to figure out whether the production servers can talk to some proxy server that exists somewhere, etc.

You would think that it would be easy to do this, right? So I feel like I'm crazy or something but I looked at the reference for HttpWebRequest and its parent class WebRequest and -- nothing. No can do. You would think Microsoft would have thought of this. The closest thing is that you can access the "Headers" collection but when I tried it, it omitted some really important headers like "content length" -- so it must be "lying" to me (I know it's lying, because I know for a fact that the remote server is returning a 200 status -- the request is successful, it's just returning bad/different/wrong data)

Here is the asked-for code example:

HttpWebRequest req = (HttpWebRequest)WebRequest.Create("http://www.whatever.com");
req.Method = ... whatever ...;
... other setup for the request ...
/* At this point we are about to send the request.
   What does the raw HTTP request look like? */
HttpWebResponse resp = (HttpWebResponse)req.GetResponse();
+1  A: 

You can use a network traffic sniffer like wireshark.

This is not a debugging proxy, but will sniff all traffic and let you see the raw requests/responses.

Oded
If that is like typical packet sniffers I have installed at home in the past, that would most likely require a level of admin access that I do not have here at work. I wouldn't be able to use it here in the office because, to put it simply, I'd be able to read my bosses' emails. Ironically it might be easier to get admin access if I could remote desktop into the production servers, but the problem with that is that I don't have any access to them at all, not even to push files (another company does that).
eeeeaaii
I would just use the technique I have outlined above - install a Tracelistener in your appdomain using a web.config file, and have the tracelistener write the debug spew to the local disk, or into the webpate that is then rendered to the client.
feroze
+1  A: 

Another suggestion. Implement your own web proxy, and set your request to use it with WebRequest.Proxy. Then you should be able to extract the traffic from the proxy instance.

Edit: update for links.

Mike Atlas
Yeah I thought about doing that, it seems like maybe the only way. But it introduces a lot of complexity. Let's say I implement a web proxy that sits on the same server as the site. What does it do with the output? Log it to a file? Is there a way to connect to the proxy and see the log, given that I do not have access to the server? I think it would be hard or impossible to set this up on the production server because it would require opening up a new port to direct proxy traffic to, and that would not be allowed by admins.
eeeeaaii
Well, the proxy could refuse all requests that don't originate from the local machine. You don't need to open the port up to the outside world. You could do all of this or only the requests through the proxy only in a #IF DEBUG section. Have it log to the event log or to a file, and then have production send you the logs. That's about the best you can do, outside of asking them to run Fiddler on the production machine for you. Personally, I would push for this (them running Fiddler), honestly, if it means saving time and money instead of rolling your own in-process proxy logger, seriously.
Mike Atlas
Also, can you just set up test server(s) that mimics your production environment using some VMs? Is the problem really only limited to this one machine?
Mike Atlas
You would not believe the amount of bureaucracy involved in maintaining these servers... I think system.net tracing might be the best way to go about this.
eeeeaaii
Yeah, I upvoted feroze's answer as well.
Mike Atlas
+2  A: 

You can use System.Net tracing mechanism to see the raw HTTP requests sent on the wire. See how to create a system.net trace logfile. You can also add your own tracelistener to the process.

feroze
I haven't tried that, this looks like a good option. Thanks!
eeeeaaii
didn't work for me for some reason, though this seems like the best answer anyway (I won't take away the checkmark). See my post here: http://stackoverflow.com/questions/3822941/net-tracing-not-working-with-diagnostics-tracesource-only-diagnostics-trace
eeeeaaii
Hmm.. This has always worked for me, of course - I always do console apps. DId you make sure that you gave the ASP.NET identity (account) write access to the file/directory where you want the trace output to be written?
feroze
A: 

You say that you think .NET is lying to you, and the specific example you give is that the header Content-Length is missing from the HTTP response.

But the header Content-Length is not required from an HTTP response. In fact, if the body of the response is in any dynamic, and if its length is not known in advance, then it is highly likely that the Content-Length header will be omitted!

Justice
I'm talking about requests, not responses. Here's the test I conducted: I ran the program, it made an http request and got a response. I then hand-crafted a request (in fiddler) based on the exact information that .NET told me it was sending (printing out HttpWebRequest.Headers, HttpWebRequest.Method, etc). Specifically, this request omitted Content-Length. But the server came back with an error stating that Content-Length was required (which makes sense, since it was a POST request). Therefore, I'm having trouble trusting what .NET reports.
eeeeaaii
p.s. also, the exact same .NET code reported a different set of headers when I ran it on two servers which had two different versions of .NET. Now maybe the two versions of .NET were actually producing different headers, IDK. But it makes me suspicious nonetheless and I'd like a raw dump.
eeeeaaii
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 - `Content-Length` must NOT be given in a number of circumstances, including when using chunked transfer encoding. Is the target server HTTP/1.1-aware?
Justice
Well the server was configured to return a 411 error when Content-Length was missing (tested this by hand-crafting a request in fiddler). So the point is, when I instantiate an HttpWebRequest and set it up, then print out the headers, it doesn't include Content-Length as a header. But if that were true, then it would be getting a 411 when I call GetResponse on httpWebRequest -- but that's not the error I'm getting. It's succeeding with a 200 and giving me bad data (a different problem). So therefore .NET is lying about the headers.
eeeeaaii
A: 

Hi -- answering my own question here, because I thought of another way to do it. Basically the idea is -- you re-point the HttpWebRequest to a page that logs the incoming raw HTTP Request. In other words set up a custom HTTP handler as per this forum post:

http://forums.asp.net/t/353955.aspx

And then change just the URL in the HttpWebRequest to point to this new endpoint, but keep all other elements of the request the same. Write the result to a file or something and you're golden.

eeeeaaii