RFC 2616 から
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1
キャッシュなし
no-cache ディレクティブでフィールド名が指定されていない場合、オリジン サーバーでの再検証が成功しない限り、キャッシュは後続の要求を満たすために応答を使用してはなりません (MUST NOT)。これにより、オリジン サーバーは、クライアントの要求に対して古い応答を返すように構成されたキャッシュによってもキャッシュを防止できます。
そのため、エージェントはすべての応答を再検証するように指示されます。
これに比べて
再検証が必要
must-revalidate ディレクティブがキャッシュによって受信された応答に存在する場合、そのキャッシュは、元のサーバーで最初に再検証せずに、エントリが古くなった後、後続の要求に応答するためにエントリを使用してはなりません (MUST NOT)。
そのため、エージェントに古い応答を再検証するように指示します。
特に に関してno-cache、これはユーザーエージェントが実際に経験的にこのディレクティブを扱う方法ですか?
とがあるno-cache場合のポイントは何ですか?must-revalidatemax-age
このコメントを参照してください。
http://palpapers.plynt.com/issues/2008Jul/cache-control-attributes/
キャッシュなし
このディレクティブは、ブラウザーにページをキャッシュしないように指示しているように聞こえますが、微妙な違いがあります。RFC によると、「no-cache」ディレクティブは、キャッシュからページを提供する前に、サーバーで再検証する必要があることをブラウザに伝えます。再検証は、アプリケーションが帯域幅を節約できるようにする優れた手法です。ブラウザーがキャッシュしたページが変更されていない場合、サーバーはそのことをブラウザーに通知するだけで、ページはキャッシュから表示されます。したがって、ブラウザは（少なくとも理論上は）ページをキャッシュに保存しますが、サーバーで再検証した後にのみ表示します。実際には、IE と Firefox は、no-cache ディレクティブを、ブラウザーにページをキャッシュしないように指示しているかのように扱い始めています。私たちは約 1 年前にこの動作を観察し始めました。
誰かがこれについてもっと公式なものを持っていますか?
アップデート
サーバーは、revalidate ディレクティブを使用する必要があります。これは、表現に対する要求の検証に失敗すると、金融取引が黙って実行されないなど、不正な操作が発生する可能性がある場合に限られます。
それは私が今まで心に留めたことのないことです。RFC は、must-revalidate を安易に使用しないように言っています。問題は、Web サービスでは、否定的な見方をして、未知のクライアント アプリの最悪の事態を想定する必要があるということです。古いリソースは、問題を引き起こす可能性があります。
Last-Modified または ETags がなければ、ブラウザはリソース全体を再度取得することしかできません。ただし、ETag を使用すると、少なくともリクエストごとに Chrome が再検証されるように見えることがわかりました。いずれにせよ、「常に再検証」を引き起こす他のヘッダーがリクエストに含まれていない限り、これらのディレクティブは適切に再検証できないため、これらのディレクティブは両方とも意味がないか、少なくとも不適切な名前になります。
最後の点を明確にしたいだけです。ETag も Last-Modified も含めずに設定must-revalidateするだけで、比較のためにサーバーに送信するものが何もないため、エージェントはコンテンツを再度取得することしかできません。
ただし、私の経験的なテストでは、ETag または変更されたヘッダー データが応答に含まれている場合、ヘッダーの存在に関係なく、エージェントは常に再検証することが示されていmust-revalidateます。
したがって、ポイントは、有効期限must-revalidate/年齢を設定した場合にのみ発生する可能性がある、古くなったときに「キャッシュをバイパス」することです。応答はすぐに古くなったと見なされます。must-revalidateno-cache
-- では、ギリの回答を最後にマークします。