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.
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.
Installed the various patches that everyone's mentioning and for whatever reason the problem was not resolved.
Installed .NET Framework 4.5 Full and the problem went away.
You don't have to update any projects to target 4.5. Just install it on the server.
Found this entry on MS Connect, the behavior is a recognized bug.
Suggested Workaround (from the entry):
Thanks You for the Help. It worked no.
I copied the file from the site to
C:\WINDOWS\microsoft.net\Framework\v2.0.50727\CONFIG\Browsers
Run In Command Prompt
C:\WINDOWS\microsoft.net\Framework\v2.0.50727>aspnet_regbrowsers.exe -i
Restart the IIS.
Tested the site and it works without any error.
Thanks Again for the Feed back
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"
There is a hotfix available for this issue[1].
1) http://support.microsoft.com/kb/26000881) 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