695

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

4

8 に答える 8

640

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

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

オリジンサーバーから送信された場合

max-age=0キャッシュ（およびユーザーエージェント）に応答が最初から古くなっていることを伝えるだけなので、キャッシュされたコピーを使用する前に応答を（ヘッダーIf-Not-Modifiedなどで）再検証する必要がありますが、キャッシュされたコピーを使用する前に再検証する必要no-cacheがあることを伝えますコピー。14.9.1からキャッシュ可能とは：

キャッシュなし

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

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

保管を妨げるものではないと言ったときのコメントは正しいですがno-cache、実際にはを使用する場合は別の違いになる可能性がありますno-cache。「キャッシュ制御ディレクティブの謎を解き明かす」というページに出くわしました（その正確さを保証することはできません）。

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

..。

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

余談ですが、Cache-Control: max-age=0, must-revalidate基本的にはと同じ意味であるように思われCache-Control: no-cacheます。それで、おそらくそれは、と同じことをすることへの明らかな移行を避けながら、のMUST -revalidateの振る舞いを取得する方法です（つまり、キャッシングはまったくありません）？no-cacheno-cacheno-store

ユーザーエージェントから送信された場合

shahkalpeshの答えはユーザーエージェント側にも当てはまると思います。13.2.6複数の応答の曖昧性解消もご覧ください。

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

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

于 2009-09-05T13:43:33.693 に答える
53

max-age = 0

これは、[更新]をクリックするのと同じです。つまり、最新のコピーを既に持っていない限り、最新のコピーを取得します。

キャッシュなし

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

于 2015-05-12T03:59:38.083 に答える
35

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

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

于 2010-11-27T09:13:04.877 に答える
29

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

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

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

一部のブラウザや一般的なキャッシュによって、機能的にno-cache同等のno-store。

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

于 2010-01-25T23:06:05.557 に答える
22 
最大年齢
    max-age = 0ディレクティブを使用して、中間キャッシュが強制的に再検証される場合
独自のキャッシュエントリであり、クライアントはリクエストで独自のバリデーターを提供しています。
提供されるバリデーターは、キャッシュエントリとともに現在保存されているバリデーターとは異なる場合があります。
この場合、キャッシュは、なしで独自のリクエストを行う際にいずれかのバリデーターを使用できます（MAY）。
セマンティックの透明性に影響を与えます。

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

    リクエストにno-cacheディレクティブが含まれている場合、min-freshを含めるべきではありません。
max-stale、またはmax-age。

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

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

于 2009-06-26T01:44:27.553 に答える
15

私はキャッシングの専門家ではありませんが、MarkNottinghamは専門家です。これが彼のキャッシングドキュメントです。彼はまた、参考文献セクションに優れたリンクを持っています。

これらのドキュメントを読んだmax-age=0ところ、「同じ時間」に着信したリクエストに対して、キャッシュがキャッシュされた応答を送信できるように見えます。「同じ時間」とは、キャッシュと同時に表示されるのに十分に近いことを意味しますが、そうでno-cacheはありません。 。

于 2009-06-26T01:59:10.130 に答える
14

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

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

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

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

通常の使用でも、一部の携帯電話は、たとえばExpires：0を介して新しいバージョンを完全にチェックできず、最後に変更された日付をチェックして、新しいバージョンを取得する必要があるかどうかを判断します。

それは単に起こらないので、私がしなければならなかったのは、更新を強制するために必要なcss /jsファイルにクエリ文字列を追加することでした。 .css？v = 1、次にv = 2（css / jsの更新）。これは主に機能します。

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

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

于 2016-04-13T19:49:06.113 に答える
1

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

于 2019-12-16T02:52:52.353 に答える