それで、私は少し奇妙な問題に遭遇しました。この動作に光を当てることができるかもしれないIEの専門家がそこにいることを願っています. 私の会社は、リアルタイムの Lift アプリケーションを実行しています。Lift の標準と同様に、ブラウザとサーバー間のリアルタイム通信にはコメット モデルを使用します。また、注目に値する: コメットがサーバーと同期しなくなった場合 (接続の問題またはサーバーの再起動など、サーバー上のセッションを強制終了する原因のいずれかが原因で)、サーバーはそのコメット要求に応答してdocument.location.reload();、ページをリロードします。 、新しいセッションの開始など。
現在、ログアウトが正常に行われるようにするために、セッション関連のすべてのクリーンアップを実行してからホームページに戻る特別な URL (/session/logout) があります。これは、その URL へのアンカーをクリックすることによってトリガーされるか、ログアウトする必要があることをしようとすると、サーバーがその URL に 302 を発行する可能性があります。簡単ですよね？ほとんどのブラウザーでは、ワークフローが次のようになるため、これはうまく機能します。
- ユーザーがログアウト ボタンをクリックするか、サーバーが 302 を /session/logout に送信します。
- 現在のページでの Javascript の実行が停止するため、すべてのコメットがシャットダウンします。
- ブラウザは /session/logout を読み込みます
- ブラウザーがサーバーから 302 メッセージ (セッションのクリーンアップが完了したことを示す) を受信し、ユーザーをホームページに移動させました。
- ブラウザがホームページを読み込みます。
ただし、IE では次の動作が見られます。
- ユーザーがログアウト ボタンをクリックするか、サーバーが 302 を /session/logout に送信します。
- ブラウザが /session/logout のロードを開始します
- ブラウザーがサーバーから 302 メッセージ (セッションのクリーンアップが完了したことを示す) を受信し、ユーザーをホームページに移動させました。
- ブラウザがホームページの読み込みを開始します。
document.location.reload();コメットは IE によってシャットダウンされていないため、サーバーから を受信し、ホームページの読み込みは中止され、ユーザーがログインせずに現在のページが再読み込みされます。
/session/logout の正しい結果をロードする必要があるため、これはまったく望ましくありません。特に、ユーザーがログイン時に実行できなかった何かを実行しようとしている場合 (この場合、302 が返されます) logout は、最初に行こうとしていた場所を指します)。
以前にこの種の問題に遭遇した人はいますか? この問題に対処する方法について何かアドバイスはありますか?