ETagにApacheのデフォルトのinode-mtime-size形式を使用したくない理由を詳しく説明している記事がWeb上にたくさんあります。
しかし、そもそもApacheにiノードを含める動機となった可能性のあるものについてはまだ何も読んでいません。一見すると、同じリソースのオクテットごとのファクシミリを区別できる必要がある場合にのみ有用であるように見えますが、これは確かにETagの目的そのものに反しています。
Apacheの作者は、インターネット標準の扱いがずさんなことで知られていないので、何かが足りないのではないかと思います。誰でも詳しく説明できますか？
編集：私はWebサーバーを管理するのではなく実装しているので、ServerFault.comではなくここでこれを尋ねます。なぜそれが悪い考えであるかについてもっと読むために、例えばここかここを見てください。そのような記事はすべて同じことを推奨しています：etagからiノードを削除します。問題は、彼らがそこにいることに何か利点があるのかということです。
よくあるケースを誤って推測したり、デフォルトでパフォーマンスよりも正確性を優先したりすることで、わずかな疑いがある場合はいつでも簡単に実行できるようなことのように思えます。
それがどのように進んだかについての話を作ってみましょう：
彼らは、コンテンツのハッシュ/チェックサムがパフォーマンス上の理由から悪い考えであると早い段階で判断します。「ファイルのサイズは誰にもわかりません。常に再計算することはできません...」そこで、サイズと日付を決定することでかなり近い結果が得られます。
「でも待ってください」と A さんは言います。開発マシンから同時にアップロードされるため、これらは異なるコンテンツを区別するのに十分ではありません。」
人物 B: 「うーん、いいですね。ファイルの内容に本質的に関連付けられているものが必要です。修正された時刻と合わせて、内容が同じかどうかを確実に判断できるものが必要です。」
Aさん：「iノードはどうですか？ファイルの名前を変更しても（たとえば、「推奨」を別のファイルに変更するなど）、デフォルトのetagは正常に機能します。」
Bさん：「わかんないけど、inodeちょっと危なそう」
Aさん：「さて、どれがいい？」
人物 B: 「ええ、良い質問です。具体的にどこが悪いのか、私には思いつかないと思います。全体的に嫌な予感がするだけです。」
人物 A: 「しかし、少なくとも、変更された場合に新しいものをダウンロードすることが保証されます。最悪の事態は、必要以上に頻繁にダウンロードすることです。心配する必要がないことを知っている人は、それをオフにします。
人物 B: 「ええ、それは理にかなっています。ほとんどの場合はおそらく問題なく、簡単な代替手段よりも優れているようです。」
免責事項: Apache の実装者が何を考えていたのかについて、私は内部の知識を持っていません。これはすべて手探りの推測であり、もっともらしい話をでっち上げようとしています。しかし、私は確かに、この種のことが頻繁に起こるのを見てきました。
考えもしなかったことが何であったかは決してわかりません (この場合、サイズと時間の衝突を心配する必要があるよりも、同じファイルを提供する冗長な負荷分散サーバーの方が一般的でした)。ロード バランサーは apache の一部ではないため、このような見落としが発生しやすくなっています。
さらに、ここでの失敗モードは、キャッシュを完全に効率的に使用しなかったことです (間違ったデータを取得したというわけではありません)。これは、彼らがそれを考えたとしても、ロードバランサーをセットアップするのに十分な関心を持っている誰かが構成の詳細を調整しても問題ないと合理的に推測できることを示唆しています.
PS: それは標準に関するものではありません。etag の計算方法を指定するものは何もありませんが、内容が変更されたかどうかを高い確率で判断するのに十分なはずです。