When doing REPORTs with absolute paths as hrefs, the response hrefs
contain a double slash at the beginning. This breaks URL parsers and
makes them assume they have a URL without protocol of the format
`//example.com/foo/bar/`.
The new API used comes from vdirsyncer, as proposed by @untitaker in
issue #130.
The code has been tested and works with the (too simple) unit tests, and
with Lightning and DAVdroid. Many things are broken and a good part of
the code has not be ported to the new API yet. TODOs have been added
where the application is known to be broken.
* Handle both the explicit <propall/> and its implicit variants
- the missing request-body case was already handled
- the empty request-body case wasn't
- the explicit (a request-body containing <propall/>) wasn't either
* <propnames/> now lists all retrievable properties
Signed-off-by: Giel van Schijndel <me@mortis.eu>
If I do REPORT requests, the following line would raise a KeyError:
items = [collection.items[name]]
Wrapping it with a try-except block obviously fixes that issue.
At least for REPORT requests, Radicale now also returns proper HTTP
status codes when items or just its properties couldn't be found.
Fix#196
The way to do collection discovery described in
http://stackoverflow.com/a/11673483 doesn't work well with Radicale:
1. current-user-principal returns /user/calendar.ics/
2. PROPFINDs asking for calendar-home-set will return the URL that was
used in the request, which is still /user/calendar.ics/
3. The final PROPFIND with Depth: 1 is supposed to list all collections,
but because the request is done with a collection URL, Radicale returns
the items for the "calendar.ics" collection which might or might not
exist.
