Re: WebDav methods and idempotency

Mark Nottingham wrote:
> Hmm, that seems to be revising the semantics of PUT to be 
> 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

Received on Monday, 7 March 2005 07:30:55 UTC