I recently had the pleasure of troubleshooting an ASP.NET application for a particular client. The issue was that clicking a particular link had the desired effect immediately, but upon any second link/postback the system would revert back to its original state. The purpose of that particular link was to set a session variable a certain way. It did not take long to determine some of the broader qualities of this issue:
- It only happens in the server environment, never in a local debug session
- It appears limited to Internet Explorer
- It affects all versions of Internet Explorer, including 11
This clearly had all the earmarks of “one of those bugs” that was going to take a long time to isolate and fix. Knowing that there was a time crunch (isn’t there always?) I set right about observing the situation, collecting whatever information I could, and researching accordingly. Observing the server interactions with Fiddler, it did not take long to realize that every single post back that IE made resulted in receiving a new session ID from the server. No matter what was link was clicked on or control changed, anything that triggered communication back to the server did not include the ASP session cookie given in the original request.
This key fact that IE was ignoring the session cookie 100% of the time led me to the solution. Some Google Fu occurred, and my eyes lit upon this Microsoft Security bulletin dated 2001. That isn’t a typo folks. MS01-055 was a security update for Internet Explorer versions 5.5 and 6. The security issue was that certain internet sites, through a properly crafted name, would be treated by Internet Explorer as a local site resulting in the wrong security zone settings applying. This made Internet Explorer less secure, so MS made a patch to fix it.
Here’s the catch: as a part of the fix, Microsoft made it that any server name utilizing an underscore was to be considered an unsecure source and treated accordingly. This treatment, apparently, meant ignoring any cookies handed out by the server. Lo and behold, the DNS entry for the server running the application I was diagnosing contained not one but TWO underscores. The good news? There’s a Microsoft security bulletin that addresses it. The bad news? Their fix is to rename the server.
After setting up a new IIS binding and editing my hostfile accordingly, I demonstrated this to be an accurate fix- accessing the same site on the same server sans underscores gave me no trouble. Passed word back to the client, made an official name change, problem resolved.
“All this has happened before, and all of it will happen again.” – Several Characters, Battlestar Galactica
I’m sure I am not the first one to trip over this, and I’m also sure I won’t be the last. From the perspective of most developers and users, this is a bug in the browser and nothing more. Chrome had zero issues and Firefox didn’t care, which makes it hard to blame anything other than Internet Explorer. Yet for 15 years the solution has been “rename the server”. Here’s to hoping this gets taken care of eventually.
Author’s note: after the fact it was discovered that Microsoft Edge exhibits this behavior as well. It would truly be sad if Edge doesn’t improve in this regard, for that would mean a 15 year old bug would have survived transplantation into an entirely new application.