shared xDAV resources
Savvas Karagiannidis
karagian at dataways.gr
Tue Apr 10 04:24:39 EDT 2018
Hi all,
I work at a small company that is also very interested in the shared
calendars and addressbooks functionality.
We did many tests and we came to the same conclusions about iOS devices
mentioned here. The pull request Ellie mentioned
(https://github.com/cyrusimap/cyrus-imapd/pull/2307) was a bug that was
discovered during that testing.
I am not an expert on DAV either, but me and the company I work for are
also willing to also contribute in any way.
I must mention that we also tested shared calendars and addressbooks on
android devices using DAVdroid. DAVdroid seems to work almost the same
way as iOS devices (using principal URL, discovering all user's
collections), but when using a shared collection URL as the account URL,
that shared collection is also included in the available collections
exposed by the app. The ideal would be for all shared collections the
user has access to, to be discovered via a single URL.
Also, from iOS devices, besides "PROPFIND /dav/calendars/shared", a
"PROPFIND /dav/calendars" seems to be performed too. I include here the
response from Cyrus 3.0.5. Not sure if the response should include
anything about the shared collections available on the server that the
user has access to...
Request:
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Accept: */*
Content-Type: text/xml
Prefer: return=minimal
Depth: 0
Connection: keep-alive
Authorization: Basic XXXXXXXXXXXXXX
Content-Length: 181
Brief: t
<?xml version="1.0" encoding="UTF-8"?>
<B:propfind xmlns:B="DAV:">
<B:prop>
<B:current-user-principal/>
<B:principal-URL/>
<B:resourcetype/>
</B:prop>
</B:propfind>
Response:
HTTP/1.1 207 Multi-Status
Date: Thu, 05 Apr 2018 08:17:23 GMT
Connection: Upgrade
Upgrade:
Vary: Accept-Encoding, Brief, Prefer
Preference-Applied: return=minimal
Content-Type: application/xml; charset=utf-8
Content-Encoding: gzip
Content-Length: 226
<?xml version="1.0" encoding="UTF-8"?>
<B:multistatus xmlns:B="DAV:">
<B:response>
<B:href>/dav/calendars</B:href>
<B:propstat>
<B:prop>
<B:current-user-principal>
<B:href>/dav/principals/user/karagian/</B:href>
</B:current-user-principal>
<B:resourcetype>
<B:collection />
</B:resourcetype>
</B:prop>
<B:status>HTTP/1.1 200 OK</B:status>
</B:propstat>
</B:response>
</B:multistatus>
Please let me know if there is any way we can further contribute.
Regards,
Savvas Karagiannidis
On 9/4/2018 06:40, Anatoli wrote:
> Bron, Ken,
>
> Thanks for your explanations.
>
> Do you consider this is something possible to implement for an outside
> developer, i.e. without Cyrus HTTP/DB implementation internals
> understanding, nor solid knowledge of xDAV RFCs? I'd like to
> collaborate, but I believe it only makes sense to start this work if I
> could finish it without too much effort to become fluent with the
> related internals/standards.
>
> On the other hand, if I don't have a reasonable chance to implement it
> myself, could I sponsor the development by your team or help your team
> in other ways (e.g. extensive testing, logs/telemetry, etc.)?
>
> I have the Cyrus xDAV functionality deployed experimentally at one
> organization, everything looks good so far, but the fact that shared
> resources (calendars and addressbooks) can't be accessed from iOS
> devices obstructs its definitive deployment there and at other
> organizations. WebDAV resources work well on all devices with some
> minor issues on macOS (I'm debugging them now, looks like they only
> occur on previous versions of macOS, i.e. El Capitan).
>
>
> > I originally wrote the code to handle public calendars in the
> "shared" namespace, but I focused on user calendars first, and public
> calendar support got tossed on the back burner. It appears that the
> code for public calendars partly works.
>
> Public calendars actually work quite well, if the device can discover
> them. Currently, I've tested them with Thunderbird and haven't found
> any issues.
>
> Remote addressbooks are not supported in Thunderbird, so I use
> /CardBook/ add-on and it works well with shared addressbooks, no
> issues detected. /Evolution/ supports CardDAV natively and also works
> well with shared addressbooks.
>
> Regards,
> Anatoli
>
> *From:* Ken Murchison
> *Sent:* Saturday, April 07, 2018 21:53
> *To:* Bron Gondwana, Cyrus Devel
> *Cc:* Ken Murchison
> *Subject:* Re: shared xDAV resources
>
> I originally wrote the code to handle public calendars in the "shared"
> namespace, but I focused on user calendars first, and public calendar
> support got tossed on the back burner. It appears that the code for
> public calendars partly works.
>
> My first thought to get auto-discovery of public calendars is to add
> /dav/calendars as a second calendar-home-set for users and see what
> the Apple clients do with that. I don't know if they can handle
> multiple home-sets. If that doesn't work, then we could map public
> calendars into the user's home-set via the same subscription mechanism
> that we use for CalDAV sharing.
>
> To answer the original question, calendars are enumerated by
> meth_propfind() and propfind_by_collection() in http_dav.c
>
>
> On 4/7/18 8:25 PM, Bron Gondwana wrote:
>> Ken knows this code best. I bet there's something which is requiring
>> that there's a user on the mboxname because we implement the same
>> behaviour at FastMail by having a separate user on which shared
>> resources are kept. The DAV resources are stored per-user, and
>> without a place to keep them for "shared calendars" that code might
>> just not be accessible. I'm sure it would be possible to create a
>> shared DAV database as well for this case, but it just needs some
>> programming effort.
>>
>> Bron.
>>
>>
>> On Sun, 8 Apr 2018, at 07:30, Anatoli wrote:
>>> Hi All,
>>>
>>> I'm trying to understand the code responsible for enumerating user
>>> calendars (and xDAV resources in general) to try to make the
>>> discovery work for shared resources too (currently there's no way to
>>> access shared resources with Apple xDAV client implementation, yes
>>> with Thunderbird as it doesn't use the discovery mechanism, but
>>> instead should be pointed to the exact URL for each calendar). If I
>>> understand it correctly, the functionality is in imap/http_caldav.c.
>>>
>>> Could you please point me to the place where the enumeration occurs
>>> and briefly mention how the general workflow looks like?
>>>
>>> The client asks for:
>>>
>>> PROPFIND /dav/calendars/user/<user at domain>/
>>>
>>> <A:propfind xmlns:A="DAV:">
>>> ...
>>>
>>> The server responds with:
>>>
>>> HTTP/1.1 207 Multi-Status
>>>
>>> <A:multistatus xmlns:A="DAV:" ...>
>>> <A:response>
>>> <A:href>/dav/calendars/user/<user at domain>/</A:href>
>>> <A:propstat>
>>> ...
>>> </A:response>
>>> <A:response>
>>> <A:href>/dav/calendars/user/<user at domain>/Default/</A:href>
>>> <A:propstat>
>>> <A:prop>
>>> ...
>>>
>>> The idea is to include in the returned lists the shared calendars
>>> too with the discovery logic based on the IMAP shared folders.
>>>
>>> Below goes the initial exchange between the calendar app on iOS
>>> 10.2.6 and Cyrus 3.0.5 when the exact URL (/dav/calendars/shared/)
>>> for the shared calendar is provided in the advanced settings of the
>>> app (the URL finally resets to the user principals folder
>>> (/dav/principals/user/t3 at domain.com/) as iOS is pointed to it by
>>> Cyrus). In the attached file goes the telemetry for the rest of the
>>> communication.
>>>
>>> Thanks,
>>> Anatoli
>>>
>>> ---------- t3 at domain.com <mailto:t3 at domain.com> Sun Mar 25 06:05:36 2018
>>>
>>> <1521968736<*PROPFIND* */dav/calendars/shared/* HTTP/1.1
>>> Accept: */*
>>> Content-type: text/xml
>>> Connection: keep-alive
>>> Content-length: 181
>>> Host: mail.domain.com
>>> User-agent: iOS/11.2.6 (15D100) accountsd/1.0
>>> Prefer: return=minimal
>>> Depth: 0
>>> Brief: t
>>> Accept-language: en-us
>>> Authorization: Basic ...
>>> Accept-encoding: br, gzip, deflate
>>>
>>> <1521968736<<?xml version="1.0" encoding="UTF-8"?>
>>> <A:propfind xmlns:A="DAV:">
>>> <A:prop>
>>> <A:current-user-principal/>
>>> <A:principal-URL/>
>>> <A:resourcetype/>
>>> </A:prop>
>>> </A:propfind>
>>>
>>>
>>> >1521968736>HTTP/1.1 207 Multi-Status
>>> Date: Sun, 25 Mar 2018 09:05:36 GMT
>>> Strict-Transport-Security: max-age=600
>>> Vary: Accept-Encoding, Brief, Prefer
>>> Preference-Applied: return=minimal
>>> Content-Type: application/xml; charset=utf-8
>>> Content-Length: 546
>>>
>>> <?xml version="1.0" encoding="utf-8"?>
>>> <A:multistatus xmlns:A="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
>>> <A:response>
>>> <A:href>*/dav/calendars/shared/*</A:href>
>>> <A:propstat>
>>> <A:prop>
>>> <A:current-user-principal>
>>> <A:href>*/dav/principals/user/t3 at domain.com/*</A:href>
>>> </A:current-user-principal>
>>> <A:resourcetype>
>>> <A:collection/>
>>> <C:calendar/>
>>> </A:resourcetype>
>>> </A:prop>
>>> <A:status>HTTP/1.1 200 OK</A:status>
>>> </A:propstat>
>>> </A:response>
>>> </A:multistatus>
>>>
>>> <1521968736<OPTIONS /dav/principals/user/t3%40domain.com/ HTTP/1.1
>>> Host: mail.domain.com
>>> Connection: keep-alive
>>> Accept: */*
>>> User-Agent: iOS/11.2.6 (15D100) accountsd/1.0
>>> Accept-Language: en-us
>>> Content-Length: 0
>>> Accept-Encoding: br, gzip, deflate
>>>
>>> >1521968736>HTTP/1.1 200 OK
>>> Date: Sun, 25 Mar 2018 09:05:36 GMT
>>> Strict-Transport-Security: max-age=600
>>> Cache-Control: no-cache
>>> Link: </dav/principals/.server-info>; rel="server-info";
>>> token="80769c2c66d340ecd178710db26d56b9c4699e3e"
>>> DAV: 1, 2, 3, access-control, extended-mkcol, resource-sharing
>>> DAV: calendar-access, calendar-auto-schedule
>>> DAV: calendar-query-extended, calendar-availability,
>>> calendar-managed-attachments
>>> DAV: calendarserver-sharing, inbox-availability
>>> DAV: addressbook
>>> Allow: OPTIONS, GET, HEAD
>>> Allow: PROPFIND, REPORT, COPY
>>> Content-Length: 0
>>>
>>> Email had 1 attachment:
>>>
>>> *
>>> |telemetry.log|
>>> 36k (text/x-log)
>>>
>>
>> --
>> Bron Gondwana, CEO, FastMail Pty Ltd
>> brong at fastmailteam.com
>>
>>
>
>
> --
> Kenneth Murchison
> Cyrus Development Team
> FastMail Pty Ltd
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20180410/4e761505/attachment-0001.html>
More information about the Cyrus-devel
mailing list