RE: [RFC2518 Issue] PROPFIND 'allprop' usage

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?

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?

Lisa

> -----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 Tuesday, 21 November 2000 11:43:33 UTC