- From: Clemm, Geoff <gclemm@rational.com>
- Date: Mon, 27 Jan 2003 10:10:05 -0500
- To: w3c-dist-auth@w3c.org
The only reason I can think of for having a new 4xx and 5xx response code would be to warn the client that it is getting a DAV:multistatus body for the error message. But until someone makes a good case for why it is hard for a client to just scan the response body to figure this out, I'd go with Julian's suggestion, and just allow arbitrary 4xx and 5xx response codes (or a specific set of existing 4xx and 5xx response codes) to take a DAV:multistatus body. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, January 27, 2003 7:53 AM To: Roy T. Fielding Cc: w3c-dist-auth@w3c.org Subject: RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and INTEROP_DELETE_A ND_MULTISTATUS (sorry for my previous empty mail) > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding > Sent: Friday, January 24, 2003 10:51 PM > To: Julian Reschke > Cc: w3c-dist-auth@w3c.org > Subject: Re: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and > INTEROP_DELETE_A ND_MULTISTATUS > ... > > Why don't you just respond with the status code of the first error, > since otherwise you will need a 5xx as well. > > 207 is completely lame (and yes I did make a stink of it at the time). > HTTP doesn't specify the contents of the message body -- a multi-response > could have just as easily been done as 200/201 with a special media type > specific to webdav. The client already knows it is performing a webdav > action and intermediaries know it isn't cacheable (because of the method), > so a parallel set of status codes isn't necessary. I absolutely agree that 207 is lame -- for a successful response, 200 should have been just fine. However, this doesn't seem to be a real issue, as long as we use 207 only as a status for successfull requests, such as a typical PROPFIND. The suggestion not to specify any new error code is interesting, and we should really discuss how far we can go this path. Proposal: define that servers may send a DAV:multistatus or a DAV:error (RFC3253) body with any 4xx and 5xx response. Use DAV:multistatus for failures that affected resources other than the one identified by the request URI, and DAV:error (optionally) otherwise. Clients would then initiate the DAV:multistatus / DAV:error evalutations independantly of the response code (do we need a new content type? I don't think so). Let's try some examples: 1) A collection delete fails because the server couldn't delete one of it's children (privileges missing): HTTP/1.1 403 Forbidden <multistatus xmlns='DAV:'> <response> <href>foobar/xyz</hre> <status>HTTP/1.1 403 Forbidden</status> </response> </multistatus> (note that we wouldn't include a response for the parent collection(s) as per result minimization rules) 2) A collection delete fails because the server couldn't delete one of it's children (I/O error because some other process on the server has the actual file in the filesystem opened): HTTP/1.1 500 Internal Server Error <multistatus xmlns='DAV:'> <response> <href>foobar/xyz</hre> <status>HTTP/1.1 500 Internal Server Error</status> </response> </multistatus> 3) PROPPATCH on a protected property HTTP/1.1 403 Forbidden <multistatus xmlns='DAV:'> <response> <href>foobar</hre> <propstat> <prop><checked-in/></prop> <status>HTTP/1.1 403 Forbidden</status> </propstat> <propstat> <prop><comment/></prop> <status>HTTP/1.1 424 Dep. Failed</status> </propstat> </response> </multistatus> This really seems to work quite well. So can anybody think of a reason why we would need a new return code? Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Monday, 27 January 2003 10:10:44 UTC