RE: [RFC2518 Issue] PROPFIND 'allprop' usage

I'm still a little confused -- Does GoLive do PROPFIND depth-infinity
'allprop' requests?

Nobody's talking about removing (or cutting back) support for PROPFIND
depth-infinity requests for _specific_ (named in request) properties, just
for 'allprop'.

Lisa

> -----Original Message-----
> From: Hartmut Warncke [mailto:hwarncke@Adobe.COM]
> Sent: Wednesday, November 22, 2000 5:12 AM
> To: Lisa Dusseault
> Cc: WebDAV WG
> Subject: 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 Sunday, 26 November 2000 12:39:16 UTC