RE: No validator in 200 response for conditional update

Yishuai summarized the issue correctly.

> From: Yishuai Li <yishuai@cis.upenn.edu> November 7, 2018 5:19 AM
> I think that sending etag is not a huge work itself, if the server is to implement etag at all. 
> The difficulty is determining whether to send it or not, because sending etag in 2.2.2 is violating the specification. Is there a specific reason for this restriction? If not, shall we remove such constraint?

Exactly.
Sending ETag back all the time is a no-brainer.
There is no additional work here at all since we do send ETag with regular 2xx responses already in state update happy path.
But deciding when to send it and when not to send calls for quite a lot of dev work and previous request tracking infra (ongoing runtime cost).
And we really-really don't want to do this.
But spec says we MUST do this and doesn't explain/hint why.
May be the reason is valid (like security), but we need to know it so we can justify our investment.

> Julian Reschke <mailto:julian.reschke@gmx.de> 于2018年11月7日周三 上午8:02写道：
> > As you have said, we are talking about an "edge case of an edge case":
> > 1. If precondition is satisfied, then process; otherwise
> > 2.1. Respond with 412 Precondition Failed, or
> > 2.2. If the proposed change has been reflected, MAY respond with 2xx 
> > (Success), and
> > 2.2.1. If current request is a duplicate of an immediately prior change 
> > made by the same user agent, MAY send etag, otherwise
> > 2.2.2. MUST NOT include etag in the response.
> > Why do we specify 2.2.1 and 2.2.2? I believe Vladimir has some traffic 
> > pattern that match 2.2, where 2xx Success is more informative than 412 
> > Precondition failed, but determining whether to send an etag or not 
> > leads to extra development effort.
> > Yishuai

> Well, sending the etag saves work on the client (because it doesn't have 
> to refetch the etag if it's interested in it).
> On the other hand it's more work on the server. The server implementer 
> can choose what's better...
> Best regards, Julian

Received on Tuesday, 13 November 2018 22:52:43 UTC