Subject: WebDav methods and idempotency

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Feb 2005 21:38:00 -0800

A couple of questions about WebDAV;

* The only mention of idempotency in any WebDAV RFC that I see is: 
"Responses from a MKCOL request MUST NOT be cached as MKCOL has 
non-idempotent semantics" in 2518, Section 8.3.2. Is it the case, then, 
that all other WebDAV-defined methods are in fact idempotent?

I could see MOVE as non-idempotent, IF the semantics of COPY are such 
that it's legal to COPY a null resource; i.e., the MOVE would first 
COPY the existant resource, then DELETE it, then on a subsequent 
request, would COPY the null resource. However, it isn't clear from a 
casual reading of 2518 as to whether COPY will fail (404?) if you try 
to point it at a null resource.

* How is MKCOL non-idempotent? I.e., how does performing MKCOL /foo 
five times have different side effects than performing it once? 2518 
says that "If the resource identified by the Request-URI is non-null 
then the MKCOL MUST fail." It seems that all MKCOLs after the first one 
will fail, thus bringing no new side-effects. I can certainly see how 
MKCOL could be involved in a non-idempotent sequence, but don't see how 
it is on its own; am I missing something, or should it be "MKCOL has 
side effects" instead of "MKCOL has non-idempotent semantics?"

Thanks,

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 Feb 2005 21:34:57 +0100

Mark Nottingham wrote:
> that it's legal to COPY a null resource; i.e., the MOVE would first COPY 
> the existant resource, then DELETE it, then on a subsequent request, 
> would COPY the null resource. However, it isn't clear from a casual 
> reading of 2518 as to whether COPY will fail (404?) if you try to point 
> it at a null resource.
> 
> * How is MKCOL non-idempotent? I.e., how does performing MKCOL /foo five 
> times have different side effects than performing it once? 2518 says 
> that "If the resource identified by the Request-URI is non-null then the 
> MKCOL MUST fail." It seems that all MKCOLs after the first one will 
> fail, thus bringing no new side-effects. I can certainly see how MKCOL 
> could be involved in a non-idempotent sequence, but don't see how it is 
> on its own; am I missing something, or should it be "MKCOL has side 
> effects" instead of "MKCOL has non-idempotent semantics?"

You are right, MKCOL isn't idempotent, nor is MOVE. I'll raise issues 
against RFC2518bis, RFC3253bis, RFC3648bis and RFC3744bis so this get's 
fixed in future revisions.

In BIND 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-11.html>) 
we're hopefully already doing it right; but you may want to check :-)

Best regards, Julian

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

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 25 Feb 2005 14:46:39 -0800

On Feb 25, 2005, at 12:34 PM, Julian Reschke wrote:

> against RFC2518bis, RFC3253bis, RFC3648bis and RFC3744bis so this 
> get's fixed in future revisions.

Do you mean that MKCOL *is* idempotent, and MOVE isn't?

Thanks!

---

From: Julian Reschke <[email-masked]>
Date: Sat, 26 Feb 2005 09:07:56 +0100

> Do you mean that MKCOL *is* idempotent, and MOVE isn't?

Yep, sorry. MKCOL is idempotent.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 26 Feb 2005 00:12:35 -0800

If MOVE is non-idempotent, it might also be good to clarify the 
semantics of MOVEing a null resource in 2518bis; i.e., that it's 
allowed, and won't give a 404 (for example).

Cheers,

On Feb 25, 2005, at 12:34 PM, Julian Reschke wrote:

>> non-idempotent semantics" in 2518, Section 8.3.2. Is it the case, 
>> then, that all other WebDAV-defined methods are in fact idempotent?
> >
>> then the MKCOL MUST fail." It seems that all MKCOLs after the first 
>> one will fail, thus bringing no new side-effects. I can certainly see 
>> how MKCOL could be involved in a non-idempotent sequence, but don't 
>> see how it is on its own; am I missing something, or should it be 
>> "MKCOL has side effects" instead of "MKCOL has non-idempotent 
>> semantics?"
>

---

From: Julian Reschke <[email-masked]>
Date: Sat, 26 Feb 2005 09:27:18 +0100

> allowed, and won't give a 404 (for example).

Finally I'm starting to understand the issue :-)

Yes, MOVE applied to a null resource is expected to fail (with 404); 
thus doing a MOVE two times in a row should leave the system in the same 
state as doing it once. Seems it's idempotent after all. Same for COPY, 
except...:

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..

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 27 Feb 2005 16:52:18 +0100

Mark Nottingham wrote:
 > ...

I have started a RFC3648bis container document for collecting errata in 
RFC3648 (Ordered Collections).

HTML version: 
<http://greenbytes.de/tech/webdav/draft-reschke-rfc3648bis-latest.html>
Issues list:
<http://greenbytes.de/tech/webdav/draft-reschke-rfc3648bis-issues.html>

I've added a new issue for the question raised by Mark (against all 
specs...) in 
<http://greenbytes.de/tech/webdav/draft-reschke-rfc3648bis-issues.html#7_safeness_and_idempotence> 
and resolved it by adding the following statement to the ORDERPATCH 
method description:

   "This method is unsafe and idempotent (see [RFC2616], Section 9.1)."

Best regards, Julian