One of the projects I'm working on requires integration with an online credit card gateway. The interface is very simple, of the single page to post parameters at variety.
So I implemented by solution using good old faithful
. Imagine my surprise when
was raising the following exception:
The server committed a protocol violation.
Section=ResponseHeader Detail=CR must be followed by LF
I had a quick look at the raw response, and sure enough the response header and body were only separated by a single CR instead of CRLF (why an IIS 6 server is responding in this fashion I have no idea).
Since I have no control over the external gateway (even though technically they are sending malformed responses) I thought that I could implement my simple
method using the Socket class.
That I idea seemed good for about 5 seconds when I recalled that I'm calling a web page over SSL, making the work of implementing
a lot more difficult.
As the title of this post suggests, I fired up Reflector
to see the code that was raising this exception to determine if there was a work around. 30 minutes later I found one (after I disassembled the entire System.dll to a temporary folder).
has two methods for parsing response headers:
ParseHeadersStrict was raising the exception. But plain old ParseHeaders looked to be a little more forgiving.
So I used Reflectors
analyzer to determine who was calling ParseHeadersStrict and discovered the
method. ParseResponseData makes a decision to call either ParseHeaders or ParseHeadersStrict based on the value of
By this point I can smell victory. Using VS.Net 2005's excellent intellisense for configuration files, I added the following:
I don't know if I would have ever found the solution so quickly.