Calendards listed in but not below the home set are not recognized



  • In DAVdroid 0.9.1.3, calendar and address book autodiscovery doesn't work any more, showing a "No address books or calendars were found" error message.

    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. 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/addressbooks/ and /$USER/calendards/, while the collections themselves reside in arbitrary locations, but typically /$USER/addresses/ and /$USER/calendar/; furthermore, the user might have access to other users' resources as well.

    In RFC6352, I couldn't find any hint that the address books must be loated under the home-set. Could you outline to me the purpose of checking hrefSegments against locationSegments?

    It should be possible to work around this in calypso, eg. by resorting to other path components for the home sets (/?%{USER};addressbook-home-set), but I'd prefer to have a good reason if it's actually necessary.



  • I'm attaching a log output of what the situation looks like to davdroid. the log has been redacted for server and other users' details. If more details are required, I can try for more careful redacting, set up a test account, or send a log in private communication.

    0_1458056871265_davdroid-debug1031145928.txt


  • developer

    @chrysn said:

    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.

    Indeed. If 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/addressbooks/ and /$USER/calendards/, while the collections themselves reside in arbitrary locations, but typically /$USER/addresses/ and /$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 hrefSegments against locationSegments?

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


Log in to reply
 

Looks like your connection to Bitfire App Forums was lost, please wait while we try to reconnect.