Re: WebDav methods and idempotency

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:

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

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

Received on Saturday, 26 February 2005 08:12:39 UTC