RE: [RFC2518 Issue] PROPFIND 'allprop' usage

Various responses, see below.

> -----Original Message-----
> From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]
> Sent: 22 November 2000 20:00
> To: w3c-dist-auth@w3.org
> Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage
> 
> I have to agree with Shaun that providing an unbounded 
> implementation of
> 'PROPFIND allprops depth infinity' would be brain dead.  
> Similarly, moving
> the goal posts to say that allprops no longer returns all the 
> properties
> would be 'unfavourable' to existing clients and servers.
> 
> The only tenable position is to allow the server to refuse 
> the request,
> either in its entirety (no all props and/or no depth infinity) or by
> allowing it to report partial results (a response status code that
> indicates not all properties were returned, and/or collection 
> members were
> not traversed) for a resource.

Should we keep the issues of PROPFIND with Depth:Infinity and "allprop"
separate threads?

> 
> IMHO, attempting to synchronize thousands of files with a 
> single call to
> the server is not a fantastic idea.

We agree, but unfortunately its in the WebDAV spec and products are based on
it. We think breaking those products would set WebDAV back a bit. Customers
who have paid for products ( sorry Greg :-) ) would not be pleased to find
their product incompatible with the lastest WebDAV server.

> 
> Regards,
> 
> Tim
> 
> 
> Hartmut Warncke <hwarncke@Adobe.COM> on 2000-11-22 04:58:26 PM
> 
> Please respond to Hartmut Warncke <hwarncke@Adobe.COM>
> 
> To:   "Hall, Shaun" <Shaun.Hall@gbr.xerox.com>, WebDAV WG
>       <w3c-dist-auth@w3.org>
> cc:
> Subject:  Re: [RFC2518 Issue] PROPFIND 'allprop' usage
> 

[snipped]

> 
> > Changing the specification could break existing products, 
> which is a bad
> > thing. Backwards compatibilty should be maintained.
> 
> Good to hear that. But I am not quite sure how you will do 
> that because if
> a
> server has the possibility to refuse a depth infinity request 
> GoLive 5 will
> not
> be able to handle that situation (synchronization of client and server
> content
> will not work anymore).

Maintaining backwards compatibility is the challenge for WebDAV spec
authors. We need people's ideas/thoughts/etc on how to do this, taking into
account the exact behaviour of existing products.

For example, use 507 or a new 5xx status code to allow a server to refuse
such a request. Would this break existing products? What would they do in
such situations?

Could vendors of WebDAV clients and even servers (as they could issue these
requests for synchronization purposes) state their products behaviour?

> 
> > We think the way forward for the WebDAV specification is to 
> allow servers
> > the ability to refuse such requests and inform the client. 
> A mechanism
> > should be defined for the client to understand this. If the client
> received
> > a response which basically stated that the server was 
> refusing to service
> an
> > infinite depth request, it could issue multiple requests 
> with a Depth:1.
> 
> If you have to synchronize a very large site with thousands of files,
> replacing
> depth infinity requests by depth 1 requests would be a huge 
> performance
> disaster
> for us.
> 
> Best, Hartmut
> 

Unfortunately its a huge performance disaster on the server as well. What is
the point of this behaviour if the server cannot cope under the load? Server
implementors might choose one of the following:
- server will attempt to perform the request (it may run out of resources
and send an error to the client).
- server will refuse such a request (which deviates from the RFC, but so be
it).

Regards

Shaun Hall
Xerox Europe

Received on Thursday, 23 November 2000 04:38:11 UTC