为什么同一资源的不同表现需要不同的Etag？

Question

我了解在乐观并发控制中使用ETags（例如在RESTful架构中的应用），并且我已经阅读过ETags应该针对同一资源的不同表示形式进行区分的理念。但是为什么需要这样做呢？

归根结底，我们不是只关心资源是否已更改，以便我们能够处理并发修改吗？我甚至很难想象在不更改资源本身的情况下资源的表示会发生变化，因此我显然缺乏一些基本的理解。

- erturne

Answer 1

这是一个很好的问题，我认为这是一些争议的问题。

我认为大多数人会说ETag不仅代表资源版本，也代表内容类型。这对于基于内容类型、语言等缓存响应来说是有意义的。

请查看以下链接:

• 维基百科关于强ETag和弱ETag的文章部分:http://en.wikipedia.org/wiki/HTTP_ETag#Strong_and_weak_validation
• 关于内容编码和ETag的信息性讨论：http://www.gossamer-threads.com/lists/apache/dev/339577

- anon

Answer 2

当您布置事实或阅读HTTP&HTTPbis规范时，这不是可以争论的问题。

ETag是一种缓存和并发控制的手段。弱ETags仅仅是一种贫民窟缓存的手段。

就缓存而言（GET）- uri + content-type + etag 可以帮助您通过不仅仅是使用 304 状态码进行响应而不是有效载荷来节省带宽。

就并发控制而言（POST；PUT；PATCH）- 基于URI + content-type + bit-exact响应有效载荷计算ETag是仓促的。为什么呢？

• 如果您基于整个对象计算ETag，则响应有效载荷的超集（即，有效载荷提供a+b，但对象实际上是a+b+c）进行PATCH将最终失败，因为ETag已更改...您刷新...您获得相同的数据但不同的ETag...您使用新的ETag重试PATCH，现在它能够工作。失败了
• 如果您基于有效载荷的子集计算ETag，您实际上正在迫使用户无法透明地控制不安全调用的条件。即使与该ETag关联的数据已经更改，PATCH也将成功，这显然不是HTTP请求的本意。 失败了

条件请求应该被视为具有类似于“鉴于我的世界观仍然是相同的，然后执行请求。否则失败”的语义。我的世界观由过去的响应（URI + headers + payload）组成。

- Andrei Neculau