1

次のような状況があります。

  • ユーザーは、フォームを表示するページ A にリクエストを行います (サーバーはこのページのキャッシュを保存します)
  • ユーザーは、フォームの送信に使用される CONTROLLER にフォームを送信します
  • CONTROLLER は、ユーザーが送信したデータのエラーを検出し、そのエラーの詳細を示す Cookie ERRORS を設定し、ユーザーをページ A にリダイレクトします。
  • ページ A には、元のコンテンツとエラーが表示されます (サーバーはこのページのキャッシュを保存します)。
  • ページ A は ERRORS Cookie を削除します

これは機能しますが、ページ A のシステムでキャッシュを使用しない場合に限ります。

問題は、Cookie を削除した後、ブラウザが Cookie を使用せずにサーバーにリクエストを送信し、304 Not Modified エラーが発生することです。その結果、(元のリクエストから) エラーなしではなく、エラーのあるページがブラウザに表示されます。 ）。サーバーはキャッシュを適切に保存します (エラーのあるページとエラーのないページの場合)。

基本的に、サーバーには 2 つのキャッシュ ページがあります。PAGE A と PAGE A WITH ERRORS です。

最後に認識されたページが PAGE A WITH ERRORS であったブラウザは、Cookie がもう存在しないため、PAGE A WITH ERRORS ではなく、PAGE A の条件を持つページをサーバーに要求します。しかし、304 応答は PAGE A ではなく、PAGE A WITH ERRORS に関するものであると考えています。ブラウザから送信されたデータを確認したところ、ERRORS Cookie を使用して PAGE A WITH ERRORS を取得したことがわかっていますが、変更されていない 304 を受け入れます。そのCookieなしでリクエストを作成します。作成された条件に対して独自のキャッシュを検証しません。

ブラウザは、設定した Cookie でキャッシュを検証しませんか?

また、リクエストごとにいくつかのGET変数を設定せずに回避策はありますか? もう 1 つの方法は、そのような ERRORS 状態が設定されたページを決してキャッシュしないようにサーバーに指示することですが、これはハックになります。

4

3 に答える 3

2

どうやら解決策は、これを応答ヘッダーとして含めることでした:

Vary: Cookie

これにより、キャッシュ エンジンで Cookie が考慮されます。

編集：

ただし、問題があります。Chrome、Internet Explorer、および Firefox は期待どおりに動作しますが、Safari と Opera はどちらも、キャッシュを保存して検証するときに「Vary」ヘッダーを無視します。

于 2012-10-23T12:49:30.867 に答える
1

クライアント側のセッション (別名 Cookie) は、このシナリオにはおそらく十分ではありません...代わりにサーバー側のセッションをお勧めします。Vary ヘッダーが機能する場合でも - $_SESSION を使用すると、保存側になります。

于 2012-10-24T00:04:53.117 に答える
0

キャッシュ制御: public はおそらくあなたが望むものではありません。Public は基本的に、静的でグローバルにアクセス可能なデータを操作していることを意味します。ユーザーごとに変更されることはありません。データがグローバルであると主張しているため、グローバルにキャッシュしています。

ユーザーごとに変更を開始するとすぐに、キャッシュの想定が破られます。「プライベート」は、あなたが望むものに似ています。

ただし、これは、優れた仲介者のキャッシュが少なくなることを意味します. 再検証するか、Vary ヘッダーを適切に使用することで、妥協点を見つけられるかもしれません。

于 2012-10-23T11:27:35.097 に答える