View WebRequest XML

Question

Hello, I'm having a strange issue - I saw a similar post on this forum, but it didn't have an answer.

Long story short, I am sending an HttpWebRequest using C# to a web service (stubs were created by adding a web reference in Visual Studio 2008, .NET 2.0) which breaks with the following message: "Unable to parse the incoming request". This is a java based webservice running on weblogic.

Here is the strange part, if I have fiddler running to monitor my request - IT WORKS FINE!!??

My theory is that fiddler is reformatting the request in some manner which the server likes?

Does anyone know what .NET could be doing to the request which fiddler could be fixing? If not, is there a way I can view my XML programmatically without using fiddler?

Caveat - I do not have access to make changes to the server hosting the web service.

Thanks, Steve

UPDATE - When I remove the "Decrypt HTTPS traffic" option in fiddler it no longer works. So whatever fiddler is doing to decrypt the HTTPS traffic is what is making this work....

Answer 1

Use Wireshark to see what's going on at the network packet level - that's as definitive as it gets!

(One caveat, which I think is true for Steve but might not be for other readers: this assumes your web service is on a different machine, so that there is some physical network activity to monitor - Wireshark won't help if it's all running on your local machine.)

Answer 2

EricLaw - thanks for the response, I believe this is the issue. I have a different method which works, but it sends less across the wire. Do you happen to know how I could buffer the request bytes within my C# code in order to make this work?

Answer 3

Steve,

I had exactly the same symptoms when I was debugging web proxy I was developing. It turned out that Fiddler was correcting the CRLF (\r\n) chars that go after the last byte of last header and before first byte of request body. According to HTTP spec, there should be exactly two CRLFs and my proxy was adding three of them there (due to a bug) and Fiddler was silently correcting this.

Not sure if this is the same problem in your case, as you are using proxies, but maybe it will help you somehow.