RE: [RFC2518 Issue] PROPFIND 'allprop' usage

I think this should be split into 2 threads (as someone suggested earlier)
and so I will attempt to do so here :)

1)  Depth infinity searches.

I can see some very good uses for depth infinity searches and can also see
the large DOS attack.   To alleviate the situation I will suggest (again)
that we add a 507 Insufficient Storage status code response to a Propfind.
This will allow a server to respond with partial results when the result set
is to large.  This was how DASL suggested that servers handle the Result Set
Truncation possibility of searches that were to large, and since Propfind is
nothing but a limited search, I believe the 507 works well in this case
also.

In this way the server is free to answer as much as they can, and still give
a proper error condition.  In cases where the depth infinity is not rather
large, the 207 is returned as normal.  In the case of LARGE depth infinity
propfinds, the 507 is returned with partial propfind data.

Kevin

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Wright, Tom
Sent: Friday, November 24, 2000 12:04 AM
To: 'WebDAV WG'
Subject: 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 Sunday, 26 November 2000 18:01:23 UTC