後続の2つのリクエストの場合、次の2つのヘッダーのどちらがブラウザによってより重要視され、そのうちの1つを変更する必要があります:ETagまたはLast-Modified?
後続の2つのリクエストの場合、次の2つのヘッダーのどちらがブラウザによってより重要視され、そのうちの1つを変更する必要があります:ETagまたはLast-Modified?
回答:
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
=!正しい比較演算子です。変換によってわずかな違いが生じる可能性があるため、クライアントはサーバーから受信したリテラル文字列を保持する必要があります。「新しい方が良い」とは限りません。
どうして?サーバーオペレーターがリソースの不良バージョンを元に戻す場合を考えてみます。戻されたバージョンは古いですが、正しいです。
クライアントは、サーバーによって現在提供されているバージョンを使用する必要があります。キャッシュされたバージョンは、同じ場合にのみ使用できます。したがって、サーバーは「新しい」ではなく、同等性をチェックする必要があります。