Re: [RFC2518 Issue] PROPFIND 'allprop' usage

Lisa,


> One more question, because maybe, as Richard Humphreys suggests, "depth
> infinity" is the problem.
>
> Hartmut, does GoLive5 use depth: infinity PROPFIND requests at all?  If yes,
> does it use them for custom property discovery?

Yes, GoLive uses those infinity requests because it's a very effiicient way to
synchronize the WebDAV server content with the content of a site on the local
machine with  *o n e*  network request. We are requesting build-in DAV
properties (like "getlastmodified" or "lockdiscovery") as well as custom
properties (which were PROPPATCHED by GoLive before) with depth infinity.

To my mind depth infinity requests are -from the client perspective - a very
efficient and interesting WebDAV feature.
Dropping  infinite requests would break GoLive 5!

By the way if a server would be allowed to refuse depth infinity requests (like
mod_dav with its "DavDepthInfinity" flag in its configuration file), the client
needs a mechanism to figure out if the server is willing to respond to depth
infinity requests or not. This mechanism has to be precisely defined by RFC2518.



> If not, then we could compromise our way through this by stating that a
> WebDAV server SHOULD (MUST?) respond to a PROPFIND depth-0 'allprop' request
> with all custom properties, but that it MAY respond to a PROPFIND depth>0
> 'allprop' request with a more limited set of properties (suggested to be the
> non-locking-related properties defined in RFC2518 presently).
>
> Would that work?

I think "allprop" should always return all properties (custom and DAV build-in).
Perhaps it makes sense to drop PROPFIND-ALLPROP requests with depth infinity but
please keep the PROPFIND-PROP requests with depth infinity because they are a
very powerful and efficient instrument. Dropping those requests would lead us
-in some situations- into a time consuming disaster with a huge amount of
network traffic.

Best, Hartmut


> > -----Original Message-----
> > From: Hartmut Warncke [mailto:hwarncke@Adobe.COM]
> > Sent: Monday, November 13, 2000 8:07 AM
> > To: Lisa Dusseault
> > Cc: WebDAV WG
> > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage
> >
> >
> >
> >
> > > To clarify, does the GoLive 5 WebDAV client rely on using
> > PROPFIND 'allprop'
> > > requests to get all custom properties on **any** webDAV server?
> >  or against
> > > a specific webDAV server?
> >
> > On  **any** WebDAV server.
> >
> > > Have you tested this against various servers?
> > > Does it work with all of them?
> >
> > Yes, it's working against IIS and mod_dav for example.
> >
> > Best, Hartmut
> >
> >
> > > > -----Original Message-----
> > > > From: w3c-dist-auth-request@w3.org
> > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Hartmut Warncke
> > > > Sent: Monday, November 13, 2000 4:07 AM
> > > > To: Lisa Dusseault; WebDAV WG
> > > > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage
> > > >
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > I have major concerns regarding the change of  the response
> > on a PROPFIND
> > > > 'allprop' request in the way you described it.
> > > >
> > > > Such a change would be  *v e r y  harmful*   for the GoLive 5
> > > > WebDAV client.
> > > > When we send a PROPFIND 'allprop' request we expect all
> > > > properties which are
> > > > defined on the resource, especially  the Lockproperties and all custom
> > > > properties defined by GoLive 5 (which we have PROPPATCHED before).
> > > >
> > > > We are probably able to replace PROPFIND 'allprop' requests by
> > > > PROPFIND 'prop'
> > > > requests in future GoLive releases (which would be indeed much
> > > > more efficient)
> > > > but the suggested change in the protocol would be a  *disaster*
> > > > for GoLive 5
> > > > which is already in the box.
> > > >
> > > > Best, Hartmut
> > > >
> > > >
> > > > Lisa Dusseault wrote:
> > > >
> > > > > Past discussions have shown that servers frequently have trouble
> > > > > implementing PROPFIND 'allprop'.  Jim asked me to summarize the past
> > > > > discussion & list the open issues so that we can get this
> > > > fixed, if it can
> > > > > be fixed, in revisions to 2518.
> > > > >
> > > > > There are already cases where not all properties will be returned:
> > > > > RFC2518: "In the case of allprop and propname, if a principal
> > > > does not have
> > > > > the
> > > > >    right to know whether a particular property exists then
> > the property
> > > > >    should be silently excluded from the response."
> > > > >
> > > > > John Stracke's proposal for reducing/specifying the scope of
> > > > 'allprop', and
> > > > > discussion of the motivation:
> > > > >  -
> > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0092.html
> > > > >  -
> > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0310.html
> > > > >
> > > > > It has been a point of discussion for Advanced Collections:
> > > > >  -
> > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0008.html
> > > > > "Clients need to know whether the property is computed on
> > the fly before
> > > > > requesting it.  There is no way to find out.  The impact of
> > > > computing on the
> > > > > fly is especially significant when a client requests allprop.
> > > > There may be
> > > > > other properties that are computed on the fly as well.
> > DAV:getetag is
> > > > > computed, and some versioning history properties may also
> > be computed."
> > > > >
> > > > > Also in Versioning:
> > > > >  -
> > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0075.html
> > > > "There has also been a massive growth in the number of available DAV
> > > > properties.  PROPFIND allprop operations may lead to very large
> > > > responses even with Depth: 1, which would slow down performance
> > > > for users due to network speeds.  It might be worthwhile to add this
> > > > facet to the open issue ALLPROP_AND_COMPUTED."
> > > >
> > > > Also in ACLs, Babich argues that clients who request 'allprop' don't
> > > really
> > > > want to see the ACL property, thus they ought to specifically
> > ask for it.
> > > >  -
> http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0101.html
> > >
> > > Several server implementors have voiced the opinion that 'allprop'
> should
> > be
> > > "put out of its misery" (GMC) or at least weakened.  Often this is
> because
> > > of standard or custom properties that must be calculated by the server
> > (e.g.
> > > 'lockdiscovery'), and the calculation can become extraordinarily
> expensive
> > > with an 'allprop' of depth: infinity.
> > >
> > > The only server-side argument for keeping 'allprop' is that
> > server-to-server
> > > COPY requires it; but if anybody has implemented this yet and can't use
> > > 'propname' instead, please speak up.
> > >
> > > Summary:
> > > There thus seems to be a consensus among server implementors and those
> > > designing new features for DAV.  What's missing in order to resolve this
> > > issue for fixing RFC2518 is input from clients.
> > >
> > > 1.  Is anybody aware of clients that rely on particular properties being
> > > returned in 'allprop'?  If the properties relied upon include any more
> > than
> > > the set DAV:{creationdate, displayname, getcontentlanguage,
> > > getcontentlength, getcontenttype, getetag, getlastmodified} (the
> > properties
> > > required for DAV level 1 support) I would be very surprised.  Thus,
> > servers
> > > may be able to restrict the required property set to this set.
> > >
> > > 2.  Is anybody aware of clients that rely on 'allprop', rather than
> > > 'propname', for property discovery?  This would be a more serious issue
> if
> > > major client implementations actually rely on doing property discovery
> > using
> > > 'allprop', and attempt this against various implementations of WebDAV
> > > servers.
> > >
> > > These seem to be our options for modifying RFC2518 (remember, it has to
> be
> > a
> > > simple mod):
> > >  - deprecate 'allprop' and tell clients not to use it, but to use
> > 'propname'
> > > instead
> > >  - define 'allprop' to be the set of properties required for DAV level 1
> > > support (although servers could freely return more properties if
> desired)
> > >  - explicitly allow servers to return an error code (507?) for
> properties
> > > that were too expensive to calculate for a 'allprop' request, but still
> > > allowing the client to do property discovery through 'allprop'
> > >
> > > Please voice your preferences among these options, objections, or other
> > > ideas.
> > >
> > > thanks,
> > > Lisa
> > > Xythos

Received on Wednesday, 22 November 2000 08:13:22 UTC