所以，我遇到了一个奇怪的问题，我希望那里有一些 IE 专家可以对这种行为有所了解。我的公司运行实时 Lift 应用程序。我们使用 Comet 模型在浏览器和服务器之间进行实时通信，这是 Lift 的标准。另外值得注意的是：如果彗星与服务器不同步（由于连接问题或服务器重启，任何会终止服务器上会话的事情），服务器会响应彗星请求document.location.reload();以重新加载页面，启动一个新会话，等等。
现在，为了确保按应有的方式注销，我们有一个特殊的 url (/session/logout)，它会执行所有与会话相关的清理，然后将您踢回我们的主页。这可以通过单击该 URL 的锚点来触发，或者如果您尝试执行需要注销的操作，服务器可能会向您发出该 URL 的 302。很简单，对吧？在大多数浏览器中，这很有效，因为工作流程看起来像这样：
- 用户单击注销按钮或服务器向 /session/logout 发送 302
- 当前页面上的 Javascript 执行停止，因此所有彗星都关闭了。
- 浏览器加载 /session/logout
- 浏览器从服务器收到 302 消息（表示会话清理完成）将用户踢到主页。
- 浏览器加载主页。
但是，在 IE 中，我们看到以下行为：
- 用户单击注销按钮或服务器向 /session/logout 发送 302
- 浏览器开始加载 /session/logout
- 浏览器从服务器收到 302 消息（表示会话清理已完成）以将用户踢到主页。
- 浏览器开始加载主页。
- Comets 收到
document.location.reload();来自服务器的 a，因为它们从未被 IE 关闭，主页的加载被中止，并且当前页面在没有用户登录的情况下重新加载。
这是完全不可取的，因为我们需要加载 /session/logout 的正确结果——尤其是在用户试图做他们登录时无法做的事情的情况下（在这种情况下，302 从注销将指向他们最初试图去的地方）。
有没有人遇到过这种问题？关于如何处理这个问题的任何建议？