* Access rights are checked before the storage is locked and
collections are loaded.
* DELETE sends 410 instead of doing nothing or crashing if the target
doesn't exist.
* GET always returns 404 if the target doesn't exist.
* GET doesn't crash if a collection without tag property is requested.
* MKCOL and MKCALENDAR send 409 if the target already exists.
* MOVE checks if the target collection of an item actually exists and
sends 409 otherwise.
* PUT doesn't crash if a whole collection that doesn't exist yet is
uploaded and ``content-type`` is ``text/vcard`` or
``text/calendar``.
* PUT distinguishes between simple items and whole collections by the
following criteria: Target is a collection; Parent exists; Parent
has the tag property set; Parent contains other items. Before only
the first two criteria where used, which was very unrelieable. #384
* PROPPATCH is only allowed on collections and 409 is send otherwise.
* ``Rights.authorized`` takes a path instead of a collection.
* ``Collection.discover`` only returns items in ``path``, that
actually exist. #442
From RFC3744: This protected property of a resource contains a set of URLs that identify the root collections that contain the principals that are available on the server that implements this resource.
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.
I have a setup where Radicale is running as the normal process, and
nginx is acting as proxy for Radicale for requests under /radicale/.
This means that all requests to nginx that go to /radicale/ are sent to
a radicale server that expects requests coming at /.
Obviously, all the href need to have the /radicale/ prefix to have
things work. So a new option proxy_base_prefix is added to allow having
such a setup.
All href that are sent in the replies will have the proxy_base_prefix
prepended.
Unrud
Guillaume Ayoub
Unrud
Florian Mounier
Nicolas Bonfante
Cedric Boscher
Markus Unterwaditzer
Jasper Bryant-Greene
igogold
Giel van Schijndel
Hadley Rich
Liam
Jochen Sprickerhof
Felix Lange
Dominik
Mathieu Dupuy
Christoph Polcin
Jean-Marc Martins
Jochen Sprickerhof
Jonathan Dupart
Vincent Untz
Fabrice Bellet