W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2006

Re: BugZilla issue 213, PROPFIND:infinity

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 04 Feb 2006 10:48:21 +0100
Message-ID: <43E47865.6010805@gmx.de>
To: Wilfredo Sánchez Vega <wsanchez@apple.com>
CC: WebDAV <w3c-dist-auth@w3.org>

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 

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

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