キャッシュなしとストアなしの両方をHTTP応答で使用する必要があるのはなぜですか？

ユーザー情報の漏えいを防ぐように言われましたが、「キャッシュなし」だけでは不十分です。「ノーストア」も必要です。

Cache-Control: no-cache, no-store

この仕様http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.htmlを読んだ後でも、理由はまだよくわかりません。

私の現在の理解は、それが中間キャッシュサーバーのためだけのものであるということです。「キャッシュなし」が応答した場合でも、中間キャッシュサーバーはコンテンツを不揮発性ストレージに保存できます。中間キャッシュサーバーは、保存されたコンテンツを次の要求に使用するかどうかを決定します。ただし、「no-store」が応答にある場合、中間キャッシュサーバーはコンテンツを保存することを想定していません。したがって、それはより安全です。

「キャッシュなし」と「ストアなし」の両方が必要な他の理由はありますか？

キャッシュno-cacheしないという意味ではないことを明確にする必要があります。実際、すべてのリクエストで、キャッシュされたレスポンスを使用する前に、「サーバーで再検証」することを意味します。

must-revalidate一方、リソースが古くなっていると見なされた場合にのみ、再検証が必要です。

リソースがまだ有効であるとサーバーが言った場合、キャッシュはその表現で応答できるため、サーバーがリソース全体を再送信する必要性が軽減されます。

no-store事実上、完全なキャッシュ禁止ディレクティブであり、いかなる形式のキャッシュにも表現が格納されないようにすることを目的としています。

私は何と言っても、RFC 2616 HTTP仕様でこれに注意してください。

履歴バッファは、通常の操作の一部としてそのような応答を格納することができます

しかし、これは新しいRFC 7234 HTTP仕様から省略されている可能性がありno-storeます。

http://tools.ietf.org/html/rfc7234#section-5.2.1.5

特定の状況下では、IEはCache-Control: no-cache応答ヘッダーにある場合でもファイルをキャッシュします。

W3Cは、の状態no-cache：

no-cacheディレクティブでフィールド名が指定されていない場合、キャッシュは、オリジンサーバーでの再検証に成功せずに、後続の要求を満たすために応答を使用してはなりません（MUST NOT）。

私のアプリケーションでは、no-cacheヘッダーのあるページにアクセスし、ログアウトしてからブラウザーに戻ると、IE6はキャッシュからページを取得します（サーバーへの新規/検証要求なし）。no-storeヘッダーに追加することで停止しました。しかし、実際にW3Cを採用した場合、この動作を制御する方法は実際にはありません。

履歴バッファは、通常の操作の一部としてそのような応答を格納してもよい（MAY）。

ブラウザの履歴と通常のHTTPキャッシングの一般的な違いについては、仕様の特定のサブセクションで説明しています。

以下からのHTTP 1.1の仕様：

ノーストア：

ノーストアの目的ディレクティブは、機密情報（バックアップテープなど）の不注意によるリリースまたは保持を防ぐことです。no-storeディレクティブはメッセージ全体に適用され、応答または要求のいずれかで送信される場合があります。リクエストで送信される場合、キャッシュはこのリクエストまたはリクエストへの応答のいずれの部分も保存してはなりません（MUST NOT）。応答で送信される場合、キャッシュは、この応答またはそれを引き出した要求のいずれの部分も格納してはなりません（MUST NOT）。このディレクティブは、非共有キャッシュと共有キャッシュの両方に適用されます。この場合の「格納しない」とは、キャッシュが情報を意図的に不揮発性ストレージに格納してはならず、情報を転送した後、できるだけ早く揮発性ストレージから情報を削除するよう最善を尽くさなければならないことを意味します。このディレクティブが応答に関連付けられている場合でも、ユーザーは、このような応答をキャッシュシステムの外部に明示的に保存する場合があります（たとえば、[名前を付けて保存]ダイアログを使用）。履歴バッファは、通常の操作の一部としてそのような応答を格納してもよい（MAY）。このディレクティブの目的は、キャッシュデータ構造への予期しないアクセスを介した情報の偶発的な放出を懸念する特定のユーザーおよびサービス作成者の規定された要件を満たすことです。このディレクティブを使用するとプライバシーが向上する場合がありますが、プライバシーを確​​保するための信頼できるメカニズムや十分なメカニズムではありません。特に、悪意のある、または侵害されたキャッシュはこのディレクティブを認識または従わず、通信ネットワークは盗聴に対して脆弱である可能性があります。履歴バッファは、通常の操作の一部としてそのような応答を格納してもよい（MAY）。このディレクティブの目的は、キャッシュデータ構造への予期しないアクセスを介した情報の偶発的な放出を懸念する特定のユーザーおよびサービス作成者の規定された要件を満たすことです。このディレクティブを使用するとプライバシーが向上する場合がありますが、プライバシーを確​​保するための信頼できるメカニズムや十分なメカニズムではありません。特に、悪意のある、または侵害されたキャッシュはこのディレクティブを認識または従わず、通信ネットワークは盗聴に対して脆弱である可能性があります。履歴バッファは、通常の操作の一部としてそのような応答を格納してもよい（MAY）。このディレクティブの目的は、キャッシュデータ構造への予期しないアクセスを介した情報の偶発的な放出を懸念する特定のユーザーおよびサービス作成者の規定された要件を満たすことです。このディレクティブを使用するとプライバシーが向上する場合がありますが、プライバシーを確​​保するための信頼できるメカニズムや十分なメカニズムではありません。特に、悪意のある、または侵害されたキャッシュはこのディレクティブを認識または従わず、通信ネットワークは盗聴に対して脆弱である可能性があります。このディレクティブを使用するとプライバシーが向上する場合がありますが、プライバシーを確​​保するための信頼できるメカニズムや十分なメカニズムではありません。特に、悪意のある、または侵害されたキャッシュはこのディレクティブを認識または従わず、通信ネットワークは盗聴に対して脆弱である可能性があります。このディレクティブを使用するとプライバシーが向上する場合がありますが、プライバシーを確​​保するための信頼できるメカニズムや十分なメカニズムではありません。特に、悪意のある、または侵害されたキャッシュはこのディレクティブを認識または従わず、通信ネットワークは盗聴に対して脆弱である可能性があります。

すべてのキャッシュを防止する場合（たとえば、[戻る]ボタンを使用するときに強制的にリロードする）には、次のものが必要です。

• IEのキャッシュなし

• Firefoxのストアなし

これに関する私の情報はここにあります：

http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/

no-store通常の状況では必要ないはずであり、速度と使いやすさの両方を損なう可能性があります。これは、HTTP応答に機密性の高い情報が含まれている場合に使用することを目的としています。ユーザーに悪影響を与えるかどうかに関係なく、ディスクキャッシュに書き込まれることはありません。

使い方：

• 通常、ブラウザーなどのユーザーエージェントが応答をキャッシュしないと判断した場合でも、ユーザーエージェント内部の理由により、応答をディスクキャッシュに保存することがあります。このバージョンは、「ソースの表示」、「戻る」、「ページ情報」などの機能に利用できます。この場合、ユーザーは必ずしもページを再度要求したわけではありませんが、ブラウザは新しいページビューとは見なしません。ユーザーが現在表示しているのと同じバージョンを提供することは理にかなっています。

• を使用no-storeすると、その応答が保存されなくなりますが、サーバーに対して新しい個別の要求を行わずにブラウザの「ソースの表示」、「戻る」、「ページ情報」などを提供する機能に影響を与える可能性があるため、望ましくありません。言い換えると、ユーザーはソースを表示しようとする可能性があり、ブラウザがそれをメモリに保持していなかった場合、これは不可能であると通知されるか、サーバーに新しいリクエストが発生します。したがって、no-storeこれらの機能が適切に機能しない、またはすぐに機能が妨げられるユーザーエクスペリエンスが、コンテンツがキャッシュに保存されないようにすることの重要性を上回っている場合にのみ使用してください。

私の現在の理解は、それが中間キャッシュサーバーのためだけのものであるということです。「キャッシュなし」が応答した場合でも、中間キャッシュサーバーはコンテンツを不揮発性ストレージに保存できます。

これは誤りです。HTTP 1.1と互換性のある中間キャッシュサーバーは、no-cacheおよびのmust-revalidate指示に従い、コンテンツがキャッシュされないようにします。これらの手順を使用すると、応答が中間キャッシュにキャッシュされないこと、および後続のすべての要求がオリジンサーバーに送り返されることが保証されます。

中間キャッシュサーバーがHTTP 1.1をサポートしていない場合はPragma: no-cache、最高のものを使用して期待する必要があります。HTTP 1.1をサポートしていない場合no-storeは、とにかく関係がないことに注意してください。

キャッシングシステムがストアなしを正しく実装している場合、キャッシュなしは必要ありません。しかし、すべてではありません。さらに、一部のブラウザーは、ストアがない場合と同様に、キャッシュを実装していません。したがって、厳密には必須ではありませんが、両方を含めるのがおそらく最も安全です。

バージョン5から8までのInternet Explorerは、httpsを介して提供されるファイルをダウンロードしようとすると、エラーがスローされ、サーバーが送信することに注意してください。 Cache-Control: no-cacheまたはPragma: no-cacheヘッダーを。

http://support.microsoft.com/kb/812935/en-usを参照してください

との使用はCache-Control: no-store、Pragma: privateまだ機能する最も近いもののようです。

Chromeの場合、再訪問時にページを再読み込みするためにno-cacheが使用されますが、履歴に戻る場合（戻るボタン）は引き続きキャッシュされます。履歴を戻すためにページをリロードするには、no-storeを使用します。IEはあらゆる状況で機能するように再検証する必要があります。

だから私がいつも使うすべてのバグと誤解を避けるために

Cache-Control: no-store, no-cache, must-revalidate

リロードを確認したい場合。

元々、私たちは何年も前にキャッシュなしを使用しており、特定のブラウザーで古いコンテンツでいくつかの問題に遭遇しました...残念ながら、詳細を覚えてはいけません。

それ以来、私たちはストアの使用をJUSTに決めました。それ以降、ブラウザや仲介者が古いコンテンツを振り返ったり、単一の問題を抱えたりしたことがありません。

このスペースは確かに、実装の現実とさまざまなRFCで記述されていることによって支配されています。特に多くのプロキシは、従うことになっているポリシーを独自のものに置き換えることで、「パフォーマンスの向上」というより良い仕事をすると考えがちです。

さらに悪いことに、一部の状況では、キャッシュなしは使用できませんが、ストアなしはできます。

http://faindu.wordpress.com/2008/04/18/ie7-ssl-xml-flex-error-2032-stream-error/

OWASPはこれについて議論します：

キャッシュ制御ディレクティブの違いは何ですか：no-cacheとno-store？

応答のno-cacheディレクティブは、後続の要求を処理するために応答を使用してはならないことを示します。つまり、キャッシュはこのディレクティブがヘッダーに設定されている応答を表示してはならず、サーバーが要求を処理できるようにする必要があります。no-cacheディレクティブには、いくつかのフィールド名を含めることができます。その場合、サーバーから提供される必要がある指定されたフィールド名を除いて、キャッシュから応答を表示できます。no-storeディレクティブはメッセージ全体に適用され、要求された応答または要求の一部をキャッシュに保存してはならないことを示します。

これらの指令は完全に安全ですか？

いいえ。ただし、通常、Expires：0（またはUNIXエポックなどの十分に日付が変更されたGMT日付）に加えて、Cache-Control：no-cache、no-storeおよびPragma：no-cacheの両方を使用します。PDF、Word文書、Excelスプレッドシートなどの非HTMLコンテンツタイプは、上記のキャッシュ制御ディレクティブが設定されている場合でもキャッシュされることがよくあります（ただし、これはバージョンや、must-revalidate、pre-check = 0、post-checkの追加の使用によって異なります） = 0、max-age = 0、およびs-maxage = 0は、実際には、ブラウザの癖やHTTPの実装が原因で、少なくともブラウザが閉じたときにファイルが削除されることがあります）。また、「オートコンプリート」機能により、ブラウザは、ユーザーがフォームの入力フィールドに入力したものをキャッシュできます。これを確認するには、フォームタグまたは個々の入力タグに 'Autocomplete = "Off"'属性を含める必要があります。しかしながら、

ソースはこちら。