- From: <Tim_Ellison@uk.ibm.com>
- Date: Tue, 14 Nov 2000 11:45:31 +0000
- To: w3c-dist-auth@w3.org
<Richard> 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. </Richard> <tim> I agree that depth infinity is not a good thing.</tim> <Richard> 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. </Richard> <tim> 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, etc.). 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! </tim> <Richard> 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. </Richard> <tim> 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. </tim> <Richard> 2- if we have to keep 'depth: infinity', it should not be the default. 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. </Richard> <tim> 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 propnames. </tim> Tim
Received on Tuesday, 14 November 2000 06:53:07 UTC