ユーザー情報の漏洩を防ぐように言われましたが、応答として「キャッシュなし」だけでは不十分です。「ノーストア」も必要です。
Cache-Control: no-cache, no-store
この仕様http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.htmlを読んだ後、私はまだ理由がよくわかりません。
私の現在の理解は、それは中間キャッシュサーバー専用であるということです。「キャッシュなし」が応答した場合でも、中間キャッシュサーバーはコンテンツを不揮発性ストレージに保存できます。中間キャッシュサーバーは、保存されたコンテンツを次のリクエストに使用するかどうかを決定します。ただし、応答に「no-store」が含まれている場合、中間キャッシュサーバーはコンテンツを保存することは想定されていません。だから、それはより安全です。
「キャッシュなし」と「ストアなし」の両方が必要な他の理由はありますか？
キャッシュno-cacheしないという意味ではないことを明確にする必要があります。実際、これは、すべてのリクエストで、キャッシュされた応答を使用する前に「サーバーで再検証する」ことを意味します。
must-revalidate一方、リソースが古くなっていると見なされた場合にのみ、再検証する必要があります。
サーバーがリソースがまだ有効であると言った場合、キャッシュはその表現で応答できるため、サーバーがリソース全体を再送信する必要がなくなります。
no-store事実上、完全なキャッシュしないディレクティブであり、いかなる形式のキャッシュでも表現が保存されないようにすることを目的としています。
私は何でも言いますが、RFC2616HTTP仕様でこれに注意してください。
履歴バッファは、通常の操作の一部としてそのような応答を保存してもよい[MAY]
no-storeただし、これは、より強力にするために、新しいRFC7234HTTP仕様から省略されています。以下を参照してください。
Cache-Control: no-cache特定の状況下では、IE6は、が応答ヘッダーにある場合でもファイルをキャッシュします。
W3Cのno-cache状態：
no-cacheディレクティブでフィールド名が指定されていない場合、キャッシュは、オリジンサーバーでの再検証が成功しない限り、応答を使用して後続の要求を満たすことはできません（MUSTNOT）。
私のアプリケーションでは、no-cacheヘッダーのあるページにアクセスし、ログアウトしてからブラウザーで再度アクセスした場合でも、IE6はキャッシュからページを取得します（サーバーへの新規/検証要求はありません）。ヘッダーを追加すると、no-store停止しました。しかし、W3Cを彼らの言葉で理解すると、実際にはこの動作を制御する方法はありません。
履歴バッファは、通常の操作の一部としてそのような応答を保存してもよい[MAY]。
ブラウザの履歴と通常のHTTPキャッシングの一般的な違いは、仕様の特定のサブセクションで説明されています。
HTTP 1.1仕様から：
ノーストア：
ノーストアの目的指示は、機密情報の不注意なリリースまたは保持を防ぐことです（たとえば、バックアップテープ上）。no-storeディレクティブはメッセージ全体に適用され、応答または要求のいずれかで送信される場合があります。リクエストで送信された場合、キャッシュはこのリクエストまたはそれに対する応答のいずれかの部分を保存してはなりません（MUSTNOT）。応答で送信される場合、キャッシュは、この応答またはそれを誘発した要求のいずれかの部分を格納してはなりません（MUSTNOT）。このディレクティブは、非共有キャッシュと共有キャッシュの両方に適用されます。この文脈での「保存してはならない」とは、キャッシュが意図的に情報を不揮発性ストレージに保存してはならず、転送後できるだけ早く情報を揮発性ストレージから削除するように最善を尽くさなければならないことを意味します。このディレクティブが応答に関連付けられている場合でも、ユーザーは、そのような応答をキャッシングシステムの外部に明示的に保存する場合があります（たとえば、[名前を付けて保存]ダイアログを使用）。履歴バッファは、通常の操作の一部としてそのような応答を保存してもよい[MAY]。このディレクティブの目的は、キャッシュデータ構造への予期しないアクセスによる情報の偶発的なリリースを懸念している特定のユーザーおよびサービス作成者の規定された要件を満たすことです。このディレクティブを使用するとプライバシーが改善される場合がありますが、プライバシーを確保するための信頼できる、または十分なメカニズムではないことに注意してください。特に、悪意のあるキャッシュや侵害されたキャッシュはこのディレクティブを認識または従わない可能性があり、通信ネットワークは盗聴に対して脆弱である可能性があります。履歴バッファは、通常の操作の一部としてそのような応答を保存してもよい[MAY]。このディレクティブの目的は、キャッシュデータ構造への予期しないアクセスによる情報の偶発的なリリースを懸念している特定のユーザーおよびサービス作成者の規定された要件を満たすことです。このディレクティブを使用するとプライバシーが改善される場合がありますが、プライバシーを確保するための信頼できる、または十分なメカニズムではないことに注意してください。特に、悪意のあるキャッシュや侵害されたキャッシュはこのディレクティブを認識または従わない可能性があり、通信ネットワークは盗聴に対して脆弱である可能性があります。履歴バッファは、通常の操作の一部としてそのような応答を保存してもよい[MAY]。このディレクティブの目的は、キャッシュデータ構造への予期しないアクセスによる情報の偶発的なリリースを懸念している特定のユーザーおよびサービス作成者の規定された要件を満たすことです。このディレクティブを使用するとプライバシーが改善される場合がありますが、プライバシーを確保するための信頼できる、または十分なメカニズムではないことに注意してください。特に、悪意のあるキャッシュや侵害されたキャッシュはこのディレクティブを認識または従わない可能性があり、通信ネットワークは盗聴に対して脆弱である可能性があります。このディレクティブを使用するとプライバシーが改善される場合がありますが、プライバシーを確保するための信頼できる、または十分なメカニズムではないことに注意してください。特に、悪意のあるキャッシュや侵害されたキャッシュはこのディレクティブを認識または従わない可能性があり、通信ネットワークは盗聴に対して脆弱である可能性があります。このディレクティブを使用するとプライバシーが改善される場合がありますが、プライバシーを確保するための信頼できる、または十分なメカニズムではないことに注意してください。特に、悪意のあるキャッシュや侵害されたキャッシュはこのディレクティブを認識または従わない可能性があり、通信ネットワークは盗聴に対して脆弱である可能性があります。
no-store通常の状況では必要ないはずであり、速度と使いやすさの両方を損なう可能性があります。これは、HTTP応答に機密情報が含まれている場合に使用することを目的としており、ユーザーに悪影響を与える場合でも、ディスクキャッシュに書き込まれることはありません。
使い方：
通常、ブラウザなどのユーザーエージェントが応答をキャッシュすべきではないと判断した場合でも、ユーザーエージェントの内部的な理由により、応答をディスクキャッシュに保存する場合があります。このバージョンは、「ソースの表示」、「戻る」、「ページ情報」などの機能に利用できます。ユーザーは必ずしもページを再度要求していませんが、ブラウザはそれを新しいページビューとは見なしません。そして、ユーザーが現在表示しているのと同じバージョンを提供することは理にかなっています。
を使用no-storeすると、その応答が保存されなくなりますが、これは、サーバーに対して新しい個別の要求を行わずに「ソースの表示」、「戻る」、「ページ情報」などを提供するブラウザーの機能に影響を与える可能性があります。これは望ましくありません。つまり、ユーザーはソースを表示しようとして、ブラウザがソースをメモリに保持していなかった場合、これは不可能であると通知されるか、サーバーに新しいリクエストが発生します。したがって、no-storeこれらの機能が適切にまたは迅速に機能しないというユーザーエクスペリエンスの妨げが、コンテンツがキャッシュに保存されないようにすることの重要性よりも重要である場合にのみ使用する必要があります。
私の現在の理解は、それは中間キャッシュサーバー専用であるということです。「キャッシュなし」が応答した場合でも、中間キャッシュサーバーはコンテンツを不揮発性ストレージに保存できます。
これは正しくありません。HTTP 1.1と互換性のある中間キャッシュサーバーはno-cacheとのmust-revalidate指示に従い、コンテンツがキャッシュされないようにします。これらの手順を使用すると、応答が中間キャッシュによってキャッシュされないようになり、後続のすべての要求がオリジンサーバーに返送されます。
中間キャッシュサーバーがHTTP1.1をサポートしていない場合はPragma: no-cache、最高のものを使用して期待する必要があります。HTTP 1.1をサポートしていない場合は、no-storeとにかく無関係であることに注意してください。
すべてのキャッシュを防止したい場合（たとえば、戻るボタンを使用するときに強制的にリロードする）、次のものが必要です。
IEのキャッシュなし
Firefoxの店舗はありません
これについての私の情報はここにあります：
http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/
キャッシングシステムがno-storeを正しく実装している場合は、no-cacheは必要ありません。しかし、すべてがそうするわけではありません。さらに、一部のブラウザは、ストアなしのようにキャッシュなしを実装します。したがって、厳密には必須ではありませんが、両方を含めるのがおそらく最も安全です。
Chromeの場合、再訪問時にページをリロードするためにキャッシュなしが使用されますが、履歴に戻ると（戻るボタン）、キャッシュは引き続きキャッシュされます。履歴を戻すためにページをリロードするには、no-storeを使用します。IEは、あらゆる場面で機能するために再検証する必要があります。
だから私がいつも使っているすべてのバグや誤解を避けるために
Cache-Control: no-store, no-cache, must-revalidate
リロードすることを確認したい場合。
バージョン5から8までのInternetExplorerは、httpsおよびサーバー送信Cache-Control: no-cacheまたはPragma: no-cacheヘッダーを介して提供されるファイルをダウンロードしようとすると、エラーをスローすることに注意してください。
http://support.microsoft.com/kb/812935/en-usを参照してください
との使用はCache-Control: no-store、Pragma: privateまだ機能している最も近いもののようです。
もともと私たちは何年も前にキャッシュなしを使用していましたが、特定のブラウザで古いコンテンツでいくつかの問題が発生しました...残念ながら詳細を覚えていないでください。
それ以来、私たちはノーストアの使用だけに落ち着きました。それ以来、ブラウザや仲介業者による古いコンテンツについて振り返ったり、単一の問題が発生したことはありません。
このスペースは確かに実装の現実とさまざまなRFCで書かれたものによって支配されています。特に多くのプロキシは、従うことになっているポリシーを独自のポリシーに置き換えることで、「パフォーマンスを向上させる」というより良い仕事をしていると考える傾向があります。
さらに悪いことに、状況によっては、no-cacheを使用できませんが、no-storeは次のことができます。
http://faindu.wordpress.com/2008/04/18/ie7-ssl-xml-flex-error-2032-stream-error/
質問に答えるために、ここにはクライアント（要求）とサーバー（応答）の2つのプレーヤーがあります。
クライアント：
クライアントは、1つのキャッシュ方式でのみ要求できます。さまざまな方法があり、指定されていない場合はを使用しますdefault。
ノート：
age内にあることを意味します。stale-while-revalidate「再検証」が必要ですが、それでも返品できます。If-Modified-Sinceに、などのヘッダーを使用してフェッチすることを意味します。ETag304: (Not Modified)https://fetch.spec.whatwg.org/#concept-request-cache-mode
サーバー::
クライアントが何ができるかを理解したので、サーバーの応答はより理にかなっています。Cache-Controlヘッダーを見て、サーバーが次を返す場合：
これで、すべてをまとめることができます。つまり、唯一の可能性は次のとおりです。
クライアントまたはサーバーの任意の組み合わせで、使用するメソッドまたはメソッドのセットを指定できます。サーバーが戻っno-storeてきた場合、クライアントの要求タイプに関係なく、サーバーはキャッシュにヒットしません。クライアントリクエストがだった場合no-store、サーバーが何を返すかは関係なく、キャッシュされません。クライアントがリクエストタイプを指定しない場合、サーバーはそれをで指示しCache-Controlます。
no-cacheサーバーが両方を返すことは意味がなく、すべてをオーバーライドするno-storeためです。はい、おそらく両方を一緒に見たことがあるでしょう、そしてそれは壊れたブラウザの実装以外では役に立たないです。それでも、1999年から仕様の一部になっています：https ：//datatracker.ietf.org/doc/html/rfc2616#section-14.9.2no-storeno-store
実際の使用法では、サーバーがをサポートしていて304: Not Modified、速度を向上させる方法としてクライアントキャッシュを使用したいが、それでもネットワークフェッチを強制したい場合は、を使用しますno-cache。をサポートしておらず304、ネットワークフェッチを強制する場合は、を使用しますno-store。キャッシュに問題がない場合は、鮮度と再検証のヘッダーを使用してください。
実際には、クライアントを混同しno-cacheてno-storeいる場合、ほとんど変化しません。次に、いくつかのヘッダーが送信され、ブラウザーによって処理されるさまざまな内部応答があります。no-cache使用した後、使用し忘れると問題が発生する可能性があります。no-cache応答をキャッシュに保存するように指示し、それなしで後の要求が内部キャッシュをトリガーする可能性があります。
コンテキストに基づいて、同じリソース上でもメソッドを混在させたい場合があります。たとえばreload、Service Workerとバックグラウンド同期で使用したいdefaultが、Webページ自体には使用したい場合があります。ここで、ユーザーエージェント（ブラウザー）のキャッシュを好みに合わせて操作できます。通常、キャッシュがどのように機能するかについては、サーバーが最終決定権を持っていることを覚えておいてください。
将来起こりうる混乱を明らかにするため。クライアントはリクエストのCache-Controlヘッダーを使用して、応答時に独自のキャッシュシステムを使用しないようにサーバーに指示できます。これは、ブラウザ/サーバーダイナミックとは関係なく、サーバー/データベースダイナミックとは関係ありません。
また、no-store技術的には、不揮発性ストレージ（ディスク）に保存して、揮発性ストレージ（メモリ）からできるだけ早く解放してはならないことを意味します。実際には、キャッシュをまったく使用しないことを意味します。コマンドは実際には双方向に実行されます。を使用したクライアント要求はno-store、ディスクまたはデータベースに書き込むべきではなく、一時的なものです。
TL; DR：no-storeオーバーライドしますno-cache。サポートされていない仕様外またはHTTP/1.0ブラウザーno-store（多分IE11？）を話しているのでない限り、両方を設定することは無意味です。サポートに使用no-cacheし304ます。
OWASPはこれについて説明しています：
cache-controlディレクティブの違いは何ですか：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コンテンツタイプはキャッシュされることがよくあります（ただし、これはバージョンや、再検証が必要な追加の使用、事前チェック= 0、事後チェックによって異なります） = 0、max-age = 0、およびs-maxage = 0は、実際には、ブラウザーの癖やHTTPの実装が原因で、ブラウザーを閉じたときに少なくともファイルが削除される場合があります。また、「オートコンプリート」機能を使用すると、ユーザーがフォームの入力フィールドに入力した内容をブラウザがキャッシュできます。これを確認するには、フォームタグまたは個々の入力タグに「Autocomplete="Off"」属性を含める必要があります。でも、
ソースはこちら。