優先順位は何ですか：ETagまたはLast-Modified HTTPヘッダー？

Question

次の2つのリクエストの場合、次の2つのヘッダーのいずれかが変更されると、ブラウザーによってさらに重視されます：ETagまたはLast-Modified？

Answer 1

「OR」表現のようなものではありませんか？擬似コードで：

if ETagFromServer != ETagOnClient || LastModifiedFromServer != LastModifiedOnClient 
    GetFromServer 
else 
    GetFromCache 

Answer 2

よれセクション13.3.4 RFC 2616に、HTTP 1.1クライアントは、キャッシュ条件付き要求でのETagを使用しなければなりません、そして改変Etag及び最終の両方が存在する場合、それは両方を使用すべきです。サーバによって明示的に宣言されない限り、ETagヘッダは強力なバリデータ（13.3.3節参照）と見なされますが、Last ModifiedヘッダはDateヘッダとの間に少なくともわずかな差がない限り弱いとみなされます。ただし、サーバーはどちらかを送信する必要はありません（ただし可能な場合はSHOULD）。

クライアントは、ヘッダーが変更されているかどうかを確認しません。それは次の条件付き要求で盲目的に使うだけです。要求されたコンテンツを送信するか304 Not Modified応答を送信するかを評価するのはサーバー次第です。サーバーが1つのみを送信する場合、クライアントはその1つだけを使用します（しかし、強力なバリデーターだけが範囲要求に役立ちます）。もちろん、中間キャッシュの裁量にもなります（Cache Controlディレクティブでキャッシュできない限り）。また、サーバーがヘッダーにどのように作用するかについても判断できます。 RFCは、バリデーターが矛盾している場合は304 Not Modifiedを返してはいけませんが、ヘッダー値はサーバーによって生成されるため、余裕があります。

実際には、Chrome、FireFox、およびIE 7以上のすべてが両方のヘッダーを送信していることに気がつきました。 RFCの情報からすでに疑わしかった変更されたヘッダーを送信するときの動作もテストしました。私がテストした4つのクライアントは、ページがリフレッシュされた場合、またはページが現在のプロセスによって初めて要求された場合に限り、条件付き要求を送信しました。

Answer 3

=！正しい比較演算子です。コンバージョンは小さな違いを生む可能性があるため、クライアントはサーバーから受け取ったリテラル文字列を保持する必要があります。あなたは「もっと新しい方が良い」と考えることはできません。

なぜですか？サーバオペレータが悪いバージョンのリソースを元に戻す場合を考えてみましょう。元に戻ったバージョンはOLDERですが、正しいです。

クライアントは、現在サーバーによって提供されているバージョンを使用する必要があります。キャッシュされたバージョンは、同じ場合にのみ使用できます。したがって、サーバーは「新しい」ではなく、同等性をチェックする必要があります。