Subject: Re: Issue: ALLPROP_AND_COMPUTED

From: [email-masked]
Date: Fri, 4 May 2001 23:52:05 +0100

"Jason Crawford" <[email-masked]> wrote:
> <<
> I think the key part of Geoff's post is "the subset that it can use".
The
> problem with allprop is that it will return all the live properties
> irrespective of whether the client is aware of the properties' semantics.
> Sometimes this is what the client wants, say if it is naively displaying
a
> property sheet; but most likely it is not since there is no way for the
> client to interpret the values or know if/how they can be changed.
> >>
> Actually I'd think that property sheet case would be pretty common.

It may be common, but it isn't very interesting, especially since a client
likely cannot display the value in a meaningful way or update the value.

> And
> removing allprop isn't going to prevent people from doing the same
thing...
> now with two requests rather than one.  And sometimes for wide
directories
> it will be difficult to avoid this (suspected) problem even without
> ALLPROP.

No dispute that people can write dumb and/or harmful clients.

> If this is actually the pivotal concern, I think the best you can
> do just warn people of the potential cost that we see of using allprop.
> From there on in, let time tell if it's really a problem.  If we discover
> it is, let's *really* solves the problem then.  I'm willing to remove
> ALLPROP, but it doesn't sound like doing that really would solve the
> problem and it's not clear if there is a problem.

I'm actually indifferent to removing allprop -- but I do think that the
default for no body and no Depth: header being allprop depth infinity is
bizzare.

> > It's the old NRA argument -- allprop doesn't kill servers, clients kill
> > servers ;-)
> At first I thought that analogy was flawed, but as I think about it, I
> think that the situation is analogous.  This discussion seems to have all
> of the same aspects.  The differences I see are...
>
> 1) I don't think it's clear that there actually is a problem in 2518 that
> we need to solve.
> 2) In 2518, the people that would be vicitimized by the concern are
> actually in (more) control over whether they are vulnerable.  (Client
> programers can discover that they don't really want all those random
> properties and perhaps conclude that it's slowing their response time and
> stop using ALLPROP.  I think clients can disconnect if a response is too
> long.  And I think servers (with guidance from us) can chose to reject
> certain requests if they really feel that they are too expensive.)
>
> <<
> I have to agree that it is a stealth action to undermine (the effects of)
> allprop.
> >>
> I'm guessing you're joking, but I'd like to hear why that was put in that
> spec.  Was there some issue involved that we haven't mentioned here?

Not really.  Delta-V was spec'd to not return all versioning properties in
allprop requests _because_ it was felt that the response would be too
expensive for servers to compute, and the scenarios where a client can
really make use of all the versioning values taken at a point in time are
limited if not minimal.

If the issue is tackled in RFC2518 then there would be less incentive for
Delta-V to take such a stance.

> As it stands now, I have a mild preference for leaving allprop in.  I'm
> *very* willing to support another position if it will bring us to
agreement
> and not do any serious damage.
>
> J.
>

Tim

---

From: Greg Stein <[email-masked]>
Date: Fri, 4 May 2001 18:14:34 -0700

> default for no body and no Depth: header being allprop depth infinity is

That was an unfortunate choice. Even worse, I'm not sure how we can change
that without breaking clients and servers across the globe.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sat, 5 May 2001 18:10:59 -0700

> that without breaking clients and servers across the globe.
Easy, even if it were needed.  Redefine "allprop" as "all properties defined
in 2518".

But I question whether it's needed.  Since not all servers return all
RFC2518 properties in response to allprop (e.g. not returning
DAV:lockdiscovery), and since obviously clients and servers across the globe
aren't already broken, is any client relying on allprop for getting all
properties?

lisa

---

From: Hartmut Warncke <[email-masked]>
Date: Mon, 07 May 2001 11:19:06 +0200

Lisa,

> aren't already broken, is any client relying on allprop for getting all

GoLive 5 uses "PROPFIND ALLPROP" (with depth 0/1) for retrieving properties of
resources on the server; we are  *not*  using "ALLPROP" with "depth infinity"
(but - btw - we are using "PROPFIND PROP" with "depth infinity"). It should be
not a big deal for us to replace our "PROPFIND ALLPROP" with "PROPFIND PROP" in
future releases. Therefore - regarding future releases - it's not a big problem
for us if "ALLPROP" does not longer exist in the spec.

On the other hand:
GoLive 5 is using "ALLPROP" so - for compatiblity reasons - its  *very*
important that existing servers keep there support for "ALLPROP" for a while;
GoLive 5 relies on "ALLPROP" and  is  *not*  able to work with a server which
does not support "ALLPROP".

Best, Hartmut

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 9 May 2001 16:09:18 -0700

> I continue to believe that rough consensus exists to change the default
> behavior of PROPFIND away from the current specification.  The
> default Depth
> value should be 0, not infinity (or an error should be reported).

I hope you mean default depth=0 for PROPFIND, not for MOVE and COPY.
(PROPPATCH should default to the same as PROPFIND though).

lisa

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 9 May 2001 16:12:58 -0700

> (PROPPATCH should default to the same as PROPFIND though).

Yes, my comments apply solely to PROPFIND.

You are right, though, default Depth values for other methods should also be
revisited.

- Jim

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 9 May 2001 15:36:43 -0700

Let me see if I can summarize points of agreement from the recent discussion
concerning PROPFIND ALLPROP. If you disagree with this summary, please send
a message to the list (a) explaining the difference, and (b) describing what
*you* believe is the rough consensus.

Problem Statement
-----------------

PROPFIND ALLPROP Depth infinity places a significant processing load on some
server implementations. Apache mod_dav provides an option limiting PROPFIND
ALLPROP Depth infinity for just "core" (RFC 2518-defined) properties. The
DeltaV specification introduces several new properties that (a) are
expensive to compute, and (b) not capable of interpretation by non-DeltaV
clients.

It is generally believed that PROPFIND ALLPROP Depth 1 is less likely to
incur a large processing load on the server than PROPFIND ALLPROP Depth
infinity. However, it is possible to have a deep hierarchy with few
resources, and a single collection with many resources, and hence there is
no guarantee that PROPFIND ALLPROP Depth 1 will be less computationally
expensive than PROPFIND ALLPROP Depth infinity. Thus, if the goal is:
"reduce the likelihood that a client request will result in a
computationally expensive server operation", then PROPFIND ALLPROP Depth
infinity and Depth 1 will both need to be addressed.

Both the DeltaV and the Access Control specifications limit the properties
returned by PROPFIND ALLPROP (of any depth). This effectively changes the
semantics of PROPFIND ALLPROP.

Client implementors involved in this discussion indicate that they have
dependencies on PROPFIND ALLPROP at Depth 0/1. To date, there have been no
reported cases of client dependencies on PROPFIND ALLPROP Depth infinity.

At present, RFC 2518 states two default behaviors for PROPFIND:
(a) a request without a Depth header should be treated as if it is Depth
infinity.
(b) a request without a body should be treated as a PROPFIND ALLPROP
To date, there have been no reported cases of clients depending on this
default behavior.

Solution Space
--------------

I continue to believe that rough consensus exists to change the default
behavior of PROPFIND away from the current specification.  The default Depth
value should be 0, not infinity (or an error should be reported). The
default computation should be PROPNAME, not ALLPROP (or an error should be
reported).

I detected no consensus on how to address the PROPFIND ALLPROP Depth
1/infinity issue. Assuming this group does not come to consensus, I believe
the following will happen:

- The revision of 2518 will contain an implementation note concerning the
effects of PROPFIND ALLPROP at Depth 1/infinity
- The DeltaV and ACL specifications will contain language prohibiting the
return of certain properties (i.e., properties defined in each
specification) for any PROPFIND ALLPROP.
- Server implementations (such as mod_dav) will continue to have
configuration options limiting PROPFIND ALLPROP Depth infinity.

- Jim

---

From: Hartmut Warncke <[email-masked]>
Date: Thu, 10 May 2001 11:04:26 +0200

> ALLPROP Depth infinity for just "core" (RFC 2518-defined) properties.

If you mean the mod_dav "DAVDepthInfinity" configuration flag here, this applies
- as far as I know - to all PROPFIND Depth infinity requests, not only to
PROPFIND ALLPROP Depth infinity. So, if this flag is set to "off" (the default
value), the client is not allowed to send a PROPFIND PROP Depth infinity.

Greg, will this change in future releases of mod_dav? So, will the
"DAVDepthInfinity" configuration only apply to ALLPROP?

Best, Hartmut