- From: Hartmut Warncke <hwarncke@Adobe.COM>
- Date: Wed, 22 Nov 2000 14:12:16 +0100
- To: Lisa Dusseault <lisa@xythos.com>
- CC: WebDAV WG <w3c-dist-auth@w3.org>
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