Subject: Re: WebDav methods and idempotency

From: Mark Nottingham <[email-masked]>
Date: Sun, 6 Mar 2005 21:43:11 -0800

Hmm, that seems to be revising the semantics of PUT to be 
non-idempotent; doesn't seem like a good idea...

On Feb 26, 2005, at 12:27 AM, Julian Reschke wrote:

> RFC3253 allows PUT and COPY (target resource) to be auto-versioned. 
> That is, everytime you PUT to a URI, you may be -- as a side effect -- 
> creating a new version (and the DeltaV live properties on the resource 
> will reflect this). Can we still consider this idempotent. RFC3253bis 
> should say something about this..

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 07 Mar 2005 08:30:15 +0100

> non-idempotent; doesn't seem like a good idea...

It's IMHO certainly the right thing to do with PUT on version-controlled 
resources.

Let's take a look at the definition 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.1.2>):

--
9.1.2 Idempotent Methods

Methods can also have the property of "idempotence" in that (aside from 
error or expiration issues) the side-effects of N > 0 identical requests 
is the same as for a single request. The methods GET, HEAD, PUT and 
DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD 
NOT have side effects, and so are inherently idempotent.

However, it is possible that a sequence of several requests is 
non-idempotent, even if all of the methods executed in that sequence are 
idempotent. (A sequence is idempotent if a single execution of the 
entire sequence always yields a result that is not changed by a 
reexecution of all, or part, of that sequence.) For example, a sequence 
is non-idempotent if its result depends on a value that is later 
modified in the same sequence.

A sequence that never has side effects is idempotent, by definition 
(provided that no concurrent operations are being executed on the same 
set of resources).
--

So if we'd classify the effect of adding something to the version 
history the same way as writing something to an audit log, that would be 
fine.

I should also clarify that the issue only occurs for auto-versioned 
resources. That is, if I explicitly CHECKOUT a resource, do multiple 
PUTs, then apply CHECKIN, I get exactly one new version (no matter how 
often PUT was applied). That should be fine, right?

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760