Subject: BugZilla issue 213, PROPFIND:infinity

From: Julian Reschke <[email-masked]>
Date: Fri, 03 Feb 2006 22:07:36 +0100

Hi,

(see <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=213> for 
history).

We discussed this issue during today's conference call, and the 
remaining issue seems to be:

If a server decides not to implement or support PROPFIND/Depth:infinity, 
is it allowed to do that generally (meaning that any 
PROPFIND/Depth:infinity request will be rejected independently of 
whether the resource at the request-URI is a collection, or the 
collection happens to be "small"), or is it required to first check that 
the Request-URI indeed identifies a collection, and the full collection 
contents is indeed to expensive to return?

I think the former represents what servers do today, and this means 
clients can't rely on PROPFIND/Infinity support in any way. As a matter 
of fact, I think clients cope with that already, and there's really no 
problem in just stating this (AFAIK, Apache/moddav is shipping 
configured that way).

Requiring servers to check whether the resource is a collection, and to 
decide on whether it would be too expensive to do seems like an 
unrealistic requirement, because it may be almost as expensive as 
executing the PROPFIND.

Feedback appreciated,

Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 3 Feb 2006 14:22:54 -0800

I had previously misunderstood what we'd discussed and thought we'd  
allow PROPFIND depth infinity requests to be rejected IF they posed a  
performance problem.  Allowing them to be rejected consistently is,  
IMO, effectively deprecating PROPFIND Depth Infinity, because then  
clients couldn't rely on it.

That is possibly a fine thing.  If we learned that most clients don't  
use it anyway, then we could deprecate PROPFIND depth infinity and  
servers wouldn't even have to worry about implementing it at all.

Lisa

On Feb 3, 2006, at 1:07 PM, Julian Reschke wrote:

>
> Hi,
>
> (see <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=213>  
> for history).
>
> If a server decides not to implement or support PROPFIND/ 
> Depth:infinity, is it allowed to do that generally (meaning that  
> any PROPFIND/Depth:infinity request will be rejected independently  
> of whether the resource at the request-URI is a collection, or the  
> collection happens to be "small"), or is it required to first check  
> that the Request-URI indeed identifies a collection, and the full  
> collection contents is indeed to expensive to return?
>
> clients can't rely on PROPFIND/Infinity support in any way. As a  
> matter of fact, I think clients cope with that already, and there's  
> really no problem in just stating this (AFAIK, Apache/moddav is  
> shipping configured that way).
>
> Requiring servers to check whether the resource is a collection,  
> and to decide on whether it would be too expensive to do seems like  
> an unrealistic requirement, because it may be almost as expensive  
> as executing the PROPFIND.
>
> Feedback appreciated,
>
> Julian
>
>

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Fri, 3 Feb 2006 18:52:32 -0800

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.

   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

---

From: Julian Reschke <[email-masked]>
Date: Sat, 04 Feb 2006 10:43:57 +0100

Lisa Dusseault wrote:
> performance problem.  Allowing them to be rejected consistently is, IMO, 
> effectively deprecating PROPFIND Depth Infinity, because then clients 
> couldn't rely on it.

Yes, we discussed that very issue. Requiring the server to execute the 
PROPFIND if it happens to be cheap is not only bad spec writing (how 
would you do a compliance test?), it also doesn't make sense (in many 
cases, even counting the descendants of a collection will be almost as 
expensive as returning them -- the recursion is the problem!).

Furthermore, servers today already work this way (they are *configured* 
to reject PROPFIND/infinity in any case), and I'm not aware of any 
client problems because of that.

> servers wouldn't even have to worry about implementing it at all.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 04 Feb 2006 10:48:21 +0100

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

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Sat, 4 Feb 2006 08:45:13 -0800

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:

>> 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).
>
>> 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
>