Re: Metadata about the selected representation in a PUT response

On 01.11.2012 04:45, Julian Reschke wrote:
> On 2012-10-31 16:30, Zhong Yu wrote:
>> On Wed, Oct 31, 2012 at 2:13 AM, Julian Reschke 
>> <> wrote:
>>> On 2012-10-30 21:40, Zhong Yu wrote:
>>>> Got it. In the spec,
>>>>> 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)
>>>> ...
>>> Why would it contain the old ETag?
>> According to the same section in the spec
>>> We use the term "selected representation" to refer to the the 
>>> current representation of a target resource that would have been 
>>> selected in a successful response if the same request had used the 
>>> method GET and excluded any conditional request header fields.
>> In my example, the request is
>>      PUT /resource HTTP/1.1
>> If the same request had used the method GET
>>      GET /resource HTTP/1.1
>> the current representation with ETag=v1 would have been selected.
>> Thereforev1 is the selected representation. If the response contains
>> ETag header, it is a metadata about the selected representation, 
>> i.e.
>> v1.
>> ...
> Well, that's certainly not what we *want* the spec to say.
> Roy?

Or is it?

A new Etag value would indicate that the v1 representation has changed 
ETag value - right. Same with any resource altering method (LINK, 
UNLINK, DELETE, POST, PATCH, ...). In fact when one comes to listing 
them, it is all the methods which invalidate the selected 
representation. It probably should be worded to the effect that 
invalidation must happen before selection on the representation.


Received on Thursday, 1 November 2012 00:12:19 UTC