Andy @ Work

Tuesday, January 24, 2006

Thank God for Reflector

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 System.Net.WebClient. Imagine my surprise when UploadValues 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 UploadValues() 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 UploadValues 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). System.Net.WebHeaderCollection 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 System.Net.Connection.ParseResponseData() method. ParseResponseData makes a decision to call either ParseHeaders or ParseHeadersStrict based on the value of SettingsSectionInternal.Settings.UseUnsafeHeaderParsing (found in System.Net.Configuration).

By this point I can smell victory. Using VS.Net 2005's excellent intellisense for configuration files, I added the following:

<httpWebRequest useUnsafeHeaderParsing="true"/>

Without Reflector I don't know if I would have ever found the solution so quickly.

Thursday, January 05, 2006

Aaaaaaah....thats why my FormsAuthentication didn't work

One of the projects that I'm currently working on involves an ASP.Net 2.0 site which needs to open an IFrame onto a different ASP.Net 2.0 site. Yesterday I noticed that after logging into my wrapping site, any attempt to navigate to another section of my site that required authenticated users would result in me having to authenticate again.

To cut a long story short, the problem I was having only presented itself when I tested the website while being hosted by the ASP.Net Development Server (hosting in IIS was fine). Well the problem came down to the <iframe>. Because I was authenticating with two sites (one wrapping the other) and they both were setting the value of the .ASPAUTHX cookie AND they were both hosted within the ASP.Net Development Server, the wrapped website was destroying my wrapping websites authentication ticket.

Changing the forms configuration element in web.config to use a different name for this cookie solved the problem.

The reason the problem only presented in the ASP.Net Development Server was due to my IIS server being referenced by a FQDN as opposed to localhost. Hence my wrapping .ASPAUTHX cookie had a different host value to my wrapped websites authentication ticket, and so was being overwritten.

You live you learn.