Troubleshooting and Fixing Session Cookie Problems in IE11

This post has been republished via RSS; it originally appeared at: Windows Blog Archive articles.

First posted to MSDN on Jul, 02 2013

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:

2836940

NDP 3.5 SP1 - Win2K3SP2/Win2K8SP2/VistaSP2/WinXPSP3

2836941

NDP 2.0 SP2 - Win2K3SP2/WinXPSP3

2836942

NDP 3.5 SP1 - Win7SP1/Win2K8R2SP1

2836943

NDP 2.0 SP2 - Win7SP1/Win2K8R2SP1

2836945

NDP 2.0 SP2 - Win2K8SP2/VistaSP2

2836946

NDP 2.0 SP2 - Win8RTM/WinRTRTM/Win2K12RTM

2836947

NDP 3.5 SP1 - Win8RTM/WinRTRTM/Win2K12RTM

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!

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.