Hehe, let's start with a quick word about proxies Basically a proxy is a rerouter of sorts. You need to send a request to HostA, but your network security or the layout of the network will not let you reach HostA directly, so, you have to route your web request through a computer that can reach HostA. So, you have HostB which is a server that can reach HostA and you configure a proxy server on it. The proxy server is a separate piece of software, like Microsoft ISA or something and allows hosts to reroute their requests through it. On your computer, since you know you cannot reach HostA, you create a web request with HostA as your target address and configure that request to use a proxy server of HostB. So, when you think you're sending your request to HostA, your computer actually forwards it to HostB with a message asking HostB to forward it on to HostA. HostA receives the request from HostB (and doesnt' know it was sent from your computer) and responds to HostB. HostB receives the response and sends it back to your computer. So, while your web request thinks it was talking to HostA, it was actually talking to HostB the whole time because your request was proxied.

OK, so, there are a couple of places where this could go wrong. First, when you send a request, it might be improperly formatted when you send it from your computer (when it's sent to HostB). Now, .NET doesn't have a way for you to see the raw bytes that are hitting the network stream because, quite frankly, they've unit tested the heck out of it and they know it's going to format the request properly, so why allow you to see it?

So, if the request is leaving your computer properly, then it could be that the proxy server (HostB) is receiving your request and when it wraps the request it's corrupting it before it sends it to HostA. This option is highly unlikely if you're using a viable commercial proxy solution like some Linux distro with a good proxy server or Microsoft ISA or something. Once again, they've probably unit tested the heck out of it.

The other option is that the HostA is just not processing the request properly. It might be reaching it fine, but throwing up when it tries to process it.

Now, debugging this is quite a chore, because as a developer, you probably don't have access to HostA or HostB, you just have access to your computer. If you're wondering whether the request is leaving your computer properly, then you can configure your sniffer to capture all traffic on your network card and when you've sent the request, stop the capture and examine the packets. You'll be able to get the raw data that was sent from your computer to HostB (most sniffers have a filter that allows you to filter the traffic by destination address... in thic case HostB).

Once you've determined that you're sending the correct request, you'll want to test whether the proxy is sending the request properly. Now this one will cause some heartache. Mainly because you want to see the proxied request, meaning you have to set up your computer as the final destination of the request... through the proxy. Since you're not in control of the proxy and you can't just put the packet sniffer on it, you'll have to have 2 computers at your location. One to send the request, and one to receive the request (I don't think you can use the same computer for both because the OS will realize that the source and destination are the same and will send the traffic across the network stack before ever reaching the actual ethernet... but with a proxy this might not be the case... not sure). So, you'll want to change your HostA target for the request to the other computer and send the request and when the request is received by your second computer, sniff the packets.

Now, when I say sniff the packets, you're going to get the raw bytes of the request. Including the HTTP/1.1 GET - Content-Length: mime-type: headers and everything. So, I'm not sure what's garbling the request, but maybe that gives you a little more insight into figuring it out