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 07:53:04 UTC