Re: BugZilla issue 213, PROPFIND:infinity

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

Received on Saturday, 4 February 2006 09:50:44 UTC