网络上有很多文章详细说明了为什么您可能不想为 ETag 使用 Apache 的默认 inode-mtime-size 格式。
但是我还没有读到任何可能促使将 inode 包含在 Apache 中的内容。从表面上看，它似乎只有在需要能够区分同一资源的八位字节传真时才有用，但这肯定与 ETags 的目的背道而驰。
Apache 的作者并不以他们对互联网标准的草率处理而闻名，所以我觉得我一定遗漏了一些东西。谁能详细说明？
编辑：我在这里而不是在 ServerFault.com 上问这个问题，因为我正在实现一个 Web 服务器而不是管理一个。要详细了解为什么这是一个坏主意，请参见此处或此处。所有此类文章都推荐相同的东西：从您的 etag 中删除 inode。问题是，他们在那里有什么好处吗？
似乎人们很容易通过对常见情况的错误猜测，或者默认情况下更喜欢正确性而不是性能来做这种事情，只要有一丝怀疑。
请允许我编造一个故事，讲述它可能是如何发展的：
出于性能原因，他们很早就决定对内容进行哈希/校验和是一个坏主意。“谁知道文件可能有多大？我们不能一直重新计算这些......”所以他们决定大小和日期让你非常接近。
“但是等等，”A 说，“没有什么能保证你不会遇到文件大小冲突。事实上，在某些情况下，比如固件二进制文件，文件大小总是相同的，完全有可能有几个是相同的。同时从开发机器上传，因此这些不足以区分不同的内容。”
人员 B：“嗯，好点子。我们需要一些与文件内容有内在联系的东西。再加上修改的时间，可以确定它是否是相同内容的东西。”
人员 A：“inode 呢？现在，即使他们重命名文件（例如，他们可能将“推荐”更改为不同的文件），默认的 etag 也可以正常工作！”
人 B：“我不知道，inode 似乎有点危险。”
人A：“嗯，什么会更好？”
B：“是的，问得好。我想我想不出它具体有什么问题，我只是有一种普遍的不好的感觉。”
人A：“但至少它保证你会下载一个新的，如果它被改变了。最糟糕的是你下载的次数超过了你需要的次数，任何知道他们不必担心它的人都可以转过来它关了。”
B：“是的，这很有道理。在大多数情况下可能没问题，而且似乎比简单的替代方案要好。”
免责声明：我对 Apache 实施者的想法一无所知。这一切都只是徒劳的猜测，并试图编造一个似是而非的故事。但我确实经常看到这种事情发生。
您永远不知道您没有想到的是什么（在这种情况下，服务相同文件的冗余负载平衡服务器比不必担心大小+时间冲突更为典型）。负载均衡器不是 apache 的一部分，因此更容易进行这种疏忽。
另外，这里的失败模式是你没有完全有效地使用缓存（不是你得到了错误的数据），这可以说是更好，虽然很烦人。这表明即使他们确实想到了这一点，他们也可以合理地假设有足够兴趣设置负载均衡器的人也可以调整他们的配置细节。
PS：这与标准无关。没有指定如何计算 etag，只是应该足以判断内容是否已更改，并且概率很高。