RE: [RFC2518 Issue] PROPFIND 'allprop' usage

unsubscribe 

(sorry if this goes to the list, I forgot to record the admin address)

> -----Original Message-----
> From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]
> Sent: Wednesday, November 22, 2000 12:00 PM
> 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.
> 
> IMHO, attempting to synchronize thousands of files with a 
> single call to
> the server is not a fantastic idea.
> 
> 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
> 
> 
> 
> 
> 
> 
> > The implications of PROPFIND with an infinite depth affect both the
> server
> > and/or the client. Supposing you have a large WebDAV 
> enabled repository.
> The
> > PROPFIND request (a few hundred bytes) could potentially 
> mean that (tens
> of)
> > GBs of data is to be returned. Even if the server could 
> generate such a
> > large response (which is a feat in its own right), it will load the
> network,
> > and what will happen when the client receives it? Pity the poor user
> sitting
> > there for a long time (hours?), only to be told "timed out" 
> or "out of
> > memory" or something similar.
> 
> Yes, of course, I completely understand your point of view. 
> But as a matter
> of
> fact we like this "depth infinity" feature very much because 
> we can use it
> in a
> very efficient way in some situations and therefore we are 
> struggleing so
> hard
> for keeping that feature.
> 
> > 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).
> 
> > 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
> 
> 
> 
>