Http 预期etag但未收到时的响应代码？

如果服务器希望设置ETag头，但请求中不包含它，那么服务器应该发送什么样的HTTP响应代码？ 最合适的是坏请求（400）吗？

将状态定义为“服务器理解请求，但拒绝满足请求。”

由于明确地由服务器来解释请求被拒绝的原因，因此403的主体说明“所有请求都必须包含ETag头”似乎是正确的响应

---

在该RFC中，状态400被定义为由于“语法错误”，这与接收您不喜欢其外观的请求不同。

它是条件GET吗？因为在客户端缓存的有效性无法验证的情况下，一个普通的200 OK和完整的正文对我来说似乎是完全合适的。

如果您的意思是缺少一个条件请求头字段（例如，如果没有匹配），那么答案将是状态428（请参阅）。

NB“ETag”不是HTTP请求的有效头。您可能想使用“If None Match”（如果不匹配）。实际上，我的意思是将ETag头与请求一起发送，因为它是一个补丁请求，ETag标识补丁文档。同样，“ETag”不是请求头字段。ETag由服务器分配。我现在明白了。目前的标准没有明确区分这一点。我假设ETag是一个头部，可以用来描述客户机和服务器的有效负载/消息。（也有其他人以这种方式使用ETag。参见）新草案对此更加明确。谢谢你的意见！a） 没有ETag请求头字段，因此您不能要求它；b） RFC 2616中状态代码400的描述有误导性，请参阅。@JulianReschke当前RFC对我来说似乎非常明确，除非您可以链接到另一个冲突的当前规范。您链接到的草稿似乎建议更改这些状态代码，因此400更宽，403更窄。在我看来，401和403的定义似乎重叠（401可以“拒绝”凭证，403可以“不充分”凭证），但不管怎样，它还不是一个标准。IMSoP：草案扩大了400的定义，因为它必须是所有4xx代码的超集（根据定义）。这就是说：草案是最后一次调用，因此如果您不同意草案中的内容，我建议您向IETF HTTPbis工作组提供反馈。否则，“标准”（standard）很快就会这样说。（对于“标准”的某些值）@JulianReschke在“接近标准”这一点上很公平，但附录确实将其列为一个更改，而不是一个澄清：“400（错误请求）状态代码已经放宽，因此它不限于语法错误（第6.5.1节）。”我不确定是否有任何要求x00状态更一般（例如，状态300可以被视为所有3xx代码的超集），只有某些语义附加到第一个数字（所有4xx都类似）JE42：您的错误案例没有意义，因此没有状态代码可供推荐。此外，我引用的草案是将取代RFC2616的六个规范之一，因此您需要在其他地方查找内容类型（第2部分）。我真的想在请求中发送ETag，以描述作为请求一部分发送的实体。请不要将HTTP贬低或试图发明自己的协议！如果匹配HTTP标头系列是为您尝试执行的操作而设计的，因此请使用它们。If-Match具有不同的语义。If-Match与资源本身的etag匹配-但是，我发送到资源终结点的文档具有不同的文档类型（因为它是修补程序文档），因此etag匹配在本例中没有意义。JE42-主要问题是您尚未解释您试图使用etag执行的操作；如果您解释了，我们可能会推荐其他操作