I’ve gone through the logs, comparing them with dav4android sources, and it appears to me that parseMultiStatus_Response, in the sameBasePath area, ignores all properties that are not children of the queried resource in terms of path.
PROPFIND is done on a resource, the response is expected to contain information about this resource (and its children, if
Depth is greater than zero). If the server is queried about
/a, why should information about
/b be taken into consideration? See RFC 4918 PROPFIND:
The PROPFIND method retrieves properties defined on the resource identified by the Request-URI, if the resource does not have any internal members, or on the resource identified by the Request-URI and potentially its member resources, if the resource is a collection that has internal member URLs.
This sounds very reasonable to me.
In RFC6352, I couldn’t find any hint that the address books must be loated under the home-set.
As I read it, RFC 6352 addressbook-home-set even describes this as the purpose of the addressbook-home-set:
Purpose: Identifies the URL of any WebDAV collections that contain address book collections owned by the associated principal resource.
Description: […] Typically, users will group all the address book collections that they own under a common collection. This property specifies the URL of collections that are either address book collections or ordinary collections that have child or descendant address book collections owned by the principal.
Furthermore you say:
This conflicts with the calypso server’s address layout of having the current user principal at /$USER/, and each user’s home sets at
/$USER/calendards/, while the collections themselves reside in arbitrary locations, but typically
/$USER/calendar/; furthermore, the user might have access to other users’ resources as well.
As quoted above, the address book home set is defined as a collection that should contain the address books.
Could you outline to me the purpose of checking
The purpose of PROPFIND is to get properties of a resource, and maybe its children, but not the properties of some random, not requested resources (regardless of whether the server thinks they might be interesting). dav4android’s
DavResource represents a WebDAV resource and therefore stores
- its properties (
public final PropertyCollection properties = new PropertyCollection()),
- and its (direct) members (
public final Set<DavResource> members = new HashSet<>()), which are
DavResources themselves and thus can store properties and members again.
Properties which are not related to either the requested resource or its members are useless, can’t be stored and can’t be processed by the calling method (because the calling method wants to get the properties of exactly the resource it requests – this is why it requests them).