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

RE: need clarification about COPY to locked resource response cod e

From: Clemm, Geoff <gclemm@rational.com>
Date: Sat, 20 Apr 2002 21:10:22 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B106979542@SUS-MA1IT01>
To: WebDAV <w3c-dist-auth@w3.org>
   From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]

   Am Freitag den, 19. April 2002, um 10:12, schrieb Julian Reschke:

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

I don't see the problem.  Either the client does not care about
the reason for the error (in which case it just ignores the
DAV:error value), or it does care, in which case it needs the
explanation provided by the DAV:error value.  The advantage of
having both is that you have a simple error code for simple clients,
and a more comprehensive error code for more sophisticated clients.

   So I would prefer to use existing HTTP
   status codes over new DAV:errors.

You can't pack sufficient information into the few bits provided
by the HTTP status codes, without having the error codes mean subtly
different things for different methods (the unfortunate path
initiated by 2518, but avoided by 3253).

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

You define errors at whatever
is the appropriate level of detail that is useful for
interoperable implementations.  If the distinction between
"destination is not accessible" and "destination parent is locked"
is sufficiently important to merit separate error codes, then separate
error codes should be defined.

Received on Saturday, 20 April 2002 21:10:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:25 UTC