我应该在 ETag 中包含媒体类型吗？
将 ETag 添加到 HTTP 响应时，是否应该包含媒体类型？当然，我知道 ETag 是不透明的，但这里有一个例子：
- 假设我有一个客户端请求 application/json 中的 Person。我查找它并创建我的 ETag 并发回此人的 JSON 表示形式
- 现在，同一客户端在同一 URI 处对同一个人（尚未修改）发出另一个请求，但希望将其放在 application/xml 中。
显然，简单地返回 304 是不正确的，但我的问题是，在第二个请求中，我是否期望 ETag 匹配，但基于 Accept 标头（或内容标头）没有缓存。另外，缓存是否有可能具有来自同一 URI 的两种表示形式，或者每次您的 Content-Type 切换时都会有一个无效的缓存？
When adding an ETag to an HTTP response, should I include the media type? Of course, I understand that the ETag is opaque, but here is an example:
- Say I have a client that requests a Person in application/json. I look it up and create my ETag and send back the JSON representation of the person
- Now the same client makes another request for the same person (which has not been modified) at the same URI but wants it in application/xml.
Clearly it is incorrect to simply return a 304, but my question is, in the second request, would I expect the ETags to match but no cache based on the Accept header (or the content header). Also, is it even possible that the cache will have two representations from the same URI, or would you always have an invalid cache every time your Content-Type switched?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我相信您可以为不同的表示发送相同的 Etag。只要您指定，它们就应该在您的响应中缓存为两个不同的实体。
这可以使用 Vary 字段来完成，如 RFC 2616
http://www.ietf.org 中所述/rfc/rfc2616.txt
使用
Vary: Accept应该是合适的。I believe that you can send the same Etag for different representations. As long as you specify, that they should be cached as two different entities, in your response.
This can be done using the Vary field, as described in RFC 2616
http://www.ietf.org/rfc/rfc2616.txt
Using a
Vary: Acceptshould be appropriate.不同的表示需要不同的实体标签。
请参阅http://trac.tools.ietf.org/wg/httpbis/ trac/ticket/39。
Different representations need different entity tags.
See http://trac.tools.ietf.org/wg/httpbis/trac/ticket/39.