Re: Appropriate partial success codes (was Re: Some questions about WebDAV)

Some of these are pretty obvious, such as no reason to return a 
multi-status
for something that is independent of the target resource (e.g., 413, 414),
but it would be worth at least a one-liner explaining why these status 
codes
must not be used.

More generally, could you explain what problem this is intended to solve?
A client must be written to cope with status codes it doesn't understand,
in which case it will just look at the first digit.

Cheers,
Geoff


Lisa wrote on 10/11/2005 08:59:46 PM:

> 
> This thread from a couple months ago brought up something probably 
> worth clarifying in RFC2518bis.  In fact we could usefully constrain 
> servers generally in what status codes MAY or MUST NOT be used inside 
> Multi-Status.  I wrote up a strawman draft section for this so we could 
> discuss the specifics:
> 
>     The following status codes MUST NOT be used in Multi-Status
>     responses: 100 Continue, 101 Switching Protocols, 205 Reset Content,
>     206 Partial Content, 300 Multiple Choices?, 305 Use Proxy, 400 Bad
>     Request, 405 Method Not Allowed, 406 Not Acceptable, 407 Proxy
>     Authentication Required, 411 Length Required, 412 Precondition
>     Failed, 413 Request Entity Too Large, 414 Request-URI Too Long, 415
>     Unsupported Media Type, 416 Requested Range Not Satisfiable, 417
>     Expectation Failed, 501 Not Implemented and 505 HTTP Version Not
>     Supported.
> 
>     The following status codes MAY be used in Multi-Status responses: 
200
>     OK, 201 Created, 301 Moved Permanently, 302 Found, 303 See Other, 
307
>     Temporary Redirect, 401 Unauthorized, 403 Forbidden, 404 Not Found
>     and 410 Gone.
> 
>     The following status codes MAY be used in Multi-Status responses,
>     although the meaning might be unclear based only on this
>     specification.  Thus, specifications extending WebDAV MAY make use 
of
>     these status codes in Multi-Status responses but regular WebDAV
>     clients would reasonably be expected to be confused by these: 202
>     Accepted, 203 Non-Authoritative Information, 204 No Content, 304 Not
>     Modified, 402 Payment Required, 409 Conflict, 408 Request Timeout,
>     500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable
>     and 504 Gateway Timeout.
> 
> Comments?
> 
> Lisa
> 
> On Jul 20, 2005, at 11:48 PM, Julian Reschke wrote:
> 
> >
> > ChunWei Ho wrote:
> >> Hi,
> >> I have another question. When the If header (webDAV's If header)
> >> condition is not met, the request should fail with 412 Precondition
> >> Failed. If the request is one over multiple resource, like PROPFIND,
> >> COPY or MOVE over Depth > 0, should the whole request fail returning
> >> 412 Precondition Failed, or fail only for the specific resources
> >> returning 207 MultiStatus with some portions giving a 412 
Precondition
> >> Failed.
> >> Thanks again for the help! :)
> >> Regards,
> >> CW
> >
> > Hi,
> >
> > judging from 
> > <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.9.4.p.4>:
> >
> > "The If header's purpose is to describe a series of state lists. If 
> > the state of the resource to which the header is applied does not 
> > match any of the specified state lists then the request MUST fail with 

> > a 412 (Precondition Failed). If one of the described state lists 
> > matches the state of the resource then the request may succeed."
> >
> > I would say that the server must return a 412 (so partial 
> > execution/success of the request is not an option).
> >
> > Best regards, Julian
> >
> 
>