- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 27 Feb 2012 16:15:07 +0100
- To: Mike Kelly <mikekelly321@gmail.com>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2012-02-27 15:18, Mike Kelly wrote: > Hi all, > > HTTPbis has amended the semantics of PUT to be unambiguous in its "clarified", not "amended". The point being: PUT never allowed partial updates. Because people used if for partial updates anyway, we made that part clearer. > prevention of partial updates. I cannot understand the rationale > behind this change, and I have a couple of questions for the group: > > - Given that 2616 was ambiguous, is it acknowledged that this > represents a breaking change to any existing infrastructure that > relies on PUT requests that are permitted to be partial? I don't think it ever was ambiguous. "The PUT method requests that the enclosed entity be stored under the supplied Request-URI." > - How is it foreseen that this over-specification of PUT will benefit > the web? i.e. what infrastructure will be able to exist once all PUT > requests are unambiguously non-partial? I don't think it's an over-specification. And even if it was, it's not new. > - Is it acknowledged that this change will effectively prevent proper > idempotent partial updates on the web? No. You can do idempotent partial updates with POST and PATCH (by including an If-Match header field). > - In light of the recent proliferation of 'mobile clients' which > operate on relatively slow and unreliable networks where partial > idempotent updates would be ideal; is the loss of idempotent partial > updates considered acceptable? See above: (1) PUT never allowed partial updates, and (2) you don't need PUT to make modifications idempotent. Best regards, Julian
Received on Monday, 27 February 2012 15:15:50 UTC