RE: v6 comments - multistatus responses

BTW my note regarding LOCK was incorrect. It turns out, interestingly
enough, that the language already specifies that only the error information
is to be returned (please refer to section 7.10.4, third sentence from the
bottom in the last paragraph). It was the example that was incorrect, it
provided more information than was necessary. As such I have fixed the
example but not otherwise altered the section on LOCK

I have added this as the last paragraph of section 7.6.2 DELETE for
Collections and have updated the examples and accompanying text

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.

I have changed the last three paragraphs of 7.8.3 COPY for Collections and
have updated the examples and accompanying text

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.  The href XML
element in the response refers to the resource that was to be copied, not
the resource that was created as a result of the copy.  In other words, each
entry indicates whether the copy on the resource specified in the href XML
element succeeded or failed and why.

The exception to this rule is for errors that occurred on the destination.
For example, if the destination was locked the response would indicate the
destination URL and a 423 Locked error.

424 Method Failure errors MUST NOT be returned in the 207 Multi-Status.
These responses can be safely left out because the client will automatically
know that the progeny of a resource could not be copied when the client
receives an error for the parent.  Additionally 201 Created/204 No Content
response codes MUST NOT be returned as values in the 207 Multi-Status
response.  They too can be safely left out because they are the default
success codes.  As such the client may safely assume that a resource was
copied successfully if no response is returned.

Finally, 7.9.1 MOVE for Collections, examples and accompanying text also
updated

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.  The href XML
element in the response refers to the resource that was to be moved, not the
resource that was created as a result of the move.  In other words, each
entry indicates whether the move on the resource specified in the href
succeeded or failed and why.

The exception to this rule is for errors that occurred on the destination.
For example, if the destination was locked the response would indicate the
destination URL and a 423 Locked error.

424 Method Failure errors MUST NOT be returned as values in the 207
Multi-Status.  These errors can be safely left out because the client will
automatically know that the progeny of a resource could not be moved when
the client receives an error for the parent.  Additionally 201 Created/204
No Content responses MUST NOT be returned as values in the 207 Multi-Status
response.  These responses can be safely left out because they are the
default success codes.  As such the client may safely assume that a resource
was moved successfully if no response is returned.


			Yaron

> -----Original Message-----
> From:	Yaron Goland 
> Sent:	Thursday, January 29, 1998 10:55 PM
> To:	'Dylan Barrell'; 'WebDAV'
> Subject:	RE: v6 comments - multistatus responses
> 
> I think the verbose header is unnecessary as is the current response
> format, it is an artifact of design decisions made regarding
> PROPFIND/PROPPATCH where there were very good reasons for returning
> everything.
> 
> I suspect that a more basic question is: What sort of response information
> does one need from DELETE/COPY/MOVE?
> 
> Success information is only useful in the context of your next command.
> That is, I successfully deleted a/b so I don't need to copy it to the
> backup disk. However given the lack of atomic operation any supposition
> made in the next command as a result of responses from the previous
> command are generally dangerous. That is, you may have just deleted a/b
> but someone else may just have created a new a/b and so you will need to
> back it up. As such I would argue that success information other than a
> summary "I did what I was told" is useless.
> 
> Failure information, however, is different because it can be used to fix a
> problem. For example, imagine trying to delete a/b and getting back a 401
> Unauthorized. At that point there is something one can do to actually fix
> the problem. However, failure information based on the namespace, that is,
> a/b could not be moved so a/b/c and a/b/d did not get deleted, is not
> terribly useful as it all reflects the same basic problem.
> 
> Given the previous I am proposing the following changes to the
> specification:
> 
> COPY/MOVE/DELETE - Only return 4xx and 5xx codes but NEVER 424 Method
> Failure
> 
> So the example in 7.8.2.1 would be:
> >>Request
> 
> DELETE  /container/ HTTP/1.1
> Host: www.foo.bar
> 
> >>Response
> 
> HTTP/1.1 207 Multi-Status
> Content-Type: text/xml
> Content-Length: xxxxx
> 
> <?xml version="1.0"?>
> <?namespace href="http://www.iana.org/standards/dav/" as="d"?>
> <d:multistatus>
> 	<d:response>
> 		<d:href>http://www.foo.bar/container/resource3</d:href>
> 		<d:status>HTTP/1.1 425 Locked</d:status>
> 	</d:response>
> </d:multistatus>
> 
> The Copy example becomes
> 
> >>Request
> 
> COPY /container/ HTTP/1.1
> Host: www.foo.bar
> Destination: http://www.foo.bar/othercontainer/
> Depth: infinity
> Content-Type: text/xml
> Content-Length: xxxxx
> 
> <?xml version="1.0"?>
> <?namespace href="http://www.iana.org/standards/dav/" as="d"?>
> <d:propertybehavior>
> 	<d:keepalive>*</d:keepalive>
> </d:propertybehavior>
> 
> >>Response
> 
> HTTP/1.1 207 Multi-Status
> Content-Type: text/xml
> Content-Length: xxxxx
> 
> <?xml version="1.0"?>
> <?namespace href="http://www.iana.org/standards/dav/" as="d"?>
> <d:multistatus>
> 	<d:response>
> 	  <d:href>http://www.foo.bar/othercontainer/R2/</d:href>
> 	  <d:href>http://www.foo.bar/othercontainer/R2/D2</d:href>
> 	  <d:status>HTTP/1.1 412 Precondition Failed</d:status>
> 	</d:response>
> </d:multistatus>
> 
> etc.
> 
> 	Any objections?
> 
> 			Yaron
> 
> 
> 	-----Original Message-----
> 	From:	Dylan Barrell [SMTP:dbarrell@opentext.ch]
> 	Sent:	Thursday, January 29, 1998 10:51 AM
> 	To:	'WebDAV'
> 	Subject:	v6 comments - multistatus responses
> 
> 	The multistatus responses are too verbose. For example the MOVE of a
> very large subtree (thousands or hundreds of thousands of children) will
> result in a multistatus entry for each successfully and each
> unsuccessfully moved resource. The same applies to many of the other
> methods.
> 
> 	I think the responses should operate on the principle of "no news is
> good news" and only contain entries for the resources which could not be
> processed. They should also not include entries for resources which could
> not be processed as a result of not being able to process another resource
> (for example the DELETE method states that if a resource cannot be deleted
> none of its ancestors may be deleted).
> 
> 	I think that a verbosity header should then be added which will
> allow a client to request the fully verbose multistatus response - the
> default should however be non-verbose.
> 
> 	The verbose header would be defined as follows:
> 
> 	Verbose = "Verbose" ":" ( "T" | "F" )
> 
> 	The Verbose header specifies whether any multistatus response
> generated by the request should generate entries which correspond to
> successfully processed resources. A  value of "T" indicates that the
> successful multistatus entries MUST be generated. A value of "F" indicates
> that the multistatus response will only contain entries for the
> unsuccessfully processed resources. If the header is not present, then the
> server SHOULD default to a value of "F".
> 
> 	If the Verbose header has a value of "F", and there are no errors to
> be reported, then the server MUST succeed with a 200 OK status code.

Received on Friday, 30 January 1998 03:16:49 UTC