- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 7 Nov 2018 14:01:50 +0100
- To: Yishuai Li <yishuai@cis.upenn.edu>
- Cc: vladimir.lashchev@oracle.com, ietf-http-wg@w3.org
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
Received on Wednesday, 7 November 2018 13:02:31 UTC