ie9 重定向后丢失 cookie

Question

我有一个 iframe：

1. 向服务器发送请求
2. 服务器会返回 302 并设置 cookie
3. 浏览器不保存 cookie，但会发帖（不知道为什么不获取，但这并不重要）
4. #3 中的 cookie 丢失

了找到了解决方法：

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

但没有帮助。 mb 有人知道什么可以解决这个问题吗？

Answer 1

您可能想了解为什么浏览器执行 POST 而不是 GET，因为这意味着您遗漏了一条重要信息。没有浏览器会使用 POST 遵循 HTTP/302 重定向。

在 IE9 中，如果标头允许，重定向响应将被缓存（IE8 及以下版本不会缓存重定向）。

您绝对可以在 302 重定向上设置 cookie。这里有两种可能性：

1. 您的 cookie 被删除，因为您未能在响应中提供 P3P 标头，表明您的隐私实践与用户的愿望兼容。
2. 您的重定向响应是从用户的缓存而不是服务器中提取的，并且缓存的响应未设置 cookie。

鉴于您在 IFRAME 中遇到此问题，#1 似乎更有可能。 （请参阅快速了解 P3P）

Answer 2

这篇文章可能有点晚了，但我最近已经处理了 Grails 应用程序的这个特定问题。许多年前，我创建的 Java Web 应用程序中也出现了同样的问题，其中 Internet Explorer 阻止了 cookie（隐私设置）。为了允许 Java Web 应用程序和 JavaScript 在 Internet Explorer 的主页面或 IFRAME 中写入 Cookie，从 Web 应用程序发送了隐私策略。 Microsoft 仍然支持名为隐私首选项平台 (P3P) 的隐私策略格式。其他现代浏览器似乎不支持此格式，但它确实有助于克服 IE cookie 问题。尽管担心 IE 10 对 P3P 的支持，我还是通过严格的验证成功测试了以下 P3P 设置。

1) 确定您的应用程序所需的类别。对于我的应用程序，交互式、导航和uniqueid< /strong> 正确操作需要类别。 P3P 规范站点上列出了紧凑策略代码

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

2) 确定紧凑策略是否单独有效。对于我的应用程序来说，紧凑的策略标头就足够了。如果您需要策略文件，请在此处查看一些示例文件：http://p3pbook.com/examples.html< /a>.

3）下面的代码是一个非常简化的示例，但仍然应该说明要执行的步骤。

HttpServletResponse response = (HttpServletResponse) res;

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

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

response.setHeader("P3P", policySettings);

您当然可以在其他技术中执行类似的步骤，例如 PHP 和 ASP.NET。我希望这至少可以帮助人们找到解决 IE cookie 问题的正确方向。

Answer 3

要扩展 EricLaw 关于 IE 9 缓存重定向响应的答案，请查看此页面：

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

另外，有一件事关于缓存的重定向响应，请注意，确实没有简单的方法可以清除它们。清除缓存和 cookie 会将它们保留在原处。有 2 个选项：

• 进入 IE 9 私有模式
• 使用 Fiddler 清除 Wininet 缓存（在“工具”下）

Answer 4

我不知道您是否明白这一点，但请确保您指示您的应用程序不要设置客户端 cookie。在 CF 中，有一个应用程序参数“setClientCookies”，将其设置为 false 时可确保您所描述的情况不会发生。 （巧合的是，将其设置为“假”或“否”不起作用，因为 CF 通常也会将其识别为假。）

Answer 5

您可能需要检查 Cookie 上的“过期”与“最长期限”设置。 IE 不会考虑 Max-Age（如果没有给出 Expire，也许较新的 IE 会考虑？），但他们会查看当地时间并将其与 Expire 日期进行比较。如果本地时间是将来的时间，或者服务器的日期是过去的，则 cookie 将被视为过期，并且不会在下一次请求时发送。

我还注意到，即使 IE9 会在开发人员界面中告诉您它执行了 POSt，但它实际上在 302 重定向后执行了 GET。需要注意的是，整个 302 事情有点混乱，网站应该使用 303 和 307，但无论如何。