RE: DAV:can-overwrite

> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
> Behalf Of Clemm, Geoff
> Sent: Monday, October 14, 2002 3:08 PM
> To: WebDAV (E-mail)
> Subject: RE: DAV:can-overwrite
>
>
>    From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
>    ... the binding draft borrows it's error handling from RFC3253, but
>    it's Overwrite header handling from RFC2518 -- but a server can't
>    do both. An RFC2518 compliant server would return a 412
>    (Precondition failed), an RFC3253 compliant server would return
>    403/409 with DAV:error/DAV:can-overwrite.
>    This isn't a severe problem, but it's annyoing.
>    I think a possible way out of this dilemma is to extend the RFC3253
>    rules by saying that the DAV:error response may also be used for
>    HTTP status 412 (por possibly more or all error codes). We could
>    then have the BIND-enhanced server return
>    HTTP/1.1 412 Precondition Failed
>    Content-Type: text/xml; charset="utf-8"
>    Content-Length: xxxx
>    <?xml version="1.0" encoding="utf-8" ?>
>    <D:error xmlns:D="DAV:">
>     <D:can-overwrite/>
>    </D:error>
>    At least for our client this would make it much easier to continue
>    to have a *generic* method of mapping responses to Java exceptions.
>    [1] <http://greenbytes.de/tech/webdav/rfc2518.html#HEADER_Overwrite>
>    [2] <http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.1.6>
>
> I'd be happy to allow error codes for 412, or to use a
> DAV:overwrite tag in the BIND request body, instead of the
> Overwrite header.  I'm slightly more inclined to do the
> latter, since bundling all the parameters into the request
> body seems like a more meaningful "unification" than re-using
> the Overwrite header, but either way is fine with me.

I think I prefer the former -- obviously we have to choose between

- making it as simple as possible for BIND

- making it as consistent as possible for RFC2518

Moving the overwrite flag into the request body solves just one problem --
allowing the DAV:error element (or actually *specifying* it) for response
codes != 403/409 simplifies the error mapping in other cases as well.

So my vote would be to leave the BIND spec as it is, and to add an entry to
the RFC2518 issues list saying that 4xx/5xx response bodies MAY use the
DAV:error format defined in RFC3253. We could then start a separate activity
to specify precondition names for common RFC2518 error conditions (such as
parent collection must exist).

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Tuesday, 15 October 2002 04:35:00 UTC