RE: [RFC2518 Issue] PROPFIND 'allprop' usage

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