RE: v6 comments - multistatus responses

BTW, I actually changed the "MUST"s to "SHOULD"s. Thus a server has the
right to return 424 and 204 but shouldn't unless they have a damn good
reason.

As for requiring confirmation of success, that would be unreasonably
verbose. If you copy 10,000 files you will end up with 10,000 success
statements. Given that we have defined, in an absolutely deterministic way,
the result without requiring extra bytes on the wire, I think we have done
the whole world a favor.

		Yaron

> -----Original Message-----
> From:	Dylan Barrell [SMTP:dbarrell@opentext.ch]
> Sent:	Tuesday, February 03, 1998 2:02 AM
> To:	Yaron Goland; 'WebDAV'
> Subject:	RE: v6 comments - multistatus responses
> 
> I would prefer to require that a server MUST return a confirmation of the
> success of the operation rather than the client simply assuming that the
> operation succeeded if absolutely no response is received.
> 
> Cheers
> Dylan
> 
> -----Original Message-----
> From:	Yaron Goland [SMTP:yarong@microsoft.com]
> Sent:	Friday, January 30, 1998 9:17 AM
> To:	'Dylan Barrell'; 'WebDAV'
> Subject:	RE: v6 comments - multistatus responses
> 
> ..... 
> If an error occurs with a resource other than the resource identified in
> the
> request URI then the response MUST be a 207 Multi-Status.  424 Method
> Failure errors MUST NOT be in the 207 Multi-Status.  They can be safely
> left
> out because the client will automatically know that the ancestors of a
> resource could not be deleted when the client receives an error for the
> ancestor's progeny.  Additionally 204 No Content errors MUST NOT be
> returned
> in the 207 Multi-Status.  The reason for this prohibition is that 204 No
> Content is the default success code.  As such the client may safely assume
> that a resource was deleted successfully if no response is returned.
> .......

Received on Tuesday, 3 February 1998 14:42:41 UTC