キャッシュなしとストアなしの両方をHTTP応答で使用する必要があるのはなぜですか？
ユーザー情報の漏洩を防ぐように言われましたが、応答の「キャッシュなし」だけでは十分ではありません。 「ストアなし」も必要です。
Cache-Control: no-cache, no-store
この仕様を読んだ後 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html 、なぜだかまだよくわかりません。
私の現在の理解では、それは中間キャッシュサーバー専用です。 「no-cache」が応答している場合でも、中間キャッシュサーバーはコンテンツを不揮発性ストレージに保存できます。中間キャッシュサーバーは、保存されたコンテンツを次の要求に使用するかどうかを決定します。ただし、応答に「ストアなし」が含まれる場合、中間キャッシュサーバーはコンテンツを格納することを想定していません。したがって、より安全です。
「キャッシュなし」と「ストアなし」の両方が必要な他の理由はありますか？
no-cacheは、キャッシュしないことを意味しないことを明確にしなければなりません。実際には、リクエストごとにキャッシュされた応答を使用する前に「サーバーで再検証」を意味します。
一方、must-revalidateは、リソースが古いと見なされた場合にのみ再検証する必要があります。
リソースがまだ有効であるとサーバーが言う場合、キャッシュはその表現で応答できるため、サーバーがリソース全体を再送信する必要性が軽減されます。
no-storeは事実上フルであり、キャッシュしないディレクティブであり、あらゆる形式のキャッシュでの表現の保存を防ぐことを目的としています。
なんと言っても、RFC 2616 HTTP仕様でこれに注意してください。
履歴バッファは、通常の操作の一部としてこのような応答を保存する場合があります
しかし、これは潜在的にno-storeをより強力にしようとする試みで、新しいRFC 7234 HTTP仕様から省略されています。
特定の状況下では、Cache-Control: no-cacheが応答ヘッダーにある場合でも、IE6はファイルをキャッシュします。
No-cacheディレクティブがフィールド名を指定しない場合、キャッシュは応答を使用して、Originサーバーとの再検証に成功せずに後続の要求を満たすことはできません。
私のアプリケーションでは、no-cacheヘッダーのあるページにアクセスし、ログアウトしてからブラウザーに戻った場合、IE6はキャッシュからページを取得します（サーバーへの新規/検証要求なし）。 no-storeヘッダーを追加すると停止しました。しかし、W3CをWordで使用する場合、実際にはこの動作を制御する方法はありません。
履歴バッファは、通常の操作の一部としてそのような応答を保存する場合があります。
ブラウザの履歴と通常のHTTPキャッシングの一般的な違いについては、 仕様の特定のサブセクション で説明されています。
HTTP 1.1仕様 から：
no-store：
no-storeディレクティブの目的は、機密情報（たとえばバックアップテープ）の不注意によるリリースまたは保持を防ぐことです。 no-storeディレクティブはメッセージ全体に適用され、応答または要求で送信される場合があります。要求で送信された場合、キャッシュはこの要求またはそれに対する応答の一部を保存してはなりません。応答で送信される場合、キャッシュはこの応答またはそれを誘発した要求のいずれかの部分を保存してはなりません。このディレクティブは、非共有キャッシュと共有キャッシュの両方に適用されます。このコンテキストでの「保存しない」とは、キャッシュが意図的に不揮発性ストレージに情報を保存してはならず、揮発性ストレージから情報を転送後できるだけ早く削除するためのベストエフォートの試みを行わなければならないことを意味します。このディレクティブが応答に関連付けられている場合でも、ユーザーはそのような応答をキャッシングシステムの外部に明示的に保存できます（たとえば、[名前を付けて保存]ダイアログを使用）。履歴バッファは、通常の操作の一部としてそのような応答を保存する場合があります。このディレクティブの目的は、キャッシュデータ構造への予期せぬアクセスによる情報の偶発的なリリースを懸念する特定のユーザーおよびサービス作成者の規定要件を満たすことです。このディレクティブを使用するとプライバシーが向上する場合がありますが、プライバシーを確保するための信頼できるメカニズムまたは十分なメカニズムではないことに注意してください。特に、悪意のあるまたは侵害されたキャッシュはこのディレクティブを認識または従わない可能性があり、通信ネットワークは盗聴に対して脆弱である可能性があります。
すべてのキャッシュを防止する場合（たとえば、[戻る]ボタンを使用するときに強制的にリロードする）：
iEのキャッシュなし
firefoxの非ストア
これに関する私の情報がここにあります：
http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/
no-storeは通常の状況では必要ではなく、速度と使いやすさの両方を損なう可能性があります。これは、HTTP応答に非常に機密性の高い情報が含まれている場合に使用することを目的としており、ユーザーに悪影響を与えるにもかかわらず、ディスクキャッシュに書き込まれることはありません。
使い方：
通常、ブラウザなどのユーザーエージェントが応答をキャッシュすべきでないと判断した場合でも、ユーザーエージェント内部の理由により、応答をディスクキャッシュに格納することがあります。このバージョンは、「ソースの表示」、「戻る」、「ページ情報」などの機能に利用できます。ユーザーは必ずしもページを再度要求する必要はありませんが、ブラウザは新しいページビューとは見なしません。ユーザーが現在表示しているのと同じバージョンを提供するのが理にかなっています。
no-storeを使用すると、その応答が保存されなくなりますが、これは、サーバーに対して新しい別個の要求を行うことなく、「ソースの表示」、「戻る」、「ページ情報」などを提供するブラウザーの機能に影響を与える可能性があります望ましくない。言い換えれば、ユーザーはソースを表示しようとする場合があり、ブラウザがソースをメモリに保持しなかった場合、これは不可能であるか、サーバーへの新しいリクエストが発生することを通知されます。したがって、no-storeは、コンテンツがキャッシュに保存されないようにすることの重要性が、これらの機能の適切または迅速な動作の妨げとなるユーザーエクスペリエンスを上回る場合にのみ使用する必要があります。
私の現在の理解では、これは中間キャッシュサーバー専用です。 「no-cache」が応答している場合でも、中間キャッシュサーバーはコンテンツを不揮発性ストレージに保存できます。
これは間違っています。 HTTP 1.1と互換性のある中間キャッシュサーバーは、no-cacheおよびmust-revalidateの指示に従い、コンテンツがキャッシュされないようにします。これらの指示を使用すると、応答が中間キャッシュによってキャッシュされず、後続のすべてのリクエストがOriginサーバーに送り返されます。
中間キャッシュサーバーがHTTP 1.1をサポートしていない場合は、Pragma: no-cacheを使用する必要があります。 HTTP 1.1をサポートしない場合、no-storeはとにかく無関係であることに注意してください。
キャッシングシステムがノーストアを正しく実装している場合、ノーキャッシュは必要ありません。しかし、すべてがそうするわけではありません。さらに、一部のブラウザは、ストアなしのようにキャッシュなしを実装しています。したがって、厳密に必須ではありませんが、両方を含めるのがおそらく最も安全です。
Chromeの場合、no-cacheは再訪問時にページをリロードするために使用されますが、履歴に戻る（戻るボタン）場合は引き続きキャッシュします。履歴を戻すためにページをリロードするには、no-storeを使用します。 IEは、あらゆる場面で機能するために、再検証が必要です。
だから、私がいつも使っているすべてのバグと誤解を避けるために
Cache-Control: no-store, no-cache, must-revalidate
確実にリロードしたい場合。
バージョン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を使用することは、今でも有効な最も近い方法のようです。
もともと私たちは何年も前にno-cacheを使用していましたが、特定のブラウザで古いコンテンツに関するいくつかの問題に遭遇しました...残念ながらその詳細を覚えてはいけません。
それ以来、ノーストアの使用のみを決定しました。過去を振り返ったり、ブラウザや仲介者による古いコンテンツに関する単一の問題が発生したことはありません。
この空間は、実装の現実と、たまたまさまざまなRFCで記述されたものに支配されています。特に多くのプロキシは、従うことになっているポリシーを独自のポリシーに置き換えることで、「パフォーマンスの向上」というより良い仕事をすると考えがちです。
さらに悪いことに、状況によっては、no-cacheは使用できませんが、no-storeは次のことができます。
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ディレクティブはメッセージ全体に適用され、キャッシュが応答またはそれを要求したリクエストの一部を保存してはならないことを示します。
これらのディレクティブで完全に安全ですか？
いいえ。ただし、通常は、有効期限：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"'属性を含める必要があります。ただし、この属性は非標準であることに注意する必要があります（ただし、主要なブラウザでサポートされています）ので、XHTML検証が中断されます。
ソース ここ 。