746962 - Never ending loop when caldav url is misconfigured (principal or home url)

Status: RESOLVED DUPLICATE of bug 874654

(Calendar :: Provider: CalDAV, defect)

Description

[Arnaud Quillaud]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0
Build ID: 20120312181643

Steps to reproduce:

Configure a CalDAV account, using a principal uri or home uri instead of a calendar collection uri, e.g. http://localhost:8080/dav/principals/[e-mail]/


Actual results:

Right after configuration, the calendar goes into invalid state (Yellow warning sign + "The calendar xxx is momentarily not available"). The error log indicates:
<<
Warning: There has been an error reading data for calendar: testcal.  However, this error is believed to be minor, so the program will attempt to continue. Error code: DAV_DAV_NOT_CALDAV. Description: The resource at http://localhost:8080/dav/principals/[e-mail]/ is a DAV collection but not a CalDAV calendar
>>

Later on, reselect the calendar and right click --> "Synchronize calendars"

==> The client enters a never ending loop, issuing the following 3 queries over and over:
<<
CalDAV: send:  PROPFIND http://localhost:8080/dav/principals/arnaud.quillaud%40example.com/
<D:propfind xmlns:D="DAV:" xmlns:CS="http://calendarserver.org/ns/" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:prop>
    <D:resourcetype/>
    <D:owner/>
    <D:supported-report-set/>
    <C:supported-calendar-component-set/>
    <CS:getctag/>
  </D:prop>
</D:propfind>

CalDAV: send: OPTIONS http://localhost:8080/dav/principals/

CalDAV: send: PROPFIND http://localhost:8080/dav/principals/arnaud.quillaud%40example.com/
<D:propfind xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:prop>
    <C:calendar-home-set/>
    <C:calendar-user-address-set/>
    <C:schedule-inbox-URL/>
    <C:schedule-outbox-URL/>
  </D:prop>
</D:propfind>
>>



Expected results:

Client should give up after detecting that the configured url is not correct (or better, make use of whatever is passed in to reconfigure the right url)

Comment 1

[Arnaud Quillaud]

Marking as major since this misconfiguration is rather common and can be seen as some sort of denial of service attack. See https://forums.oracle.com/forums/thread.jspa?threadID=2377546&tstart=0

From what I can see, in checkDavResourceType(), if the resource type is a dav collection but not a calendar collection, an error is returned only if this.mDisabled is false:

<<
            if ((resourceType == kDavResourceTypeCollection) &&
                !thisCalendar.mDisabled) {
                thisCalendar.completeCheckServerInfo(aChangeLogListener,
                                                     Components.interfaces.calIErrors.DAV_DAV_NOT_CALDAV);
                return;
            }
>>

If mDisabled is true (case of the second attempt to synchronize), the caldav provider continues with the normal code flow, although the collection is not a calendar collection.

This leads to the following loop:
 refresh() ==> replayChangesOn() ==> safeRefresh() ==> getUpdatedItems() ==> checkDavResourceType() ==> checkServerCaps() ==> findPrincipalsNS ==> checkPrincipalsNamespace() ==> completeCheckServerInfo() ==> refresh()

Comment 2

[richlv]

this might be the same or different issue, but misconfigured webdav ical shows the same behaviour. extra "./" at the calendar url makes it constantly do :

PROPFIND /calendar_name.ics./

this is Lightning/1.7, according to apache logs.

apparently here it manages to do some 63 requests per second, but that's with an underpowered vm running the webdav share. apache logs grow significantly...

Comment 3

[David von Oheimb]

Essentially the same misbehavior occurs when a correctly specified CalDAV calendar server is not reachable (because for instance there the network connection of the client is down or the server is in some company intranet but the laptop accessing it is outside that zone). 

I suffer from this problem using DavMail, as reported here: http://sourceforge.net/tracker/index.php?func=detail&aid=3609878&group_id=184600&atid=909904
When trying to synchronize a calendar while the server is not accessible,
exceptions are thrown all the time, causing very high CPU load.

DavMail correctly returns a "HTTP/1.1 503 Service Unavailable" error,
yet Lightning immediately retries the connection over and over!
It must give up after trying a few times and then wait (not using a busy loop) for some time before re-trying.

Please generalize the title of this bug report, flag this issue to be confirmed, and give it high priority, since it makes the calendar unusable - it even makes the client machine´s desktop/GUI unresponsive.

Comment 4

[David von Oheimb]

Since nobody of the Lightning team responded to my latest comment 3,
mguessan opened a new bug report for it: bug 874654.
The patch provided there might also solve the issue originally posted here - please check!

Comment 5

[Sushrut Bhalla]

can i have this? I am looking for my first bug...

Comment 6

[David von Oheimb]

Fix confirmed (see bug 874654).

Comment 7

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Thanks for checking!