Re: WebDav methods and idempotency

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.

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

Received on Friday, 25 February 2005 20:35:37 UTC