RE: v6 comments - multistatus responses

I have been waiting for someone to complain about not being able to have the verbose information but it seems as though silence indicates that it is not needed although I could imagine some users finding this information useful.

Cheers
Dylan

-----Original Message-----
From:	Yaron Goland [SMTP:yarong@microsoft.com]
Sent:	Friday, January 30, 1998 7:55 AM
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 Tuesday, 3 February 1998 10:36:17 UTC