W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2005

Re: WebDav methods and idempotency

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 25 Feb 2005 21:34:57 +0100
Message-ID: <421F8BF1.5000902@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: w3c-dist-auth@w3.org

Mark Nottingham wrote:
> 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?"

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.

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
Received on Friday, 25 February 2005 20:35:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:31 UTC