[Ietf-caldav] MKCOL versus MKCALENDAR and status code

[Julian Reschke]

Arnaud Quillaud wrote:
> Hello,
> 
> Both WebDAV MKCOL and CalDAV MKCALENDAR should fail if the Request-URI is already mapped.

Yes.

> If I look at the MKCOL definition (http://tools.ietf.org/html/rfc4918#section-9.3.1), I see a corresponding status code:
> <<
> 405 (Method Not Allowed) - MKCOL can only be executed on an unmapped URL.
> but no precondition.

Yes. Probably should have been included.

> If I look at the MKCALENDAR definition (http://tools.ietf.org/html/rfc4791#section-5.3.1), I see a corresponding precondition:
> <<
> (DAV:resource-must-be-null): A resource MUST NOT exist at the Request-URI;
> but no specific status code.

Yes, that's stolen^H^H^H^H^H^Hcopied from 
<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.6.3>.

> The most common status code when sending back a precondition error is 403 (Forbidden).

Not really. It's just a default when nothing else applies.

> Both MKCOL and MKCALENDAR define the meaning of this status code in their context in the same way:
> <<
>       403 (Forbidden) - This indicates at least one of two conditions:
>       1) the server does not allow the creation of calendar collections
>       at the given location in its namespace, or 2) the parent
>       collection of the Request-URI exists but cannot accept members;
> 
> So should MKCALENDAR return a 405 with a DAV:resource-must-be-null error body (and an Allow header), or a 403 with a DAV:resource-must-be-null error body ?

405.

> If 403 with a DAV:resource-must-be-null is more appropriate, is there any harm doing the same for MKCOL ?

Both should behave the same. That being said, I'd be surprised if it 
makes any difference in practice.



Best regards, Julian