RE: PROPFIND behaviour regarding collections with non-listable me mbers

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Daniel Brotsky
> Sent: Saturday, October 13, 2001 12:57 AM
> To: Julian Reschke
> Cc: Clemm, Geoff; Webdav WG
> Subject: RE: PROPFIND behaviour regarding collections with non-listable
> me mbers
>
>
> At 9:03 PM +0200 10/12/01, Julian Reschke wrote:
> >Well,
> >
> >that's something we could do, but that would hide the difference
> between a
> >collection that's empty and a collection where you don't have "list"
> >permission to.
>
> When security is so tight that people aren't allowed to even know
> about the existence or non-existence of members, these cases (a
> collection that's empty versus one that contains members "invisible
> to you") aren't supposed to be distinguishable.  To see this,
> consider the case where a collection has some visible and some
> invisible members (from a particular user's point of view): just the
> visible members should be listed.
>
> But I think there's an entirely different spec issue here: whether or
> not DAV collections can hide the existence of members at all.
> Section 8.1 on PROPFIND says:

I think this is exactly the reason why I got to my current approach.

>     Consequently, the multistatus XML element for a collection resource
>     with member URIs MUST include a response XML element for each member
>     URI of the collection, to whatever depth was requested. Each response
>     XML element MUST contain an href XML element that gives the URI of
>     the resource on which the properties in the prop XML element are
>     defined.
>
> This seems to require you either:
>
> a. to list the members and then say 403 for any properties, or

...I think I remember this will break existing clients like Adobe GoLive
([1]) that expect the (live) property to be either returned *with* value, or
to be silently dropped.

>
> b. to return 403 for any PROPFIND with depth > 0 on the
> containing collection.
>
> Note that neither of these options meets the security requirements of
> "a user must not be able to determine whether or not a collection has
> a given member," but I don't think that 2518 intended to make it
> illegal for servers to enforce this kind of security.  So I think
> there is a spec issue here.

So obviously we've got a spec issue here, and it probably should be resolved
together with:

[1] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0248.html>

Received on Saturday, 13 October 2001 05:36:47 UTC