如果出现 412“前提条件失败”，是否可以返回实体的最新版本？
当使用“If-Match”标头执行 PUT 或 DELETE 时，如果客户端发送的 ETag 指示过时，我想返回整个最新实体（包括其新的 ETag 在 HTTP 标头中），因此客户端不必执行另一次 GET 往返，否则他们肯定会这样做 - 在我的用例中，至少他们在可能 100% 的情况下都会这样做。
我在 412 的文档中没有看到任何支持或反对的内容： http://www.w3.org/Protocols/rfc2616/rfc2616 -sec10.html#sec10.4.13
然后查看状态码 409，一般来说，对 4xx 错误的响应正文执行任何操作似乎都不是问题： http://www.w3.org/Protocols/rfc2616/rfc2616 -sec10.html#sec10.4.10
那么，有什么（特别是在 HTTP 规范中）说话吗？反对返回完整的最新实体及其 ETag？
When doing a PUT or DELETE with an "If-Match" header, in case the ETag sent by a client indicates staleness, rather than just returning a 412, I'd like to return the whole up-to-date entity (including its new ETag in the HTTP header), so the client does not have to perform another GET round trip, which they otherwise would certainly do - in my use-case at least they'd do in probably 100% of the cases.
I don't see anything for or against it in the docs for 412:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.13
And looking at, say, status code 409, it doesn't seem to be a problem in general to do whatever one likes with the response body of a 4xx error:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.10
So, does anything (especially in the HTTP specs) speak against return the full up-to-date entity and its ETag?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
应该没问题：
来源：http://www.w3.org/Protocols/rfc2616 /rfc2616-sec4.html#sec4.3
Should be fine:
Source: http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.3
有什么要求？使用 If-None-Match 获取？在这种情况下，服务器无论如何都不应该返回 412。
对于 PUT、DELETE，您当然可以返回当前表示。对于大型代表，对于不需要它的客户来说会很不方便。
您可能还想使用 Location 标头将有效负载标记为资源的表示；请参阅http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-16.html#identifying.response.linked.with.representation。
What is the request? GET with If-None-Match? In that case, the server isn't supposed to return 412 anyway.
For PUT, DELETE, you certainly can return the current representation. For large representations, it will be inconvenient for clients that don't need it though.
You may also want to label the payload as representation of the resource by using the Location header; see http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-16.html#identifying.response.associated.with.representation.