Re: Idempotent partial updates

On Mon, Feb 27, 2012 at 3:15 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> 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."
>

It was ambiguous enough to lead to real-world implementations which
directly violate it. You've said as much above, and the action to
ammend the semantics

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

It is now explicit and non-ambiguous (i.e. prevented). That is new.

This is getting away from the real intention of the question: what are
your thoughts on the benefits of partial prevention vs non-prevention?

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

I'm aware of this technique. It's neat, but I wouldn't consider it
explicitly idempotent; i.e. it's idempotent nature is not explicit and
is therefore not very visible. This is an issue for intermediary
components, such as HTTP client libraries in mobiles which (if the
request were PUT) could handle the re-issue of failed requests. Afaik,
this infrastructure already exists  right now on the web and works
fine for partial PUT requests.

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

as above:

(1) Then why were the semantics amended, and why would others have
implemented against the spec in that fashion?

(2) You need PUT to make a request that is visibly idempotent through
the network.

Cheers,
Mike

Received on Monday, 27 February 2012 15:36:28 UTC