Geek Answers Handbook

Ie9 loses cookies after redirecting

I have an iframe that:

  • sends a request to the server
  • the server returns 302 and sets a cookie
  • the browser does not save cookies, but makes a message (I don’t know why it doesn’t work, but it doesn’t matter).
  • cookie of # 3 lost

I found a workaround:

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

but it did not help. Does anyone know what can solve this problem?

+7
source share
5 answers

You can see why your browser does POST and not GET, as this means there is important information that you left. Without a browser , an HTTP / 302 redirect with POST follows .

In IE9, redirect responses are cached if headers are enabled (IE8 and below will not cache redirects).

You can absolutely set your cookie to redirect 302. There are two possibilities:

  • Your cookie will be deleted because you were unable to provide a P3P header in response indicating that your privacy practices are compatible with the user's wishes.
  • Your redirect response is pulled from the user's cache, not the server, and the cached response does not set a cookie.

Given that you have this problem in an iframe, # 1 seems more likely. (See Quick View P3P )

+11
source

This post may be a bit late, but I recently addressed this issue for a Grails application. Many years ago, the same problem arose in the Java web application that I created when Internet Explorer blocked cookies (privacy settings). In order for the Java and JavaScript web applications to record cookies on the main page or in IFRAME in Internet Explorer, a privacy policy has been sent from the web application. Microsoft still maintains a privacy policy format called the Privacy Platform (P3P) . This format does not appear to be supported in other modern browsers, but it helps to cope with IE cookie problems. Despite the problems with IE 10 P3P support, I successfully tested the following P3P settings with rigorous validation.

1) Define the required categories for your application. For my application to work correctly, the categories needed were interactive , navigation, and unique . Compact Policy codes are listed on the P3P specification site.

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

2) Determine if only compact policy will work. A compact policy header was enough for my application. If you need a policy file, check out some examples here: http://p3pbook.com/examples.html .

3) The code below is a very simplified example, but should still illustrate the steps that are taken.

 HttpServletResponse response = (HttpServletResponse) res; String policySettings = policyFileExists ? "policyref='" + policyFilePath + "', " : ""; policySettings += "CP='INT NAV UNI'"; response.setHeader("P3P", policySettings);

You can follow similar steps in other technologies such as PHP and ASP.NET. Hopefully this will at least help point people in the right direction to solve the IE cookie problem.

+2
source

To deploy EricLaw's answer about IE 9 caching redirect 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 cached redirection responses, there really is no easy way to resolve them. Clearing the cache and cookies leaves them in place. There are 2 options:

  • Go into IE 9 private mode
  • Use Fiddler to clear the Wininet cache (in the "Tools" section)
+1
source

I don’t know if you ever understood this, but make sure that you instruct your application not to set client cookies. There is a setClientCookies application parameter in CF when setting it to false to make sure that what you are describing is not happening. (Coincidentally, setting “false” or “no” does not work where CF usually recognizes this as false.)

0
source

You might want to check the Expire vs Max-Age settings in your cookie. IEs do not take into account Max-Age (perhaps newer if there is no Expire?), But they will look at local time and compare it with the expiration date. If the local time in the future or the server has a date in the past, the cookie will be considered expired and will not be sent to the next request.

I also noticed that even if IE9 tells you in the developer's interface that it runs POSt, it really does GET after 302 redirection. As a note, all 302 things are a bit messy and you should have 303 and 307 sites, but anyway.

0
source

More articles:


All Articles