- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: 2002年4月21日 11:36:15 +0200
- To: "Clemm, Geoff" <gclemm@rational.com>
- Cc: WebDAV <w3c-dist-auth@w3.org>
- Message-Id: <39FEE6DB-550B-11D6-8B11-00039384827E@greenbytes.de>
Am Sonntag den, 21. April 2002, um 03:10, schrieb Clemm, Geoff: > 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. One cannot not disagree with this. However, in Julian's example error responses like 403 and others are replaced with a general 409 and some DAV:error in the response body. What you are talking about is keeping a 403 response and _adding_ a response body with a more detailed explanation in DAV:error. That is perfectly fine with me. > 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). I have to elaborate. Instead of a response plain vanilla HTTP/1.1 403 LOCKED or Julian's HTTP/1.1 409 CONFLICT <DAV:error><DAV:destination-parent-locked/></DAV:error> I would prefer HTTP/1.1 207 MultiStatus <DAV:multistatus> <DAV:response><DAV:href>http://host/destination/parent</DAV:href> <DAV:status>HTTP/1.1 403 LOCKED</DAV:status> </DAV:response> ... </DAV:multistatus> The problem with this is that for COPY/MOVE, a server would have to list all non-copied resources as well in the multistatus. Something to be avoided when a precondition for a operation failed. So, the best of both worlds would maybe be: HTTP/1.1 403 LOCKED <DAV:error> <DAV:href>http://host/destination/parent</DAV:href> <DAV:status>HTTP/1.1 403 LOCKED</DAV:status> </DAV:error> //Stefan > 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. > > Cheers, > Geoff >
Received on Sunday, 21 April 2002 05:36:29 UTC