Re: PROPFIND Depth:1 and ACLs

Werner Donné wrote:
> 
> Hi,
> 
> Section 8.2 of RFC 2518bis has two paragraphs which say:

9.1.

> "If there is an error retrieving a property then a proper error
>  result MUST be included in the response.  A request to retrieve the
>  value of a property which does not exist is an error and MUST be
>  noted, if the response uses a multistatus XML element, with a
>  response XML element which contains a 404 (Not Found) status value.
> 
>  Consequently, the multistatus XML element for a collection resource
>  with member URLs MUST include a response XML element for each member
>  URL of the collection, to whatever depth was requested. Each
>  response XML element MUST contain an href XML element that gives the
>  URL of the resource on which the properties in the prop XML element
>  are defined.  URLs for collections appearing in the results MUST end
>  in a slash character.  Results for a PROPFIND on a collection
>  resource with internal member URLs are returned as a flat list whose
>  order of entries is not significant."
> 
> This mandates a response element for resource B.
> 
> It further also says:
> 
> "Properties may be subject to access control. In the case of allprop
>  and propname, if a principal does not have the right to know whether
>  a particular property exists then the property should be silently
>  excluded from the response."
> 
> This still doesn't allow for omitting a response element. At most a
> property can be left out.

I think you're reading the spec correctly, but I'm going to say this is 
not what the intention was, and certainly is not what many servers 
implement. It seems to me that this needs to be corrected.

> My conclusion is that when you have the read privilege on a collection,
> you have the right to see its entire contents, i.e. all of its members.
> There is no notion of a partial read privilege.

Personally I agree this the more sound approach, but I'm pretty sure 
many implementors disagree and just hide the entries. I think we need to 
allow that.

> The problem, however, is that there is no method to retrieve the
> contents of a collection. You have to use PROPFIND with which you
> can't request for an empty set of properties. You have to ask for
> something, which means you always request the collection contents
> together with information about its members. In the case the principal

That's correct; and I think we should have relaxed that. An empty <prop> 
element should be allowed; clients could easily test for that by just 
trying it and analyzing the result; it's it's 207, the server understood 
the request..

> doesn't have the read privilege for some member, a 403 status code should
> be placed in its response element. According to the content model

That's what the SAP KM WebDAV server is doing.

> of the "response" element it can be done with a "status" element
> directly under "response", so no property names have to be exposed.
> It anyway doesn't make sense to set the status for each property,
> because RFC 3744 doesn't allow to set privileges on individual
> properties.
> 
> Note that having to use PROPFIND to retrieve the contents of a
> collection has a serious impact on performance when ACLs are supported.

Could you a be a bit more specific? Would a PROPFIND where just the 
member names are being returned sufficient?

Best regards, Julian

(adding to new issues to 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html>)

Received on Monday, 14 May 2007 21:07:09 UTC