W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2000

Re: [RFC2518 Issue] PROPFIND 'allprop' usage

From: <Tim_Ellison@uk.ibm.com>
Date: Tue, 14 Nov 2000 11:45:31 +0000
To: w3c-dist-auth@w3.org
Message-ID: <80256997.0040A1DC.00@d06mta07.portsmouth.uk.ibm.com>

    We spent a great deal of time debating this issue and have
    come to the following conclusion:

    'Allprop' is not the problem - 'depth: infinity' is the problem.


<tim> I agree that depth infinity is not a good thing.</tim>

    Allprop is a perfectly reasonable, even necessary, request.
    Any client will have a need to know about the complete property
    namespace for a particular resource.  Why then should any
    sensibly written client need to issue a propfind request with
    depth infinity?  Even if the server has the capacity to build
    such a horrendous response, the response would probably crash the
    client when it was received.

I dispute that allprop is necessary.  It is a convenient and even
reasonable short-hand for using propname and retrieving named properties.

The only excuse for a client to issue depth infinity requests is to
off-load the traversal work onto the server.  This is useful if the comms
are an issue, and also if the client is naive (their own depth infinity
traversal would have to retain state, watch out for Loop Detected cases,

However, since there is inherently no limit to the number of properties
that can be set on a resource, the server has the problem of dealing with
potentially large responses (even without depth infinity) provoked by
clients that only sent (numerous) small requests.

Servers could refuse PROPPATCHes once the resource is 'full' thereby
limiting the size of responses.  The definition of 'full' would be a
function of the number of properties, the size of their values, and, for
collections, the 'fullness' of their members.
More likely, servers need some equivalent to 'that request is too expensive
for me to compute--ask me an easier one' status!

    Two possible  solutions arose from our discussions, about which
    we would welcome constructive criticism:

    1- propfind should only be required to accept 'depth:0' and
    'depth:1'.  Clients who really need more information can then
    issue requests as needed to go further into the hierarchy.
    The client will then receive a '501 Not implemented' if it
    attempts something that nasty.

Refusing to implement depth infinity would be fine.  Answering a 501 may be
misleading since it would imply that the PROPFIND method is not
implemented.  It would require some other status condition.

    2- if we have to keep 'depth: infinity', it should not be the

    These suggestions seem reasonable (even ideal!) to us here,
    but we must concede that we may be biased by the needs of
    our own particular project.

I agree it should not be the default.  I think an absent depth header
should default to depth zero, and an absent method body should default to

Received on Tuesday, 14 November 2000 06:53:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:22 UTC