W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2002

RE: need clarification about COPY to locked resource response code

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 19 Apr 2002 10:47:29 +0200
To: "WebDAV" <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCAEPDEGAA.julian.reschke@gmx.de>
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing
> Sent: Friday, April 19, 2002 10:32 AM
> To: Julian Reschke
> Cc: WebDAV
> Subject: Re: need clarification about COPY to locked resource response
> code
>
> ...
>
> > - there doesn't seem to be any prior usage of multistatus to describe
> > information about destination URIs.
>
> The examples cover children of destination uris in 207. But, for
> example,

Indeed. So I'll have to take this back.

But how well will this interoperate? If the href in multistatus only lists
the destination URI, it will be non-trivial to find out which source could
not be copied/moved, right? So to make this fly, I'd expect the response
element *also* to tell me which source resource was affected by the problem
on the destination.

> with access control you can get 403 on the destination uri and that is
> not defined either. I would expect a server to report this 403 on the
> destination inside a 207 multistatus.
>
> > The cleanest "solution" (although not backward-compatible) would
> > be to have
> > a separate status code for the condition "destination locked".
> > However, we
> > are currently talking about RFC2518, so we're probably stuck with the
> > ambiguity.
> >
> > In a future WebDAV protocol that supports enhanced error reporting a la
> > RFC3253, I'd probably suggest:
> >
> > 409 CONFLICT
> > ....
> >
> > <error xmlns='DAV:'><destination-URI-is-locked/></error>
>
> I don't like this for the simple reason that clients need hardcoded
> information about each DAV:error _and_ they need to know how to handle
> HTTP status codes. So I would prefer to use existing HTTP status
> codes over
> new DAV:errors.

RFC3253 already goes this way, simply for the reason that it's hard to
define new HTTP status codes, but it's simple to define new error elements
(because this solves the issue of namespacing the new codes automatically).
"Simple" clients will just see 403 (won't work no matter how hard you try)
or 409 (it failed, but there's something you can do about it).

> Otherwise you need to define also DAV:destination-is-not-accesible,
> DAV:destination-parent-is-locked, etc.

Maybe.
Received on Friday, 19 April 2002 04:48:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:00 GMT