我应该在我的 ETag 中包含媒体类型吗？答案

【问题标题】：Should I include media type in my ETag?我应该在我的 ETag 中包含媒体类型吗？
【发布时间】：2011-12-19 21:30:12
【问题描述】：

向 HTTP 响应添加 ETag 时，是否应该包含媒体类型？当然，我知道 ETag 是不透明的，但这里有一个例子：

显然，简单地返回 304 是不正确的，但我的问题是，在第二个请求中，我是否希望 ETags 匹配但没有基于 Accept 标头（或内容标头）的缓存。此外，缓存是否有可能来自同一个 URI 的两种表示形式，或者每次切换 Content-Type 时总是有无效的缓存？

【问题讨论】：

【解决方案1】：

不同的表示需要不同的实体标签。

【讨论】：

【解决方案2】：

我相信您可以为不同的表示发送相同的 Etag。只要您指定，它们应该在您的响应中被缓存为两个不同的实体。这可以使用 Vary 字段来完成，如 RFC 2616 中所述

14.44 变化

Vary 字段值表示请求标头字段的集合完全确定，当响应是新鲜的时，缓存是否允许使用响应来回复后续请求无需重新验证。对于不可缓存或陈旧的响应，Vary 字段值向用户代理建议使用的标准选择表示。

使用Vary: Accept 应该是合适的。

【讨论】：

请不要引用 RFC 2616，当相应的工作组承认它不够清楚时，并且已经在回复中发布了指向澄清的指针。
我觉得这有点不公平。当我开始理解对问题的回复时，描述了糟糕的服务器实现如何产生缓存问题，而不是规范本身的缺陷。我认为您的判断与其他人一致认为适当使用标题 Vary stackoverflow.com/questions/1975416/… 的做法背道而驰。置顶的答案和我的回复一样，好评。
Cleric：如果您认为新的 HTTP 规范是错误的，那么我鼓励您到 HTTPbis WG 邮件列表来讨论这个案例。文件接近 Last Call，所以现在是时候了。 BTW：我同意你需要使用 Vary；我不同意的是，这就足够了；因此，您链接到的另一个答案是无关紧要的（因为那里甚至没有提到 etags）
我很确定我并没有争辩说新的 HTTP 规范是错误的，但我很想就这个主题发表一些意见。我很遗憾没有。但我的立场是正确的，我提出的链接根本没有谈论 Etags。我将不得不对 Etags 的解释方式以及为什么 Vary 不够用做一些进一步的研究。如果您有关于该主题的链接，我将不胜感激。
根据tools.ietf.org/html/rfc7232#section-2.1，这是不正确的。您所描述的是“弱验证器”：“同样，如果一个验证器同时由给定资源的两个或多个表示共享，则验证器是弱的，除非这些表示具有相同的表示数据。”