Cache-Control：max-age = 0とno-cacheの違いは何ですか？

ヘッダーCache-Control: max-age=0は、コンテンツがすぐに古くなっていると見なされ（再フェッチする必要がある）ことを意味します。これは、実質的にと同じですCache-Control: no-cache。

これと同じ質問があり、検索でいくつかの情報が見つかりました（あなたの質問が結果の1つとして浮上しました）。これが私が決めたものです...

Cache-Controlヘッダーには2つの側面があります。一方は、Webサーバー（別名「元サーバー」）が送信できる場所です。反対側は、ブラウザ（別名「ユーザーエージェント」）から送信できる場所です。

オリジンサーバーから送信されたとき

私は信じているmax-age=0だけで応答がより古くなったキャッシュ（およびユーザエージェント）伝えるのget-行くと、彼らはそうすべきである応答を再検証（例えばとIf-Not-Modifiedヘッダ）キャッシュされたコピーを使用する前に、一方でno-cache、彼らはそれらを伝えなければならキャッシュされたを使用する前に再検証コピー。14.9.1からキャッシュ可能とは：

キャッシュなし

...キャッシュは、オリジンサーバーでの再検証に成功せずに、後続の要求を満たすために応答を使用してはなりません（MUST NOT）。これにより、オリジンサーバーは、クライアント要求に対して古い応答を返すように構成されたキャッシュによっても、キャッシュを防止できます。

言い換えると、キャッシュは古い応答を使用することを選択する場合があります（ただし、Warningヘッダーを追加する必要があると思います）が、no-cacheどのような場合でも古い応答を使用することは許可されていません。たぶん、あなたはしたいと思いSHOULD野球の統計情報がページに生成されたときに-revalidate動作をしますが、したいと思いますMUSTあなたは電子商取引の購入に対する応答を生成した-revalidate行動を。

no-cacheストレージを妨げるものではないと言うときのコメントは正しいですが、を使用する場合は実際には別の違いになる可能性がありますno-cache。Cache Control Directives Demystifiedというページに出くわしました（その正確さについては保証できません）。

実際には、IEとFirefoxはno-cacheディレクティブを、ページをキャッシュしないようにブラウザーに指示するかのように扱い始めました。私たちはこの行動を約1年前から観察し始めました。この変更は、キャッシングを防止するためにこのディレクティブが広く（かつ不正に）使用されたことによって引き起こされたと思われます。

...

最近、「cache-control：no-cache」も「no-store」ディレクティブのように動作するようになったことに注意してください。

余談ですが、Cache-Control: max-age=0, must-revalidate基本的にはと同じことを意味するように思えますCache-Control: no-cache。ので、と同じことをするための明らかな移行を回避しながら（つまり、キャッシングをまったく行わない）、MUSTを再検証する必要があります。no-cacheno-cacheno-store

ユーザーエージェントによって送信されたとき

shahkalpeshの答えはユーザーエージェント側にも当てはまると思います。13.2.6複数回答の明確化もご覧ください。

ユーザーエージェントがCache-Control: max-age=0（別名「エンドツーエンドの再検証」）で要求を送信すると、途中の各キャッシュは、そのキャッシュエントリ（If-Not-Modifiedヘッダーなど）をオリジンサーバーに再検証します。応答が304（Not Modified）の場合、キャッシュされたエンティティを使用できます。

一方、Cache-Control: no-cache（「エンドツーエンドのリロード」とも呼ばれる）でリクエストを送信しても再検証されず、サーバーは応答時にキャッシュされたコピーを使用してはなりません（MUST NOT）。

max-age = 0

これは、[ 最新の情報に更新 ]をクリックするのと同じです。つまり、最新のコピーがない場合は、最新のコピーを取得します。

キャッシュなし

これは、Shiftキーを押しながら[更新]をクリックすることです。つまり、何があってもすべてをやり直すことができます。

古い質問ですが、他の誰かが私が行ったように検索でこれに遭遇した場合、IE9はこれを利用して、戻るボタンと進むボタンを使用するときのリソースの動作を構成するようです。とき最大エージング= 0が使用されているバック/フォワードプレス上のリソースを表示するときに、ブラウザが最後のバージョンを使用します。場合は何もキャッシュが使用されていない、リソースが再フェッチされます。

IE9キャッシングの詳細については、このmsdnキャッシングブログの投稿をご覧ください。

IE8とFirefox 3.5を使用した最近のテストでは、どちらもRFCに準拠しているようです。ただし、オリジンサーバーとの「使いやすさ」は異なります。IE8はとno-cache同じセマンティクスで応答を処理しmax-age=0,must-revalidateます。ただし、Firefox 3.5 はとno-cache同等に扱うようでno-store、パフォーマンスと帯域幅の使用量が少なくなります。

Squid Cacheは、デフォルトではno-cache、Firefoxのように、ヘッダーを付けて何も保存しないようです。

私のアドバイスはpublic,max-age=0、すべてのリクエストで鮮度をチェックする必要がある機密性の低いリソースを設定することですが、それでもキャッシュのパフォーマンスと帯域幅の利点を可能にします。同じ考慮事項を持つユーザーごとのアイテムの場合は、を使用しますprivate,max-age=0。

no-cache一部のブラウザや一般的なキャッシュによって、と同等の機能に改ざんされているように見えるので、完全に使用することは避けますno-store。

さらに、AkamaiとLimelightをエミュレートしないでください。彼らは本質的に主要なビジネスとして大規模なキャッシングアレイを実行しており、エキスパートである必要がありますが、実際にはネットワークからより多くのデータをダウンロードすることに強い関心を持っています。Googleもエミュレーションに適していないかもしれません。彼らは使用するように見えるmax-age=0か、no-cacheランダムにリソースに依存します。

最大年齢
    max-age = 0ディレクティブによって中間キャッシュが強制的に再検証される場合 
独自のキャッシュエントリ。クライアントはリクエストに独自のバリデータを提供し、 
指定されたバリデーターは、現在キャッシュエントリに保存されているバリデーターとは異なる場合があります。 
この場合、キャッシュは、いずれかのバリデーターを使用して、 
意味の透明性に影響を与えます。 

    ただし、バリデーターの選択はパフォーマンスに影響を与える可能性があります。最善のアプローチは
要求を行うときに独自のバリデーターを使用する中間キャッシュ。サーバーが応答した場合
304（未変更）の場合、キャッシュは検証済みのコピーをクライアントに返すことができます 
200（OK）応答。サーバーが新しいエンティティとキャッシュバリデーターで応答する場合、
ただし、中間キャッシュは、返されたバリデーターを、 
強力な比較機能を使用したクライアントのリクエスト。クライアントのバリデーターが
オリジンサーバーのものと等しい場合、中間キャッシュは単に304（Not 
変更）。それ以外の場合は、200（OK）応答で新しいエンティティを返します。

    リクエストにno-cacheディレクティブが含まれている場合は、min-freshを含めないでください。 
max-stale、またはmax-age。 

礼儀：http : //www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4

これを答えとして受け入れないでください-私はそれを読んで、それの本当の使い方を理解する必要があります:)

私はキャッシングのエキスパートではありませんが、マーク・ノッティンガムはそうです。これが彼のキャッシングドキュメントです。彼はまた、「参考文献」セクションに優れたリンクがあります。

それらのドキュメントの私の読書に基づいて、それはmax-age=0キャッシュが「同時」に来たリクエストにキャッシュされた応答を送信できるように見えるかもno-cacheしれません。 。

ちなみに、一部のモバイルデバイス、特にiPhone / iPadなどのApple製品は、no-cache、no-store、Expires：0などのヘッダーを完全に無視することに注意してください。フォームページ。

これにより、ユーザーのiPadがフォームプロセスを通じて到達したページ（ステップ2/3など）でスリープ状態になり、デバイスがストアを完全に無視するなどの問題が発生するため、頭痛の種に終わりはありません。キャッシュディレクティブは、私の知る限り、ページの最後の状態から仮想スナップショットを取得します。つまり、明示的に通知された内容を無視し、それだけでなく、保存してはならないページを取得します。 、実際に再度チェックせずに保存すると、セッションのさまざまな奇妙な問題が発生します。

誰かがやって来て、なぜ特にiphoneとipadでセッションエラーが発生しているのかわからない場合に備えて、これを追加します。これは、この領域で最悪の犯罪者であるようです。

私はこの問題でかなり大規模なデバッガーテストを行いましたが、これは私の結論です。デバイスはこれらのディレクティブを完全に無視します。

定期的に使用している場合でも、一部の携帯電話では、Expires：0を使用して新しいバージョンを確認できず、最後に変更された日付を確認して、新しいバージョンを取得する必要があるかどうかを確認します。

それは単に発生しないので、更新を強制するために必要なcss / jsファイルにクエリ文字列を追加することを余儀なくされました。それは愚かなモバイルデバイスをだまして、それが持っていないファイルであると思わせます： .css？v = 1、css / js更新の場合はv = 2。これは主に機能します。

ちなみに、2016年の時点でユーザーブラウザーもデフォルトのままにしておくと、私が継続的に発見するため（私たちのサイトには多くの変更と更新が行われます）、そのようなファイルの最終変更日をチェックできませんが、クエリ文字列メソッドはその問題を修正します。これは、ブラウザーで基本的な通常のユーザーデフォルトを使用する傾向があり、css / jsなどのキャッシュの問題を認識していないクライアントやオフィスの人々が気づいたことです。ほとんどの場合、変更時に新しいcss / jsを取得できません。つまり、ブラウザのデフォルト、主にMSIE / Firefoxは、指示されたとおりに動作せず、変更を無視し、最終更新日を無視し、Expires：0を明示的に設定しても検証しません。

これは多くの優れた技術情報を備えた優れたスレッドでしたが、特にモバイルデバイスでのこのサポートがいかに悪いかを指摘することも重要です。数か月ごとに、受信するヘッダーコマンドを追跡できない、またはそれらのコマンドを適切に干渉しないようにするための保護層を追加する必要があります。

（意外にも）言及されていないことの1つは、max-staleディレクティブを使用して、リクエストが古いデータを受け入れることを明示的に示すことができることです。その場合、サーバーがで応答したmax-age=0場合、キャッシュは応答が古くなっていると見なし、クライアントの要求[古くなっている可能性のあるデータを要求]を満たすためにそれを自由に使用できます。対照的に、サーバーno-cacheが実際に送信した場合max-stale、キャッシュは再検証する必要があるため、古いデータに対する（を使用した）クライアントからの要求よりも実際に優先されます。

違いは、no-cache（Firefoxではno-store）があらゆる種類のキャッシュを防止することです。これは、セキュリティで保護されたコンテンツが含まれるページがディスクに書き込まれないようにする場合や、[戻る]ボタンで再度アクセスした場合でも常に更新する必要があるページに役立ちます。

max-age = 0は、キャッシュエントリが古く、再検証が必要ですが、キャッシュを妨げないことを示します。多くの場合、ブラウザはリソースをブラウザセッションごとに1回だけ検証するため、新しいセッションでサイトにアクセスするまでコンテンツが更新されない場合があります。

通常、ブラウザーは、ブラウザーのキャッシュがいっぱいになったときに新しいコンテンツ用のスペースを再利用しない限り、期限切れのキャッシュエントリーを削除しません。no-store、no-cacheを使用すると、キャッシュエントリを明示的に削除できます。