- From: Clemm, Geoff <gclemm@rational.com>
- Date: 2002年4月21日 20:40:48 -0400
- To: Stefan Eissing <stefan.eissing@greenbytes.de>, "Clemm, Geoff" <gclemm@rational.com>
- Cc: WebDAV <w3c-dist-auth@w3.org>
- Message-ID: <3906C56A7BD1F54593344C05BD1374B1069795D1@SUS-MA1IT01>
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] 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. Section 8.8.3 of RFC 2518 has "error minimization rules" that require/encourage a server to only return the error once for a given lock. So only one such error message would be included. 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> I don't think this degree of divergence from RFC 2518 is warranted/required. The error minimization rules handle this case reasonably well. Note: I am neutral as to whether the server returns a 423 LOCKED or a 409 CONFLICT in case an error token is being returned by the server. One can make reasonable arguments for either behavior (but I personally would do the latter, i.e. 409 CONLICT). Cheers, Geoff
Received on Sunday, 21 April 2002 20:41:23 UTC