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

Re: Idempotent partial updates

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 28 Feb 2012 10:23:51 -0800
Message-ID: <CABkgnnVeZ2j48ZKOTifJnQsBHcw6U4xw0-Q9AU+5cxiifSKaOg@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Mike Kelly <mikekelly321@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 28 February 2012 08:49, Julian Reschke <julian.reschke@gmx.de> wrote:
>> A PUT is by definition idempotent.  A PATCH, like POST, is only
>> idempotent under (secret, non-obvious) conditions.
> That is true, but I'm not sure that is a problem when the conditions are
> well understood and documented.

That's the part that needs to be clearer.  Because I'm not certain
that I can look at a given PATCH (or POST) request and make a
determination about idempotence. The problem is that RFC 5789
categorically denies that PATCH is idempotent (then goes on to qualify
as you cited previously.)

Is it always true that a PATCH request with an If-Match header
containing a strong ETag is idempotent?  I think that it is as long as
the contract is observed (i.e. the server pays attention to the
If-Match; the ETag really is strong).

I don't think that any of the other conditional headers can be used to
make a statement of the same certitude.  Of course, there are plenty
of requests that could be non-idempotent, but - if you understand the
context - are actually idempotent.  That's the point of contention: is
it desirable that this property be observable (thanks Carsten)?

I don't see a strong reason to.  (What I think you saw as motivation
to do so, was just an attempt at clarifying a technical point.)  I
tend to think that if this is important, you need to restructure your
resources (my original point).

Received on Tuesday, 28 February 2012 18:24:24 UTC

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