Subject: [RFC2518 Issue] PROPFIND 'allprop' usage

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 10 Nov 2000 10:40:14 -0800

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

---

From: Hartmut Warncke <[email-masked]>
Date: Mon, 13 Nov 2000 13:06:57 +0100

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

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 13 Nov 2000 07:49:44 -0800

This is very good feedback.

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?  Have you tested this against various servers?
Does it work with all of them?

I'd point out that even if the RFC weakens the requirements for supporting
'allprop', existing (shipped) implementations are not going to change, and
when new versions come out, they may still support verbose 'allprop' (there
will be nothing in the RFC to prevent verbose 'allprop' responses).

Lisa

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]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,
>
> >  -
> http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0092.html
> >  -
> http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0310.html
> >
> >  -
> http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0008.html
> >  -
http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0075.html

---

From: Hartmut Warncke <[email-masked]>
Date: Mon, 13 Nov 2000 17:06:41 +0100

> a specific webDAV server?

On  **any** WebDAV server.

> Have you tested this against various servers?

Yes, it's working against IIS and mod_dav for example.

Best, Hartmut

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 21 Nov 2000 08:45:36 -0800

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

> From: Hartmut Warncke [mailto:[email-masked]]
> Sent: Monday, November 13, 2000 8:07 AM
> To: Lisa Dusseault
> Cc: WebDAV WG
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0101.html
> >
> > Several server implementors have voiced the opinion that 'allprop'
should
> be
> > These seem to be our options for modifying RFC2518 (remember, it has to
be
> a

---

From: Hartmut Warncke <[email-masked]>
Date: Wed, 22 Nov 2000 14:12:16 +0100

Lisa,

> 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.

> non-locking-related properties defined in RFC2518 presently).

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

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sun, 26 Nov 2000 09:41:10 -0800

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

> Sent: Wednesday, November 22, 2000 5:12 AM
> To: Lisa Dusseault
> Cc: WebDAV WG
> > > > > Also in ACLs, Babich argues that clients who request
> 'allprop' don't
> > > > really
> > > > of standard or custom properties that must be calculated by
> the server
> > > (e.g.
> > > > returned in 'allprop'?  If the properties relied upon
> include any more
> > > than
> > > > 'propname', for property discovery?  This would be a more
> serious issue
> > if
> > > > major client implementations actually rely on doing
> property discovery
> > > using

---

From: Hartmut Warncke <[email-masked]>
Date: Mon, 27 Nov 2000 10:55:39 +0100

Lisa,

> I'm still a little confused -- Does GoLive do PROPFIND depth-infinity

No, we only use PROPFIND-PROP requests for specific properties with depth
infinity.

> depth-infinity requests for _specific_ (named in request) properties, just

I am not quite sure if this is the opinion of all members on this list. I think
a lot of people want to cut off depth infinity at all.

Best, Hartmut