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@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@domain>/</A:href>
<A:propstat>
...
</A:response>
<A:response>
<A:href>/dav/calendars/user/<user@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/t...@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
---------- t...@domain.com <mailto:t...@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/t...@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
br...@fastmailteam.com
--
Kenneth Murchison
Cyrus Development Team
FastMail Pty Ltd
