Re: BugZilla issue 213, PROPFIND:infinity

   True enough.  I'm happy to see the feature deprecated.  The more I  
think about it, the more it seems like a misfeature.

	-wsv


On Feb 4, 2006, at 1:48 AM, Julian Reschke wrote:

>
> Wilfredo Sánchez Vega wrote:
>>   I could imagine a case where a server starts out by trying to  
>> honor the request, but if the depth level (or number of resources  
>> encountered, or whatever measure they use to judge the cost of  
>> this query) reaches some limit, it bails out and returns an error.
>
> That's conceivable, but not really practical. A server that does  
> support  depth infinity will need to stream the response, and if it  
> does, there's no way to return a non-207 status at a later point  
> (because the response headers already have been sent to the client).
>
>>   I don't know if anyone does this now, but my server does honor  
>> depth: infinity at the moment and I was considering that sort of  
>> thing whenever the time comes that I need to reject such requests.
>>   As such, I'd like the spec to allow for me to reject depth:  
>> infinity requests for some but not all resources.  The old  
>> language seems to imply that I can either reject all or no such  
>> requests if I want to return a propfind-finite-depth error, though  
>> it's not really clear.  The proposed new language looks better,  
>> though perhaps "MAY be disabled" in 9.1 could be written as "MAY  
>> be disabled for some or all resources", or something similar.
>>     -wsv
>
> OK, let's have a different look at this whole issue:
>
> 1) Is anybody aware of a use case where the PROPFIND/depth:infinity  
> can't be substituted by a series on PROPFIND/depth:1 requests?
>
> 2) Is anybody aware of a client that breaks if the server rejects  
> PROPFIND/depth:infinity?
>
>
>
>
> Best regards, Julian