If-Unmodified-Since/If-Modified-Since 的意义何在？他们不是被ETags取代了吗？答案

【问题标题】：What is the point of If-Unmodified-Since/If-Modified-Since? Aren't they superseded by ETags?If-Unmodified-Since/If-Modified-Since 的意义何在？他们不是被ETags取代了吗？
【发布时间】：2011-01-08 18:25:24
【问题描述】：

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

If-Unmodified-Since 和 If-Modified-Since，客户端发送资源的时间戳。
If-Modified 和 If-None-Modified，客户端发送资源的 ETag 表示。

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

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

所以，我的问题是：

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

【问题讨论】：

虽然可能是相切的，但还有另一种方法可以发出条件请求：If-Range。它可以使用 ETage 或时间戳。

标签： http rest http-headers etag if-modified-since

【解决方案1】：

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

【讨论】：

【解决方案2】：

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

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

Etag 仅在身份方面具有可比性。要么相同，要么不同。如果您拥有与上述相同的资源，并且在这一年中 docroot 已移动到新磁盘和文件系统，则为所有文件提供新的 inode，但保留修改日期。有人将 ETags 基于文件的 inode 号。那么我们不能说旧的 ETag 仍然可以，没有过去仍然可以的 ETag 日志。

所以我不认为它们会过时。它们适用于不同的情况。您可以轻松获取您将要服务的页面中所有数据的 Last-Modified 日期，或者您可以轻松获取您将要服务的内容的 ETag。

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

当支持这些缓存协议时，我肯定只选择其中一个，而不是两者。

【讨论】：

赞成，这是一个非常好的观点。但是，ETags 是否只在身份方面具有可比性？这不取决于服务器用作 Etag 值的内容吗？例如，据我了解，服务器可以选择使用原始时间戳作为某些资源的 ETag。这样，将为这些资源订购 ETag。因此，如果 ETag 可以有效地成为时间戳，那么一对仅适用于时间戳的单独标头有什么意义？
您需要在等式中添加代理。如果您的 Etag 值具有语义含义，那么它们现在就没有意义了。

【解决方案3】：

原因很简单：向后兼容。

【讨论】：

好的。您是说 If-Unmodified-Since 和 If-Modified-Since 是遗留的，因此在您可以完全控制客户端发送的标头和服务器处理的标头的情况下，您应该只使用 ETags？
对于验证和/或条件请求，ETag 是可行的方法。但是，Last-Modified 标头在条件请求之外具有语义含义，如果您可以控制所有内容，也应该发送。见w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.4