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 Monday, 13 November 2000 11:07:48 UTC