Re: Issue: ALLPROP_AND_COMPUTED

"Jason Crawford" <ccjason@us.ibm.com> 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

Received on Friday, 4 May 2001 18:54:46 UTC