RE: v6 comments - multistatus responses

Oh and the changes also apply to LOCKs on collections.
	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:03:23 UTC