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

Re: Idempotent partial updates

From: Mike Kelly <mike@mykanjo.co.uk>
Date: Tue, 28 Feb 2012 13:31:19 +0000
Message-ID: <CANqiZJaO70OSLAdmCnvN+uW1VvuA7-Psr4Ow4nJO=pgA_nsJSQ@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: ietf-http-wg@w3.org
On Tue, Feb 28, 2012 at 12:38 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
> 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.

Do you know of any caching infrastructure that is implemented to this effect?

Does it conflict with the following:


"Responses to the PUT method are not cacheable.  If a PUT request
passes through a cache that has one or more stored responses for the
effective request URI, those stored responses will be invalidated"

Received on Tuesday, 28 February 2012 13:31:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:00 UTC