IE10 User-Agent causes ASP.Net to not send back Set-Cookie (IE10 not setting cookies)

Question

Summary

ASP.Net does not send back a Set-Cookie header when using IE 10. Meaning that for example you cannot login to an ASP.Net site using IE10 when using Forms Authentication for example.

Detail

We're currently testing one of our legacy web apps against IE 10 [Preview 2].

When attempting to login using Forms Authentication, we don't get a Set-Cookie header in the response if the user-agent is that of IE 10. We've tried this with a blank .Net 2 and .Net 4 site.

Because we couldn't/wouldn't believe it, we even ran the follow HTTP request manually through telnet - after using all usual tools - and got the same response.

GET http://test.ourdomain.co.uk/ HTTP/1.1
Accept: */*
Host: test.ourdomain.co.uk
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0)
Content-Length: 0

The above HTTP request returns no Set-Cookie in the response. Yet if we simply change the User-Agent to Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/6.0) it works!

Can anyone else replicate this? I can't find any known issue with IE10 cookies other than an issue that effects non-standard URL patterns.

Hotfix

After devio posted the original answer, with a workaround, nullptr has confirm that there is now a hotfix for this.

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

I've promoted the hotfix to the main question as it's just handier for future reference, but please do up-vote the users mentioned.

Answer 1

The problem rests with some IIS instances thinking that IE10 is a cookieless browser (i.e. cant support cookies). In our problem case the server was setting the authentication cookie and sending it back to the browser, but was then ignoring the cookie on subsequent requests.

The solution is to either patch the browser capabilities so that it knows IE10 can do cookies (outlined in another answer on this page), or change the default behaviour to force it to use cookies even if it thinks the browser can’t do cookies.

We just added the following to our forms section in web.config:

cookieless="UseCookies"

<authentication mode="Forms">
  <forms name=".AUTH" cookieless="UseCookies" loginUrl="/" timeout="10000" path="/" />
</authentication>

Answer 2

Found this entry on MS Connect, the behavior is a recognized bug.

Suggested Workaround (from the entry):

== Workaround ==

In the meantime to make it work and to avoid similar issues in the future, I use a file ~\App_Browsers\BrowserFile.browser with the following:

<browsers>
<browser refID="Default">
<capabilities><!-- To avoid wrong detections of e.g. IE10 -->
<capability name="cookies" value="true" />
<capability name="ecmascriptversion" value="3.0" />
</capabilities>
</browser>
</browsers>

Answer 3

There is a hotfix available for this issue[1].

1) http://support.microsoft.com/kb/2600088
1) http://support.microsoft.com/kb/2600217 (replaces previous KB)

Also, [2] suggests that this will hit Windows Update in January of 2012.

2) http://www.hanselman.com/blog/BugAndFixASPNETFailsToDetectIE10CausingDoPostBackIsUndefinedJavaScriptErrorOrMaintainFF5ScrollbarPosition.aspx

Answer 4

Thanks You for the Help. It worked no.

1. I copied the file from the site to C:\WINDOWS\microsoft.net\Framework\v2.0.50727\CONFIG\Browsers

2. Run In Command Prompt C:\WINDOWS\microsoft.net\Framework\v2.0.50727>aspnet_regbrowsers.exe -i

3. Restart the IIS.

4. Tested the site and it works without any error.

Thanks Again for the Feed back

Answer 5

An update for nullptr answer.

I tried today to download the Microsoft KB2600088. After receiving the link by email, I clicked on it then it lead me the page that says it is no longer available.

Try this: http://support.microsoft.com/kb/2600217

That link is a replace ment for KB2600088 and KB2628838.

MIcrosoft .Net Framework 4.5 is also available now.