Re: BugZilla issue 213, PROPFIND:infinity

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

Received on Friday, 3 February 2006 22:23:01 UTC