Code Sleuth’s Blog

A lesson learned the hard way: browsers do not post referring URL information to a HTTPS connection, and it looks like there may some more spanners in the works preventing Request.URL from providing the correct URL. This makes sense in the fact that the headers aren’t necessarily secure – Firefox for example had a long standing and globally aware problem (issue?) where extensions had access to decrypted headers, requiring people to perform minor hacks to achieve true anonymity.

In my scenario I’m presented with an SSL connection to an IIS 6.0 server running an ASP.NET website I designed and created entirely in my local ASP.NET Development server. Come to production use, the site had a major problem . The code, Response.Redirect(Request.Url.ToString()), which I use to prevent the somewhat stupid end users from pressing the browser’s refresh and forcing a post twice to the server, was telling the browser to go to “https:///“, which is clearly an invalid address. Even though a browser should know this address doesn’t exist, both Firefox and IE7 were ending up with a “Connection Time-out” message.

At first it isn’t clear that this is caused by hosting using a secure server, but after realising this was the only difference, I commenced banging my head upon the table.

The moral of this story I would say is to always test your code in a production environment. Pay particular attention to what your IT bod is up to with your server.