後続の 2 つのリクエストで、次の 2 つのヘッダーのどちらが変更された場合にブラウザーによってより重要視されますか: ETag または Last-Modified?
3 に答える
RFC 2616セクション13.3.4によると、HTTP 1.1クライアントはキャッシュ条件付きリクエストでETagを使用する必要があり、ETagとLast Modifiedの両方が存在する場合は、両方を使用する必要があります。ETagヘッダーは、サーバーによって明示的に弱いと宣言されていない限り、強力なバリデーターと見なされます(セクション13.3.3を参照)。一方、Last Modifiedヘッダーは、それとDateヘッダーの間に少なくともわずかな違いがない限り弱いと見なされます。ただし、サーバーはどちらも送信する必要がないことに注意してください(ただし、可能であれば、送信する必要があります)。
クライアントはヘッダーが変更されているかどうかを確認するためにヘッダーをチェックしないことに注意してください。次の条件付きリクエストでそれらを盲目的に使用します。要求されたコンテンツを送信するか、304 Not Modified応答を送信するかを評価するのは、サーバーの責任です。サーバーが1つだけを送信する場合、クライアントはその1つだけを使用します(ただし、範囲要求には強力なバリデーターのみが役立ちます)。もちろん、中間キャッシュ(キャッシュ制御ディレクティブによるキャッシュが禁止されていない限り)とサーバーがヘッダーに対してどのように機能するかについても、サーバーの裁量に委ねられています。RFCは、バリデーターに一貫性がない場合は304 Not Modifiedを返さないようにする必要があると述べていますが、ヘッダー値はサーバーによって生成されるため、かなりの余裕があります。
実際には、Chrome、FireFox、IE 7+はすべて、利用可能な場合は両方のヘッダーを送信することに気づきました。また、RFCの情報からすでに疑っていた、変更されたヘッダーを送信するときの動作もテストしました。私がテストした4つのクライアントは、ページが更新された場合、またはページが現在のプロセスによって初めて要求された場合にのみ、条件付き要求を送信しました。
「OR」式のようなものではありませんか。擬似コード:
if ETagFromServer != ETagOnClient || LastModifiedFromServer != LastModifiedOnClient
GetFromServer
else
GetFromCache
=! 正しい比較演算子です。変換によってわずかな違いが生じる可能性があるため、クライアントはサーバーから受信したリテラル文字列を保持する必要があります。「新しいほうがいい」と決めつけてはいけません。
なんで?サーバー オペレータがリソースの不適切なバージョンを元に戻す場合を考えてみましょう。元に戻したバージョンは古いですが、正しいです。
クライアントは、サーバーによって現在提供されているバージョンを使用する必要があります。同じ場合にのみ、キャッシュされたバージョンを使用できます。したがって、サーバーは「新しい」ではなく、等しいかどうかをチェックする必要があります。