仕様を理解している限り、RFC 2616（HTTP / 1.1）で導入されたETagは、Last-Modified-Headerの後継であり、ソフトウェアアーキテクトにキャッシュ再検証プロセス。
RFC 2616によると、Cache-Validation-Headers（If-None-MatchとIf-Modified-Since）の両方が存在する場合、リソースが変更されているかどうかを確認するときに、クライアント（つまりブラウザー）はETagを使用する必要があります。RFC 2616のセクション14.26によると、If-None-Match-Headerに表示されるETagが変更され、サーバーが追加のIf-Modified-Since-Headerを無視する必要がある場合、サーバーは304NotModifiedで応答してはなりません。 、 存在する場合。提示されたETagが一致する場合、Last-Modified-Headerの日付で指定されていない限り、リクエストを実行してはなりません（MUSTNOT）。（提示されたETagが一致する場合、サーバーはGETまたはHEAD要求の場合に304 Not Modifiedで応答する必要があります...）
このセクションには、いくつかの推測の余地があります。
- 強力なETagは「毎回」変更されることになっており、リソースが変更されます。したがって、変更されていないETagとIf-Modified-Since-Headerを使用したリクエストに対して、304 Not Modifiedとして応答する必要がありますが、これは少し矛盾しています。これは、強力なETagがリソースが変更されていません。（ただし、サーバーは同じ変更されていないリソースを再度送信できるため、これはそれほど致命的ではありません。）
- ..。
... ok私がこれを書いている間、質問はこの答えに沸騰していました：
上記の（小さな）矛盾は、ETagが弱いために発生しました。弱いETagでマークされたリソースは変更されている可能性がありますが、ETagは変更されていません。したがって、弱いETagの場合、ETagが変更されていないのに、304 Not Modifiedで応答するのは間違っていますが、If-Modified-Sinceに表示される日付が一致しません。