RE: Issues PUT_AND_INTERMEDIATE_COLLECTIONS and INTEROP_DELETE_A ND_MULTISTATUS

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