Re: No validator in 200 response for conditional update

On 2018-10-27 08:04, Yishuai Li wrote:
> I am also confused by this clause. Consider the following scenario (for 
> simplicity, the entity-tag is identical to entity, and the all requests 
> have the same target):
> 
> (1) A --> S : PUT "a" (unconditional)
> (2) S --> A : 204 No Content, ETag: "a"
> (3) A --> S : PUT "a", If-Match: "b" (not satisfied)
> (4) S --> A : 204 No Content
> (5) A --> S : PUT "a", If-Match: "b" (not satisfied)
> (6) S --> A : 204 No Content, ETag "a"
> 
> Did I understand the specification correctly that: S MUST NOT send a 
> validator in (4), but MAY do so in (6), because (5) is a duplicate of 
> (3), but (3) is not a duplicate of (1)?
> 
> Thanks,
> Yishuai Li
> ...

Ok, now I understand the question. Ignore my previous reply.

So that's an edge case of an edge case, right?

The spec says:

>    An origin server MUST NOT perform the requested method if a received
>    If-Match condition evaluates to false; instead, the origin server
>    MUST respond with either a) the 412 (Precondition Failed) status code
>    or b) one of the 2xx (Successful) status codes if the origin server
>    has verified that a state change is being requested and the final
>    state is already reflected in the current state of the target
>    resource (i.e., the change requested by the user agent has already
>    succeeded, but the user agent might not be aware of it, perhaps
>    because the prior response was lost or a compatible change was made
>    by some other user agent).  In the latter case, the origin server
>    MUST NOT send a validator header field in the response unless it can
>    verify that the request is a duplicate of an immediately prior change
>    made by the same user agent.

Note the "immediately prior change" - so no (4) did not result in a 
change, so the rule does not apply and no etag should be sent.

Best regards, Julian

Received on Monday, 29 October 2018 17:07:08 UTC