PROPFIND Depth:1 and ACLs

Hi folks,
Say I have a collection that has DAV:read privilege for 
DAV:unauthenticated, and two resources, A and B in that collection. 
Resource A has DAV:read for the DAV:unauthenticated, but resource B does 
not (it has DAV:read for DAV:authenticated).

Now lets say that user does a PROPFIND Depth:1 on the collection. What 
should the multi-status response contain? Obviously an entry for the 
collection and one for resource A. But should there be a DAV:response for 
resource B? Certainly if there is, it ought not to include any requested 
properties, but if that is the case should the response simply not contain 
any properties at all, or list all properties as Forbidden?

My opinion is that resource B should not be listed at all in the PROPFIND 
Depth:1 results - if you can't read the resource content or properties you 
should not be able to see it at all in a directory listing. Other people 
have suggested that it ought to be returned in the propfind to at least 
alert someone that it is there.

The real problem is this: say I have a WebDAV browser and point it at the 
collection. Since unauthenticated access is allowed there, the browser can 
do an unauthenticated PROPFIND Depth:1 to list the collection contents (the 
server won't prompt for authentication). Using my approach, resource B 
would not appear in the listing. Thus a user who could authenticate and see 
resource B, would actually never be able to if they just relied on the 
"on-demand" nature of HTTP authentication. Using the other approach, 
resource B would be listed, and if a user clicked it in the browser they 
would be able to access it if they authenticate when the server prompts for 
that.

Any suggestions on how best to deal with this?

-- 
Cyrus Daboo

Received on Wednesday, 11 April 2007 17:21:24 UTC