Troubleshooting and Fixing Session Cookie Problems in IE11

Another browser, another version check crisis…

So, like many of my esteemed nerdly readers, I pushed “go” on upgrading to the Windows 8.1 preview the first opportunity that I had. And, naturally, the first thing I started doing was finding the broken stuff. Unfortunately, it didn’t take me long.

We have an internal conference twice a year called TechReady, and nobody was able to get to that site using the ADFS logon. Curious. So, I had to go and take a look. The first thing I tried was a User Agent String (UAS) lie, because that’s mostly what I have to do these days. But, the site developers were still confused what was broken, so I went ahead and debugged it further. Here’s what I found:

In the failure case (no UAS lie), I had the following conversation:

Request:

GET (busted web site)/ HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-US,en;q=0.7,ja;q=0.3
Accept-Encoding: gzip, deflate, peerdist
Host: www.bustedwebsite.com
DNT: 1
Connection: Keep-Alive
X-P2P-PeerDist: Version=1.1
X-P2P-PeerDistEx: MinContentInformation=1.0, MaxContentInformation=2.0
User-Agent: Mozilla/5.0 (
>>        Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko

Response (headers only):

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Expires: -1
Server: Microsoft-IIS/7.0
X-AspNetMvc-Version: 4.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
X-UA-Compatible: IE=IE10
Content-Length: 9586
Date: Tue, 02 Jul 2013 02:1
>>        4:49 GMT

In the success case (IE10 UAS lie), I had the following conversation:

Request:

GET (busted web site)/ HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-US,en;q=0.7,ja;q=0.3
Accept-Encoding: gzip, deflate, peerdist
Host: www.bustedwebsite.com
DNT: 1
Connection: Keep-Alive
X-P2P-PeerDist: Version=1.1
X-P2P-PeerDistEx: MinContentInformation=1.0, MaxContentInformation=2.0
User-Agent: Mozilla/5.0 (
>>        compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)

Response (headers only):

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Expires: -1
Server: Microsoft-IIS/7.0
X-AspNetMvc-Version: 4.
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
X-UA-Compatible: IE=IE10
Content-Length: 9586
Date: Tue, 02 Jul 2013 02:1
>>        5:33 GMT
Set-Cookie: .session_state=e3arirjbcwtm10nphugo15sp; path=/; HttpOnly

What’s the difference? I get a Set-Cookie header when I say I’m IE10, but not when I use the default UAS string. Just to make sure it’s not specific to IE10, I actually crafted my own user agent string and sent it along:

User-Agent: Mozilla/5.0 (Windows NT 6.3; MSIE 11.0; WOW64; Trident/7.0; rv:11.0) like Gecko

I added MSIE, and – like magic – it lit up the Set-Cookie header. UAS sniffing. I’d really like to understand the scenarios where it has caused delight, because the scenarios where it has caused pain and suffering are plentiful and I’m not sure there is enough delight to outweigh that.

The poor site developer wasn’t at fault, though. They’re victimized by ASP.NET’s browser definition file. <sigh>

The workaround they used was to change the cookieless value from UseDeviceProfile to UseCookies, and we no longer consult the browser definition file.

It’s also now possible to patch ASP.NET to have an updated device profile. Here’s the one for the 4.0 framework:

http://support.microsoft.com/kb/2836939

There are also patches for other frameworks:

So, there you have it. Version checking wreaks havoc again.

You may be asking yourself – why did we remove the MSIE in the first place? Well, because tons and tons of sites check for IE by looking for MSIE, and if they find it, they either give us really junky old HTML designed for ancient versions of IE (which don’t work well in IE, but also don’t work well in any other browser), or they just refuse to do anything and instead post an advertisement for other browsers. You would honestly be surprised at how many sites light up and work terrifically on IE11 because of this change, despite the “clever” coding designed to keep IE from being useful. Just another step in the discrimination arms race.

So, with that – happy browsing, and happy debugging!