RE: [RFC2518 Issue] PROPFIND 'allprop' usage

Hi,

We've discussed this and don't think that servers should compromise as
you've suggested.

Even if you permitted what you've suggested, the response could still
potentially be very large (depending on the non-locking properties defined
and the number of resources). We feel that the locking properties form only
a small number of all the properties stored.

If a client issues an "allprop", it should get all the properties defined.
Allowing the server to chooose what properties to return seems to convulent
the RFC/specification for example:
- how would the client know whether it actually received all the properties?
- would the client have to make further PROPFIND requests to retrieve the
extra properties?

If people want to allow the server to return a "subset" of all the
properties for an "allprop", the specification should "partition" the
potential response "in concrete" so there is no room for interpretation for
example:
- the server MUST return the WebDAV properties.
- the server MAY return all other properties. However, if it chooses to
return the non-WebDAV properties, it MUST return all non-WebDAV properties.
- if the specification allows servers to choose what properties to return,
there must be some well defined mechanism for the client to be able to
retrieve the non-returned proprties.

People must realise that allowing "allprop" with a depth infinity is going
to generate potentially large responses (which could be denial of service
attacks). If people don't like this, then consider dropping "infinite" depth
requests from the specification. This assumes that it doesn't break existing
products and one response for one product isn't necessarily a good
response/sample.

Regards

Shaun Hall
Xerox Europe

> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: 21 November 2000 16:46
> To: Hartmut Warncke; WebDAV WG
> Subject: 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 Wednesday, 22 November 2000 03:40:35 UTC