(Apache) i ノードを ETag に入れる目的は何ですか?

Question

ウェブ上には、その理由を詳しく説明した記事がたくさんあります。 ない ETag に Apache のデフォルトの inode-mtime-size 形式を使用したいと考えています。

しかし、そもそも Apache に i ノードを含める動機となったものについては、まだ何も読んでいません。一見すると、同じリソースのオクテットごとのファクシミリを区別できる必要がある場合にのみ役立つように見えますが、これは確実に ETag の目的そのものに反しています。

Apache の作成者はインターネット標準の扱いがずさんであることで知られているので、私には何かが欠けているに違いないと感じています。誰か詳しく説明してもらえますか？

編集： 私は Web サーバーを管理しているのではなく実装しているため、ServerFault.com ではなくここで質問しています。それが悪い考えである理由について詳しくは、例を参照してください。 ここ または ここ. 。このような記事はすべて同じことを推奨しています。etag から i ノードを削除します。問題は、彼らがそこにいることに何かメリットがあるのか​​ということです。

Answer 1

これは、一般的なケースについて間違った推測をしたり、少しでも疑問がある場合にデフォルトでパフォーマンスよりも正確さを優先したりすることで、簡単に実行できる類のことのように思えます。

それがどのように起こったかについての話を作らせてください。

彼らは、コンテンツのハッシュ/チェックサムはパフォーマンス上の理由から悪い考えであると早い段階で判断します。「ファイルがどのくらいの大きさになるか誰にもわかりません。それらを常に再計算することはできません...」そこで、サイズと日付を決定して、ほぼそれに近いものを決定します。

「でも、ちょっと待ってください。ファイル サイズの衝突がないという保証は何もありません。実際、ファームウェア バイナリなど、ファイル サイズが常に同じ場合があり、複数のファイルが開発マシンから同時にアップロードされる可能性は十分にあります。そのため、これらは異なるコンテンツを区別するのに十分ではありません。 」

人物B:「うーん、いい指摘だね。ファイルの内容に本質的に結び付けられたものが必要です。変更された時刻と組み合わせることで、同じ内容かどうかを確実に判断できるもの。」

ペルソナ：「iノードはどうですか？これで、ファイル名を変更したとしても (たとえば、「推奨」を別のファイルに変更した可能性があります)、デフォルトの etag が正常に機能します。

人物B:「わかりませんが、inode は少し危険なようです。」

ペルソナ：「さて、何が良いでしょうか？」

人物B:「はい、いい質問ですね。具体的に何が問題なのかは考えられないんですが、ただ全体的に嫌な予感がするんです。」

ペルソナ：「しかし、少なくとも、変更された場合には新しいものをダウンロードすることが保証されます。最悪の場合は、必要以上にダウンロードが頻繁に行われることですが、心配する必要がないとわかっている人は、ダウンロードをオフにすることができます。」

人物B:「ええ、それは理にかなっています。おそらくほとんどの場合にはこれで問題なく、簡単な代替案よりも優れているようです。」

免責事項:Apache の実装者が何を考えていたのかについて、私は内部の知識を持っていません。これはすべて、ただの手作業による推測であり、もっともらしい話をでっち上げようとしているだけです。しかし、私はこの種のことが頻繁に起こるのを確かに見てきました。

何が思いつかなかったのかはわかりません (この場合、サイズと時間の衝突を心配するよりも、負荷分散された冗長サーバーで同じファイルを処理する方が一般的でした)。ロード バランサは Apache の一部ではないため、このような見落としが起こりやすくなります。

さらに、ここでの失敗モードは、キャッシュを完全に効率的に使用していないことです (間違ったデータを取得したわけではありません)。迷惑ではありますが、おそらくその方が良いでしょう。これは、たとえそれを考えたとしても、ロード バランサーのセットアップに十分な関心を持っている人なら、構成の詳細を調整しても問題ないと合理的に想定できることを示唆しています。

追伸：それは規格の話ではありません。etag の計算方法については何も指定されていません。コンテンツが変更されたかどうかを高い確率で判断できれば十分です。