This change set implements the "context path" discovery for the
CalDav/CardDav endpoints.
This basically implements the bootstrapping process as defined in
RFC6764 section 6, point 2 and 3.
What's missing in this implementation is the fallback that is described
in point 3, subpoint 3, which says that if the context path discovered
in the TXT RR is not reachable the .well-known URI should be used
instead.
I propose to implement this in a future iteration.
NewPropFindResponse uses callbacks to lazily build the response.
However, some props are static: they don't require any processing
to generate. Add a small helper to reduce boilerplate a bit.
Both the displayname and the description can be absent for both
calendars and address books. If this is the case they should not show up
in PROPFIND responses as empty string.
It seems like e.g. Apples reminders likes to send `PropPatch`, and
currently this just fills up my logs because of the panic. I thought it
would be better to signal that this isn't supported yet, which should
hopefully make it easier to dig through the logs.
Now that the handling for multiple address books is in place, this
commit adds initial support for creation and deletion of address books.
These operations obviously require support from the backend, so the
interface gains two new methods. All properties of the address book
passed to `CreateAddressBook()` may be unset (e.g. when a client sends a
MKCOL request without a body), except for the path, which is always set.
It is up to the backend to put any desired default values in place.
This is the equivalent of #127 (and #140) for CardDAV and finally allows
backends to serve different address books to different users.
While I'm breaking the interface, correct one last instance of
"Addressbook" to "AddressBook" (in `AddressBookHomeSetPath`).
Matches on open time ranges (i.e. no end date) were not properly
handled, as `end` is simply the zero time, which confuses the
`.Before()` and `.After()` logic employed here.
This commit fixes that by adding the appropriate `.IsZero()` checks and
also adds a test case.
The current behavior unfortunately broke compatibility with DAVx5, which
by default queries only events less than 90 days ago (by using an open
time range).
This CL corrects the following bug uncovered by staticcheck:
```
internal/elements.go:148:6: this comparison is always true (SA4023)
internal/elements.go:146:18: the lhs of the comparison gets its value from here and has a concrete type
```
Signed-off-by: Sebastien Binet <binet@cern.ch>
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.
