no-cacheとmust-revalidateの違い

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-revalidateとはmax-age？

このコメントを参照してください：

http://palpapers.plynt.com/issues/2008Jul/cache-control-attributes/

キャッシュなし

このディレクティブはブラウザにページをキャッシュしないように指示しているように聞こえますが、微妙な違いがあります。RFCによると、「no-cache」ディレクティブは、キャッシュからページを提供する前にサーバーで再検証する必要があることをブラウザーに通知します。再検証は、アプリケーションが帯域幅を節約できるようにする優れた手法です。ブラウザがキャッシュしたページが変更されていない場合、サーバーはそれをブラウザに通知するだけで、ページはキャッシュから表示されます。したがって、ブラウザは（理論的には）キャッシュにページを保存しますが、サーバーで再検証した後でのみページを表示します。実際には、IEとFirefoxはno-cacheディレクティブを、ページをキャッシュしないようにブラウザーに指示するかのように扱い始めました。私たちはこの行動を約1年前から観察し始めました。

誰かがこれについてもっと公式なものを持っていますか？

更新

再検証が必要なディレクティブは、表現に対する要求の検証に失敗すると、黙って実行されない金融トランザクションなどの不正な操作が発生する可能性がある場合にのみ、サーバーで使用する必要があります。

それは今まで心に留めたことのないことです。RFCはmust-revalidateを軽く使用しないように言っています。問題は、Webサービスでは否定的な見方をして、未知のクライアントアプリにとって最悪の状態を想定する必要があることです。古いリソースは問題を引き起こす可能性があります。

そして、Last-ModifiedやETagsがないと、私が今検討した他の何かは、ブラウザがリソース全体を再びフェッチすることしかできません。ただし、ETagを使用すると、少なくともすべてのリクエストでChromeが再検証されるようです。これにより、リクエストに他のヘッダーが含まれていて、常に「常に再検証」が行われない限り、これらのディレクティブは正しく再検証できないため、これらのディレクティブはどちらも無効であるか、少なくとも名前が不適切です。

最後のポイントをもっと明確にしたいだけです。must-revalidateETagもLast-Modifiedも設定せずに含めるだけで、エージェントは、比較するためにサーバーに送信するものがないため、コンテンツを再度取得することしかできません。

ただし、私の経験的テストでは、ETagまたは変更されたヘッダーデータが応答に含まれている場合、must-revalidateヘッダーの存在に関係なく、エージェントは常に再検証を行うことが示されています。

したがって、ポイントはmust-revalidate、古くなったときに「バイパスキャッシュ」を強制することです。これは、ライフタイム/エージを設定した場合にのみ発生するため、must-revalidateエージまたは他のヘッダーのない応答に設定されている場合、実質的には次のようにno-cacheなります。応答はすぐに古くなったと見なされます。

-では、最後にギリの答えにマークを付けます！

私はそれがmust-revalidate意味することを信じています：

キャッシュの有効期限が切れると、古い応答が受け入れられるとユーザーが言っても、ユーザーに古い応答を返すことを拒否します。

がno-cache意味するのは：

must-revalidate さらに、応答がすぐに古くなるという事実。

応答が10秒間キャッシュ可能である場合、10秒後にmust-revalidate起動しますno-cacheが、must-revalidate、0秒後にします。

少なくとも、それは私の解釈です。

max-age=0, must-revalidateそして、no-cache全く同じではありません。でmust-revalidate、サーバーが再検証リクエストに応答しない場合、ブラウザ/プロキシは504エラーを返すはずです。を使用no-cacheすると、キャッシュされたコンテンツのみが表示されます。これは、おそらくユーザーに好まれます（何もないよりも古くなっている方がよい）。これがmust-revalidate重要なトランザクションのみを対象とする理由です。

ジェフリー・フォックスの解釈ではno-cache、私は、クロム52.0.2743.116メートル下の結果が示すテストしてみたno-cacheのと同じ動作を持っているmust-revalidate彼らはすべてのだろう、NOTサーバが到達不能であるときに、ローカルキャッシュを使用し、そして、彼らはすべてのタップブラウザの[戻るながら、キャッシュを使用します。 /サーバーに到達できない場合の/進むボタン。上記のように、少なくとも実装でmax-age=0, must-revalidateは、と同じだと思いますno-cache。

私は違いがあると思いmax-age=0, must-revalidateとはno-cache：

must-revalidate返された場合、クライアントはIf-Modified-Sinceリクエストを送信し、キャッシュからの応答を提供することが許可されています304 Not Modified。

このno-cache場合、クライアントは応答をキャッシュしてはならないため、を使用しないでくださいIf-Modified-Since。