I arrived on the client's floor and didn't even have a chance to walk into the office.
"Stop everything - we need to solve this problem"
Sounds serious.
After deploying an existing ASP.Net application to a new server, a basic run-through test is typically done, making sure that everything is working. This time, however, nothing would work. The site would load, but as soon as the user did anything, it would return them to the launch page. We tried a different site and it worked fine. So it must be the configuration of IIS --- that was the general consensus.
What was happening was that the session variables used in the application were simply not being registered. So if you issued a Session("Variable") = "Andrew", it didn't error out but it also didn't set the variable.
But it wasn't. The kicker came when we installed Chrome and tried the site - it worked fine!
Now, I'm a big fan of browsers but I don't think the solution to a problem is always "switch to ...." (unless it's IE 6).
StackOverflow to the rescue - I found this link - which seemed to describe the problem - "ie8-does-not-keep-session-variables".
Then in the comments was this innocent little note:
Blocking cookies when the host contains underscores is a known issue in IE. support.microsoft.com/kb/316112– EricLaw -MSFT- May 27 '11 at 20:03
As it turns out, it's not just a "known issue", according to the KB article:
"A potential security vulnerability exists in Internet Explorer versions 5.5 and 6.0 in which a malicious user could create a URL that allows a Web site to gain unauthorized access to cookies that are stored on a client computer and then (potentially) modify the values that are contained in these cookies."
IE 5.5 and 6 --- the actual KB article is from 2005. So it must have been fixed, right? It seems kind of strange that every other browser doesn't have this issue, except ----
The problem? The testing server was named with an underscore in it.
The workaround:
To work around this problem, use one of the following methods:
Renaming the server name is something that every sys admin loves to do.
Thankfully, the testing could proceed with the IP address.
This is the first time I've ever come across this problem - but then again, I don't typically name servers with an underscore in it. But having been bit once, you can bet I'll be on the lookout.
What old bugs have you been bitten by?
"Stop everything - we need to solve this problem"
Sounds serious.
After deploying an existing ASP.Net application to a new server, a basic run-through test is typically done, making sure that everything is working. This time, however, nothing would work. The site would load, but as soon as the user did anything, it would return them to the launch page. We tried a different site and it worked fine. So it must be the configuration of IIS --- that was the general consensus.
What was happening was that the session variables used in the application were simply not being registered. So if you issued a Session("Variable") = "Andrew", it didn't error out but it also didn't set the variable.
But it wasn't. The kicker came when we installed Chrome and tried the site - it worked fine!
Now, I'm a big fan of browsers but I don't think the solution to a problem is always "switch to ...." (unless it's IE 6).
StackOverflow to the rescue - I found this link - which seemed to describe the problem - "ie8-does-not-keep-session-variables".
Then in the comments was this innocent little note:
Blocking cookies when the host contains underscores is a known issue in IE. support.microsoft.com/kb/316112– EricLaw -MSFT- May 27 '11 at 20:03
"A potential security vulnerability exists in Internet Explorer versions 5.5 and 6.0 in which a malicious user could create a URL that allows a Web site to gain unauthorized access to cookies that are stored on a client computer and then (potentially) modify the values that are contained in these cookies."
IE 5.5 and 6 --- the actual KB article is from 2005. So it must have been fixed, right? It seems kind of strange that every other browser doesn't have this issue, except ----
STATUS
This behavior is by design.
The problem? The testing server was named with an underscore in it.
The workaround:
To work around this problem, use one of the following methods:
- Rename the domain name and the server name, and use only alphanumeric characters.
- Browse to the server by using the Internet Protocol (IP) address rather than the domain/server name.
Renaming the server name is something that every sys admin loves to do.
Thankfully, the testing could proceed with the IP address.
This is the first time I've ever come across this problem - but then again, I don't typically name servers with an underscore in it. But having been bit once, you can bet I'll be on the lookout.
What old bugs have you been bitten by?
Comments