610087 - Failed OPTIONS request against a calendar-home-set URL makes calendar unusable

Status: RESOLVED DUPLICATE of bug 588799

(Calendar :: Provider: CalDAV, defect)

Description

[Andrew McMillan]

In the process of accessing a calendar, Lightning attempts to discover server capabilities through an OPTIONS on (possibly the first member of) the calendar-home-set associated with the owner of a collection.

According to RFC3744 (see section 3.1. DAV:read Privilege) for a successful OPTIONS request the user must have 'read' privileges to the resource being queried.

It is possible for the user to have 'read' (or even read + write) access to the collection, and yet *not* have 'read' access to other URLs on the server, so Lightning should probably do the OPTIONS on the calendar URL itself. That's what it really cares about in any case.

This issue appears to cause problems for some users of the current version of DAViCal, where it is possible to configure a group calendar without granting 'read' access to the group principal for members of the group.

It's probably also worth noting that the available methods and capabilities listed in response to an OPTIONS request can (and do) vary.  A principal-URL might not allow the PUT or DELETE operations, whereas a calendar collection will allow these if the accessing user has a 'write' privilege.

Also consider that calendar-home-set is a *set* of URLs, and not necessarily a single URL at all.  The call to OPTIONS in the caldav_checkServerCaps function possibly makes this mistake also, although I freely admit I don't know the code well enough to make an assessment on that issue, but the code certainly does not make any effort to continue attempting the OPTIONS on other members of the calendar-home-set.

Comment 1

[Stefan Fleiter (:sfleiter)]

Possibly a duplicate of Bug 588799.
Description and title are better, but the discussion on the solution already started on the other bug.

Comment 3

[Arnaud Quillaud]

Solution described in 588799 does not look OK to me. Instead of ignoring an error, the fix is really to issue the OPTIONS request against the calendar URL, as configured by the end user.

Comment 5

[Stefan Fleiter (:sfleiter)]

Bug 588799 now contains a patch doing just that, see bug 588799 comment 32.

Comment 6

[Stefan Fleiter (:sfleiter)]

Bug 588799 now contains a patch which stays with the current behavior and only falls back to using the calendar URL.
This was wanted for backwards compatibility.

Marking as duplicated because the fix is developed there.
Thanks a lot for the detailed bug report Andrew.