ヘッダーはCache-Control: max-age=0
、コンテンツがすぐに古いものと見なされる(再取得する必要がある)ことを意味しており、これは実質的に と同じことですCache-Control: no-cache
。
ベストアンサー1
私も同じ疑問を抱いており、検索でいくつかの情報を見つけました (あなたの質問は結果の 1 つとして表示されました)。私が判断したことは次のとおりです...
ヘッダーには 2 つの側面がありますCache-Control
。1 つは Web サーバー (別名「オリジン サーバー」) によって送信される側です。もう 1 つはブラウザー (別名「ユーザー エージェント」) によって送信される側です。
オリジンサーバーから送信された場合
max-age=0
は、キャッシュ(およびユーザーエージェント)に、レスポンスが最初から古いことを伝え、キャッシュされたコピーを使用する前にレスポンス(たとえばヘッダー)を再検証する必要があることを伝えているだけだと思います。If-Not-Modified
一方、は、キャッシュされたコピーを使用する前に再検証する必要があることno-cache
を伝えています。14.9.1 キャッシュ可能とは何か:
キャッシュなし
...キャッシュは、オリジン サーバーでの再検証が成功しない限り、後続のリクエストを満たすためにレスポンスを使用してはなりません。これにより、オリジン サーバーは、クライアントのリクエストに対して古いレスポンスを返すように設定されているキャッシュによるキャッシュも防止できます。
言い換えると、キャッシュは古い応答を使用することを選択する場合があります (ただし、その場合はヘッダーを追加する必要があると思いますWarning
) が、no-cache
何があっても古い応答を使用することは許可されていません。野球の統計情報がページで生成される場合はSHOULD -revalidate 動作が必要になるかもしれませんが、電子商取引の購入に対する応答を生成した場合は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-cache
no-cache
no-store
ユーザーエージェントによって送信された場合
私は信じているshahkalpeshの回答ユーザーエージェント側に適用されます。13.2.6 複数の応答の曖昧さを解消する。
ユーザー エージェントがCache-Control: max-age=0
(別名「エンドツーエンドの再検証」) を含むリクエストを送信すると、途中の各キャッシュは、If-Not-Modified
元のサーバーに至るまでキャッシュ エントリ (たとえば、ヘッダーを含む) を再検証します。応答が 304 (変更なし) の場合、キャッシュされたエンティティを使用できます。
一方、リクエストを送信するとCache-Control: no-cache
(別名「エンドツーエンド リロード」)、再検証は行われず、サーバーは応答時にキャッシュされたコピーを使用してはなりません。