ie9 loses cookies after redirect

I have an iframe that:

1. does a post request to server
2. server returns 302 and sets cookie
3. browser 开发者_高级运维not saves cookies but does a post(don't know why not get but it doesn't matter)
4. cookie from #3 are lost

i've found a workaround:

Response.AddHeader("Pragma", "no-cache");
Response.AddHeader("Cache-Control", "no-cache");

but it didn't help. mb anybody knows what can fix this issue?

You may want to look into why your browser is doing a POST rather than a GET, since that implies that there's an important piece of information that you left out. No browser will follow a HTTP/302 redirect with a POST.

In IE9, redirection responses are cached if headers allow (IE8 and below would not cache redirects).

You can absolutely set a cookie on a 302 redirect. There are two possibilities here:

1. Your cookie is getting dropped because you failed to supply a P3P Header on the response indicating that your privacy practices are compatible with the user's desires.
2. Your redirection response is getting pulled from the user's cache, not the server, and the cached response didn't set a cookie.

Given that you're having this problem in an IFRAME, #1 seems more likely. (See Quick Look at P3P)

This post may be a little late, but I have recently handled this particular issue for a Grails application. Many years ago, the same issue occurred in a Java web application that I created where Internet Explorer was blocking cookies (privacy settings). In order to allow the Java web app and JavaScript to write cookies in a primary page or an IFRAME in Internet Explorer, a privacy policy was sent from the web application. Microsoft still supports a privacy policy format called Platform for Privacy Preferences (P3P). This format does not appear to be supported in other modern browsers, but it does help overcome IE cookie issues. Despite concerns with IE 10 support of P3P, I have successfully tested the following P3P settings with strict validation.

1) Identify required categories for your application. For my application, the interactive, navigation, and uniqueid categories were required for proper operation. The Compact Policy codes are listed on the P3P specification site

Category       Compact
--------       -------
interactive => INT
navigation  => NAV
uniqueid    => UNI

2) Determine if compact policy alone will work. For my application, the compact policy header was sufficient. If you require a policy file, then please review some example files here: http://p3pbook.com/examples.html.

3) The code below is a very simplified example, but should still illustrate the steps to perform.

HttpServletResponse response = (HttpServletResponse) res;

String policySettings = policyFileExists ? "policyref='" + policyFilePath + "', " : "";

policySettings += "CP='INT NAV UNI'";

response.setHeader("P3P", policySettings);

You can certainly perform similar steps in other technologies, such as PHP and ASP.NET. I hope this at least helps point people in the right direction for solving the IE cookie issue.

To expand on EricLaw's answer about IE 9 caching redirection responses, check out this page:

http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx

Also, one thing to note about the cached redirect responses is there really is no easy way to clear them out. Clearing cache and cookies leaves them in place. There are 2 options:

• Go into IE 9 Private Mode
• Use Fiddler to clear the Wininet cache (under Tools)

I dunno if you ever figured this out, but make sure you're instructing your application to not set client cookies. In CF, there's an application parameter 'setClientCookies', when setting it to false makes sure what you're describing doesn't happen. (Coincidentally, setting it to 'false' or 'no' does not work where as CF normally recognizes this as false as well.)

You may want to check the Expire vs. Max-Age setting on your cookie. IEs will not consider the Max-Age (maybe newer ones do, if no Expire is given?), but they will look at the local time and compare it with the Expire date. If local time is in the future, or server has the date in the past, the cookie will be considered as expired and will not be sent on the next request.

I've also noticed that even if IE9 will tell you in the developer interface that it does a POSt, it really does a GET after a 302 redirect. As a note, the whole 302 thing is a bit messed up and sites should you 303 and 307, but anyway.