- From: Wright, Tom <Tom.Wright@gbr.xerox.com>
- Date: Fri, 24 Nov 2000 08:03:38 -0000
- To: "'WebDAV WG'" <w3c-dist-auth@w3.org>
Various replies below Regards Tom Wright Xerox All comments are my own opinions and not really from my company. -----Original Message----- From: Hartmut Warncke [mailto:hwarncke@Adobe.COM] Sent: 23 November 2000 12:06 To: Greg Stein Cc: Hartmut Warncke; WebDAV WG Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Greg, > Given that the default configuration of mod_dav prevents a Depth:infinity > PROPFIND, I'd guess that a rejection of Depth:infinity is a definite > possibility. What does GoLive do when it gets the rejection? Do you simply > skip that feature, send a bunch of Depth:1 requests, or something else? >We do *not* send a bunch of Depth:1 requests, some WebDAV functionality is simply >*not* working in GoLive 5 when the server is not willing to respond to depth infinity >requests. We have simply tried to implement the WebDAV protocol as it is described in >RFC2518 and RFC2518 does *not* allow a server to deny a depth infinity access. At >the point in time when the "DavDepthInfinity" flag was introduced into mod_dav it was >much too late for us to implement such a "bunch of Depth:1 requests"-solution because >we were right before GM. >And I think this is a general problem. There are a lot of very huge products of huge >companies out there which support WebDAV and I am very lucky about that especially >because I think that the idea of WebDAV is very powerful and advanced. But we all have >to keep in mind that a huge product has a well defined life cycle and workflow which >cannot be changed frequently. And of course a product cannot be changed when it is >already in the box. So when some changes take place in the protocol or its important >implementations like mod_dav and this will effect negatively or even break products >which are already in the box or right before GM, a customer who have paid for the >product has to wait at least for the next product release (which will take months or e>ven years). Though Issuing patches is a well known tried an trusted appropach to this kind of problem. >So I think it's very important to get some degree of stability and continuity in the >WebDAV protocol and its implementations which does not mean to let the protocal >unchanged during the next years but we should keep its key features. Otherwise a lot >of companies will think twice before they implement WebDAV support and - without any >doubt - every protocol needs a widespread acceptance from commercial companies and >products to be succesful. All of your responses are missing the point Hartmut. If a server generates a 2 or 4 Gigabyte XML response in response to your thousands of files on the server, 1) its going to hog the server, and even cause it to fail if your building XML in memory, 2) clog the network with traffic and 3) how on earth is the client going to cope with parsing a 2 or 4 gig ( or larger ) XML response, are you simply hoping that you never get a response so large that you cant handle it ? Sending a few hundred byte request ( which may be reasonable to the user ) can result in potentially crippling the server, network or client with unexpectedly large amounts of data, after all most users have no idea of the size of the response before hand. I agree we need to do our best to maintain backwards compatability, but it sounds like your check all in one go approach is a naive implementation. There is simply no need to retrieve more than a directory ( ala depth 1 ) of files/folders properties at a time. Heck you dont even need webdav to do this, using if-modified-since is good enough for files, unless you need to check properties as well. Your arguement about it being efficient is hard to understand. Whats efficent, your use of server and client resources, network band width etc ? I am actually implementing propfind as we speak, and have full sympathy with your position and agree we must not break backwards compatibility, however the current spec is 1) a draft and 2) not considerate of resources, after all they are not infinite. I am suprised greg has not argued the case of infinite depth and got the spec changed!! Maybe the best compromise is as shaun suggested is to have a new status code, saying i have done a depth 1 instead of a depth infinity propfind response, the rest is up to you kind of code, some new 200 code perhaps. The current situation of allowing infinite depth allprop with an unknown number of properties for an unknown number of resources is 'silly'. The protocol is not just for clients, servers have to implement it also, and they need to be able to throatle malicious/unintentional requests which will potentially flood the network and cripple the server/client. As a whole, i hope Jim is reading these emails, as there is clearly a number of people unhappy with the current specification. Maybe it should be changed before the next release? Best regards Tom
Received on Friday, 24 November 2000 03:45:06 UTC