W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: Idempotent partial updates

From: Mike Kelly <mikekelly321@gmail.com>
Date: Tue, 28 Feb 2012 10:39:24 +0000
Message-ID: <CANqiZJbuMi5=WWVFAx4_ef3Din0oj93VdFzuwpfAqxTDN_QZmg@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: "Eric J. Bowman" <eric@bisonsystems.net>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Feb 28, 2012 at 10:19 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2012-02-28 11:10, Mike Kelly wrote:
>>
>> On Tue, Feb 28, 2012 at 5:27 AM, Eric J. Bowman<eric@bisonsystems.net>
>>  wrote:
>>>
>>> Martin Thomson wrote:
>>>>
>>>>
>>>> I agree with Mike that PATCH (or a special POST) aren't visibly
>>>> idempotent, which is a crucial characteristic if this is going to
>>>> work.
>>>>
>>>
>>> If 99.9% of partial updates are non-idempotent, wouldn't the need for
>>> idempotent partial update be an edge case, as opposed to crucial?
>>>
>>> What we're trying to make visible on the wire is *sender intent* not
>>> idempotency.  The sender doesn't intend to make idempotent vs. non-
>>> idempotent requests.  Idempotency is a property of the request method,
>>> not a sender intent in and of itself.
>>
>>
>> No. What we should be trying to make visible "on the wire" are
>> properties of a request that are useful/valuable for intermediate
>> processing.
>>
>> The idempotency of a request is valuable for intermediate processing,
>> because infrastructure can be developed to re-issue a client request
>> on network failure.
>>
>> Having a request guaranteed to be non-partial is not useful or
>> valuable for intermediate processing, apparently there are no examples
>> of intermediary mechanisms which leverage this.
>
>
> Just because something isn't useful to intermediaries (with which I don't
> fully agree) doesn't mean it isn't useful to be defined.
>

If we're talking about 'visibility on the wire', we should be talking
about facilitating intermediary processing.

I have a couple of further questions:

- why don't you fully agree?
- how is PUT being unambiguously non-partial useful?

Bear in mind applications which interact through HTTP can define
whether or not their use(s) of PUT are non-partial without HTTP being
involved - many already do this.

Cheers,
Mike
Received on Tuesday, 28 February 2012 10:39:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:56 GMT