It seems like the Reminders app in iOS/macOS does this request as
the first thing when setting up an account, so it seems reasonable to
handle it for us.
This just returns the most basic current-user-principal now, but that
should hopefully be enough to continue the process.
I started using this project to export tasks over CalDav, more
specifically to Reminders on iOS/macOS. I quickly realized that
even if you specify that `SupportedComponentSet` contains `VTODO`, that
isn't reflected properly when doing the `PROPFIND`.
This patch should fix that, while keeping the behaviour of defaulting to
`VEVENT` for propfind. Also added some tests to make sure that I didn't
break anything (Which I hope I didn't 😅).
This is done properly in the carddav and caldav packages, but the custom
function does not know what the user intends to serve, so it must be
passed in from the user. Without this, certain clients (e.g. DAVx5)
will be unable to discover endpoints served this way.
Also slightly extend the supported methods returned on OPTIONS requests.
REPORT is properly supported, the others are mostly for not giving
clients the impression that the resources are read-only.
The `If-Match` and `If-None-Match` conditional headers can have either a
wildcard or a (quoted) ETag as value. However, the ETag _could_ be a
literal `*`, so care must be taken to allow these cases to be
distinguished. The values of these headers have to be handled by the
backend, so export a type that facilitates working with these values.
The match helper will now properly return recurring events if any of
their recurrences fall into the queried time range. A test for this was
added as well.
See https://www.rfc-editor.org/errata/eid4164
The original RFC's appendix was missing a part of the calendar data used
in the examples. This will become relevant when adding tests for
retrieving recurring events.
This is not yet complete (see TODOs in code), but basic filtering of a
list of CaledarObjects works.
Includes test data from the RFC, which allows to use the RFCs examples
as test cases.
Allow the backend to provide a value for the `getcontentlength` property
as described in [RFC 2518 section 13.4][1].
The implementation treats is as optional, allthough it is a required
property per RFC. Most clients do perfectly fine without it, though.
Properly setting this in the backend makes the CalDAV collection
listable with clients that do require it, e.g. cadaver.
[1]: https://datatracker.ietf.org/doc/html/rfc2518#section-13.4
CalDAV imposes a set of constraints on iCal Calendar objects. They are
spelled out in RFC 4791, section 4.1 [1]. Add an exported function to
validate a calendar according to those constraints, and return data that
is necessary for further CalDAV processing and which can only be
extracted if the calendar meets these constraints.
[1]: https://datatracker.ietf.org/doc/html/rfc4791#section-4.1
Currently, the user principal path and the home set path are both
hardcoded to "/", for both CalDAV and CardDAV. This poses a challenge if
one wishes to run a CardDAV and CalDAV server in the same server.
This commit introduces the concept of a UserPrincipalBackend. This
backend must provide the path of the current user's principal URL from
the given request context.
The CalDAV and CardDAV backends are extended to also function as
UserPrincipalBackend. In addition, they are required to supply the path
of the respective home set (`calendar-home-set` and
`addressbook-home-set`). The CardDAV and CalDAV servers act accordingly.
The individual servers will continue to work as before (including the
option of keeping everything at "/"). If one wishes to run CardDAV and
CalDAV in parallel, the new `webdav.ServeUserPrincipal()` can be used as
a convenience function to serve a common user principal URL for both
servers. The input for this function can be easily computed by the
application by getting the home set paths from the backends and using
`caldav.NewCalendarHomeSet()` and `carddav.NewAddressbookHomeSet()` to
create the home sets.
Note that the storage backend will have to know about these paths as
well. For any non-trivial use case, a storage backend should probably
have access to the same UserPrincipalBackend. That is, however, an
implementation detail and doesn't have to be reflected in the
interfaces.
The basic types related to queries and filtering are missing some
features specified in the RFC (as also noted in the TODO comments). This
adds several of the missing elements, working towards being able to
handle all RFC-compliant queries.
The work is not fully done, e.g. the collation for text-match is still
not handled, but it's getting pretty close.
