Re: [RFC2518 Issue] PROPFIND 'allprop' usage

On Thu, Nov 23, 2000 at 01:06:16PM +0100, Hartmut Warncke wrote:
> 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.

Eek. You mentioned something about a "sync" feature which uses the
Depth:infinity request. Is that it, or are there other times when you use
that request type? Is the sync feature used often?

Basically, I'm curious about the user impact here. It would be helpful for
me if I understood the end-user impact a bit better.

[ btw, I just sent mail to Stephanie to see if I can get a copy of GoLive 5
  so that I can do some of this interop testing ]

> 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.

Yes... you beat me up on that one already :-(

> 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
> even years).

I've worked on products with release cycles on the order of two years.
Believe me... I understand the issue, and sympathize greatly.

On the other hand, I wasn't interested in releasing mod_dav with a known,
simple, DoS attack (in the default configuration). Admins can always turn
the feature back on, but I'd prefer to see them do it with the understanding
of what it means.

> 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.

Agreed.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Received on Thursday, 23 November 2000 07:26:33 UTC