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
_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav osafoundation.org
See http://ietf.webdav.org
/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-
caldav
|
