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

Re: Idempotent partial updates

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Wed, 29 Feb 2012 01:38:26 +1300
Message-ID: <4F4CCAC2.7000304@treenet.co.nz>
To: ietf-http-wg@w3.org
On 28/02/2012 11:10 p.m., 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.

What seems not so obvious, is that the PUT request-body is cacheable for 
the request-URI. Middleware can leverage this immediately on a 2xx 
response to start serving it up without wasting further bandwidth 
re-fetching it. People are already hacking away at the code trying to 
get as much as possible cached. Bandwidth reduction is a hot topic in 
the cloud based web app world. You can expect to see implementations 
appearing within the year, now that there is an actual need appearing.

As has been mentioned by others already a lot of HTTP capabilties were 
rare due to HTML limitations affecting the browsers. Custom HTTP agents 
have been using these features invisibly for some time. Browsers XHR 
support and HTML5 features are opening the doors to a great many web 
apps using these features in ways never before seen (outside the dreams 
of the spec writers anyway, maybe not even there).

AYJ
Received on Tuesday, 28 February 2012 12:38:55 GMT

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