Subject: No validator in 200 response for conditional update

From: Vladimir Lashchev <[email-masked]>
Date: Fri, 26 Oct 2018 15:52:21 -0700 (PDT)

Hello,

RFC7232 in https://tools.ietf.org/html/rfc7232#section-3.1 has the following clause:
```
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
```
It doesn't really explain what security or performance considerations are leading to such a requirement and seems to favor idempotent updates coming from the same user agent.
Sending validator (ETag) to all requestors seems to be a simpler and better choice.
Could somebody please clarify why we need to this as suggested in RFC?

Thanks,
Vladimir Lashchev

---

From: Julian Reschke <[email-masked]>
Date: Sat, 27 Oct 2018 11:38:38 +0200

FWIW, "in the latter case" is about..:

>  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)

...so that's an edge case already.

Best regards, Julian

---

From: Yishuai Li <[email-masked]>
Date: Sat, 27 Oct 2018 02:04:34 -0400

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

Vladimir Lashchev <[email-masked]> 于2018年10月27日周六 上午1:07写道：

> 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
> ```
> It doesn't really explain what security or performance considerations are
> leading to such a requirement and seems to favor idempotent updates coming
> from the same user agent.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 29 Oct 2018 14:05:19 +0100

On 2018-10-27 08:04, Yishuai Li wrote:
 > ...

Why would step (4) result in a 204? Should be Precondition Failed, no?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 29 Oct 2018 18:06:07 +0100

On 2018-10-27 08:04, Yishuai Li wrote:
> 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
>    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