If-Unmodified-Since/If-Modified-Since 有什么意义？它们不是被 ETag 取代了吗？

Question

似乎有两种不同的方法可以使用 HTTP 标头来实现条件请求，这两种方法都可以用于缓存、范围请求、并发控制等...：

1. If-Unmodified-Since 和 If-Modified-Since, ，其中客户端发送 时间戳 的资源。
2. If-Modified 和 If-None-Modified, ，其中客户端发送一个 电子标签 资源的表示。

在这两种情况下，客户端都会发送一条有关资源的信息，这使得服务器可以确定自客户端上次看到该资源以来该资源是否已更改。然后，服务器根据客户端提供的条件标头决定是否执行请求。

我不明白为什么有两种不同的方法可用。当然，ETag 会取代时间戳，因为服务器可以很容易地选择从时间戳生成 ETag。

所以，我的问题是：

• 在哪些情况下您可能更喜欢 If-Unmodified-Since/If-Modified-Since 而不是 ETag？
• 在哪些情况下您可能需要两者？

Answer 1

我曾经思考过同样的事情，并意识到有一个非常重要的区别：日期可以订购，而 ETag 则不能。

这意味着，如果某些资源在一年前被修改过，但此后就再也没有修改过，我们就知道这一点。然后我们可以正确回答去年任意日期的 If-Unmodified-Since 请求，并同意肯定......自该日期以来，它一直没有被修改。

Etag 仅在身份方面具有可比性。要么相同，要么不同。如果您拥有与上述相同的资源，并且在这一年中，文档根目录已移动到新的磁盘和文件系统，为所有文件提供新的 inode，但保留修改日期。有人根据文件的索引节点号建立了 ETag。那么如果没有过去仍然可以的 ETag 日志，我们就不能说旧的 ETag 仍然可以。

所以我不认为它们会取代另一个。它们适用于不同的情况。您可以轻松获取要提供服务的页面中所有数据的上次修改日期，也可以轻松获取您将提供服务的内容的 ETag。

如果您有一个包含来自大量数据库查找的数据的动态网页，则可能很难在不使数据库包含大量修改日期的情况下判断上次修改日期是什么。但您始终可以对渲染页面的结果进行 md5 校验和。

当支持这些缓存协议时，我肯定只支持其中一种，而不是同时支持两种。

Answer 2

有一个比较大的区别：如果我过去已经向服务器请求过 ETag，我只能使用 ETag。时间戳，OTOH，我可以边走边补。

Answer 3

原因很简单：向后兼容性。