http リクエストの一部としてファイルが返されるとします。そのファイルの ETag を作成する正しい方法は何ですか?
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19
私はそれがいくつかの方法で行われるのを見てきました
答えは、場合によるということです。
Etag には、弱いものと強いものの 2 種類があります。弱いものを使用すると、特定の条件付き操作を実行できますが、ほとんどの場合、強力な etag が必要になります。
強力な etag の唯一の制限は、何らかの理由で表現が変更された場合、etag も変更されるということです。ファイルの場合はハッシュを生成できますが、それを生成している間、エンティティをメモリ内に保持する必要があります。あるいは、単純にコンテンツをストリーミングし、Etag を後続の http ヘッダーとして追加することもできますが、現在、その (非常に便利であまり愛されていない) 機能をサポートしているサーバーはほとんどありません。
ティックの解像度は低く、内容が異なっていても、同じファイルに 2 つの連続した書き込みを行うと、ティックの数が同じになる可能性があります。その段階で、etag が強力で泥水の中にいる場合、etag は無効になります。Last-Modified と同じ問題です。ほとんどの HTTP サーバーがこれに対処する方法は、複数のプロパティ、別名タイムスタンプ、サイズ、およびおそらくファイル オブジェクト ID (Apache の inode、おそらく NT のオブジェクト ストア エントリへのフル パスを追加し、 IIS はその値にもカウンターを追加するため、何かが変更された場合に備えて、サーバー上の 2 つの構成変更によって異なる etag が生成されます)。
ある種のデータベースを使用する場合、id + バージョンは強力な etag である必要があります (繰り返しますが、取得したコンテンツが、ルートがバージョンを変更することなく、それぞれが個別に変更される可能性のある複数のものの集合体ではない場合)。
したがって、それを計算する方法は実際にはシナリオに依存し、特に他の多くの理由で非常に便利な機能であるため、書き込み時にファイルのハッシュを保持することがおそらく最も役立ちます (サービスを開始する前に)。
意味的には、コンテンツが変更されると ETag が変更されます。
したがって、ハッシュは適切に見えます...しかし、ETagは、異なるURLおよび/または重複ファイルの異なるタイムスタンプでも一意である必要があります...安全のために、ファイルをハッシュし、それを最後の変更のタイムスタンプと連結し、 URLとハッシュをもう一度...