- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Tue, 30 Oct 2012 15:40:55 -0500
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Dan Winship <dan.winship@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Got it. In the spec, http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-8.2 > Additional header fields define metadata about the selected representation, which might differ from the representation included in the message for responses to some state-changing methods So if the current representation has ETag=v1, and PUT sends a new representation to which the server assigns ETag=v2, the response to PUT may contain ETag of the old representation. (This was not in RFC2616) Except, if there's no representation before the PUT, the response must be 201, and its ETag is of the new representation. I have to say the meanings of headers are heavily overloaded. Zhong On Tue, Oct 30, 2012 at 1:21 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > On 30 October 2012 19:10, Julian Reschke <julian.reschke@gmx.de> wrote: >> On 2012-10-30 18:17, Zhong Yu wrote: >>> I don't quite understand it; can anyone give an example where the >>> selected representation is not the representation enclosed in the >>> response? >> >> >> DELETE? > > Or the more obvious one: HEAD. Or a PUT response that contains a > summary of changes, rather than an actual representation, etc...
Received on Tuesday, 30 October 2012 20:41:22 UTC