Re: No validator in 200 response for conditional update

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?

Yishuai

Julian Reschke <julian.reschke@gmx.de> 于2018年11月7日周三 上午8:02写道：

> On 2018-11-07 13:53, Yishuai Li wrote:
> > 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
>