Lightning hammers webdav server with repeated OPTIONS and PROPFIND when incorrectly configured as caldav

RESOLVED FIXED in 4.0.1.2

Status

Calendar
Provider: CalDAV
RESOLVED FIXED
6 years ago
2 years ago

People

(Reporter: Wim Lewis, Assigned: Fallen)

Tracking

Lightning 1.0b4
4.0.1.2
x86
Windows 7

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

6 years ago
Under some circumstances Lightning will make 5-10 (or more) useless requests per second to the WebDAV server hosting .ics file.

The pattern of requests look like this (slightly anonymized):

IPADDRESS - - [25/Jul/2011:01:26:25 -0700] "OPTIONS / HTTP/1.1" 301 239 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 Lightning/1.0b4"
IPADDRESS - USERNAME [25/Jul/2011:01:26:25 -0700] "OPTIONS /directory/ HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 Lightning/1.0b4"
IPADDRESS - USERNAME [25/Jul/2011:01:26:25 -0700] "PROPFIND /directory/ HTTP/1.1" 207 690 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 Lightning/1.0b4"
IPADDRESS - - [25/Jul/2011:01:26:25 -0700] "OPTIONS / HTTP/1.1" 301 239 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 Lightning/1.0b4"
IPADDRESS - USERNAME [25/Jul/2011:01:26:26 -0700] "OPTIONS /directory/ HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 Lightning/1.0b4"
IPADDRESS - USERNAME [25/Jul/2011:01:26:26 -0700] "PROPFIND /directory/ HTTP/1.1" 207 690 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 Lightning/1.0b4"

As you can see, once per second it makes an OPTIONS request to / (which it probably shouldn't; see bug 658960); then one to the user's actual directory, then performs a PROPFIND. Periodically (every 30 minutes or so), the number of requests being sent will multiply, as if there are additional threads performing the same operations every second. In my logs this process tops out at around 30 HTTP requests per second, probably because the user's net connection is saturated. The pattern of increase is very regular and linear over the course of hours, so I think it is some automatic behavior inside Lightning, not a user action.

(Sorry for the sparse information about the Lightning configuration here; I am coming at this from the server side, looking at load spikes on my DAV servers. I will update this bug if I am able to get more information from the Lightning user.)

Some bugs which I do not think are the same bug:
  Bug 598880 is CalDAV specififc, but the traffic I am seeing in plain WebDAV
  Bug 562621 has to do with authentication failure, but my user is successfully authenticating
  Bug 435854 looks somewhat similar, but is marked as resolved
(Assignee)

Comment 1

6 years ago
Strange, we didn't really change much w.r.t the webdav provider. Maybe you can try to reproduce this with your own Lightning installation or contact the user.

It would be interesting to know if the same thing happens with an older version (i.e regression or not) and if the user is getting any error console messages.
Wim, is this still an issue using the recently released Lightning 1.0?
Martin, this is still an issue on Lightning 1.9.

Updated

3 years ago
Blocks: 975402

Comment 4

2 years ago
I can confirm that this symptom still applies to the current Lightning 3.3.3 version.

At work we are running several webdav servers which support webdav but not caldav. I can reproduce the issue when I try to create a caldav calendar inside a webdav resource. When enabling calendar debug in Thunderbird, I get correctly notified that the server doesn't support caldav (message "DAV_NOT_CALDAV") but in the following lines, Lightning or Thunderbird states that the error is probably not severe and that it will continue anyway. That's the moment when the endless OPTIONS and PROPFIND requests start. In the GUI, there is no clue for the user that creating the calendar in fact did not work and nothing is being correctly synched. Even when the user deletes the calendar, the request flood does not end until the client is restarted or temporarily set to "Offline". Just a few users can this way generate tens of thousands broken requests each day without noticing.

Using iCal instead of caldav is working just fine with our servers.
(Reporter)

Comment 5

2 years ago
FYI, I can also confirm that this is still happening with a recent version (user-agent "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 Lightning/3.3.2").

Comment 6

2 years ago
I can confirm this bug on Fedora 22 with thunderbird-38.0.1-2.fc22.x86_64.

I install Baikal CalDAV server and Thunderbird started to flood the CalDAV server with ~30 requests per second:

...
127.0.0.1 - user [28/Jun/2015:01:02:03 +0300] "OPTIONS /bk/html/cal.php/principals/ HTTP/1.1" 200 -
127.0.0.1 - user [28/Jun/2015:01:02:03 +0300] "PROPFIND /bk/html/cal.php/principals/user/ HTTP/1.1" 207 1057
127.0.0.1 - user [28/Jun/2015:01:02:03 +0300] "OPTIONS /bk/html/cal.php/principals/ HTTP/1.1" 200 -
127.0.0.1 - user [28/Jun/2015:01:02:03 +0300] "PROPFIND /bk/html/cal.php/principals/user/ HTTP/1.1" 207 1057
...

CalDav URI: https://server/bk/html/cal.php/principals/user

My server has invalid SSL certificate, Thunderbird asked for security exception at first connect which I granted.

Server's IP address is 127.0.0.1

I've enabled [X] Show reminders and [X] Offline support. Refresh default every 30 minutes.


I can reproduce the problem 100%, any advice for further debugging would be appreciated.
(Assignee)

Comment 7

2 years ago
Hi folks, sorry this bug has not been getting traction over the years. It sounded to me like it was a minority case which may have to do with using the wrong URL for the server, which can easily be corrected by fixing the URL.

This bug is actually about the ICS/Webdav provider, but I also see reports about CalDAV. It would be nice if we could separate the issues.

I will take a look and see if I can reproduce this locally, I'm sure we can add this to 4.0.1.1 if I am quick, or 4.0.2 otherwise.
(Assignee)

Updated

2 years ago
Assignee: nobody → philipp
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 8

2 years ago
Ok, looking at the initial request it does look like this is the caldav provider trying to access a webdav share. The webdav provider only does a PROPFIND when the etag could not be retrieved correctly.
Component: Provider: ICS/WebDAV → Provider: CalDAV
Summary: Lightning hammers DAV server with repeated OPTIONS and PROPFIND → Lightning hammers webdav server with repeated OPTIONS and PROPFIND when incorrectly configured as caldav
(Assignee)

Comment 9

2 years ago
Created attachment 8636012 [details] [diff] [review]
Fix - v1

Ok, I've been able to reproduce this by subscribing to the webdav resource http://dav.kewis.ch/directory (which is actually a DAV directory, not a caldav calendar). It doesn't happen immediately after subscribing, but as soon as you synchronize it starts to happen.

I've fixed this part by ensuring that checkServerCaps is only called if the resource type is really a calendar.

Then, I looked at the "minor error" code, this is obviously not a minor error. I've noticed that changing mReadOnly and mDisabled does not actually change the properties "readOnly" and "disabled". I've fixed this by removing mDisabled and mReadOnly and just using the property getters directly.

I can take the first part of the fix for 4.0.1.1, but the second part is more risky and should probably be postponed to 4.0.2
Attachment #8636012 - Flags: review?(makemyday)
Attachment #8636012 - Flags: approval-calendar-release+
Attachment #8636012 - Flags: approval-calendar-beta+
Attachment #8636012 - Flags: approval-calendar-aurora+
(Assignee)

Updated

2 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 10

2 years ago
Created attachment 8636016 [details] [diff] [review]
Fix - v2
(Assignee)

Updated

2 years ago
Attachment #8636016 - Flags: review?(makemyday)

Comment 11

2 years ago
Comment on attachment 8636016 [details] [diff] [review]
Fix - v2

Review of attachment 8636016 [details] [diff] [review]:
-----------------------------------------------------------------

r+ with the comment below considered.

::: calendar/providers/caldav/calDavCalendar.js
@@ +1888,1 @@
>              }

You should add a return; herein to avoid falling through to the forced error below.

Comment 12

2 years ago
Upps, the comment was for

>+            if (resourceType == kDavResourceTypeCalendar) {
>+                // If this calendar was previously offline we want to recover
>+                if (thisCalendar.mDisabled) {
>+                    thisCalendar.mDisabled = false;
>+                    thisCalendar.mReadOnly = false;
>+                }
>+                thisCalendar.setCalHomeSet(true);
>+                thisCalendar.checkServerCaps(aChangeLogListener);
>             }

Updated

2 years ago
Attachment #8636016 - Flags: review?(makemyday) → review+
(Assignee)

Comment 13

2 years ago
Thanks, great catch! I'll correct this before pushing.

Comment 14

2 years ago
Will you provide an updated patch for the exchange of the disabled and reaonly props? The existing one has parts of the v4.0.1.1 patch in it, so it cannot be applied on top of this.

If you do so, you can use readOnly directly instead of the g/setter for this.
(Assignee)

Comment 15

2 years ago
(In reply to MakeMyDay from comment #14)
> Will you provide an updated patch for the exchange of the disabled and
> reaonly props? The existing one has parts of the v4.0.1.1 patch in it, so it
> cannot be applied on top of this.
The first patch is a combined patch that fixes both issues, the 4.0.1.1 patch *should* be just the fix for the endless loop, without removing mReadOnly and mDisabled (which also works). If you prefer, I can separate the two patches completely, applying only the one on 4.0.1.1 and both of them on 4.0.2+

> 
> If you do so, you can use readOnly directly instead of the g/setter for this.
Can you clarify this? Not exactly sure what you mean.

Comment 16

2 years ago
(In reply to Philipp Kewisch [:Fallen] from comment #15)
> The first patch is a combined patch that fixes both issues, the 4.0.1.1
> patch *should* be just the fix for the endless loop, without removing
> mReadOnly and mDisabled (which also works). If you prefer, I can separate
> the two patches completely, applying only the one on 4.0.1.1 and both of
> them on 4.0.2+

You can do it either way, but having the patches separately makes it more tracable. Also the patches should then split up in two bugs as they have different target versions.

> > If you do so, you can use readOnly directly instead of the g/setter for this.
> Can you clarify this? Not exactly sure what you mean.

instead of e.g.
    thisCalendar.mReadOnly = false;
I you can use
    thisCalendar.readOnly = false;

Unfortunately, there is no directly accessible attribute for disabled in the calendar interface, so for that you would have to use set/getProperty, then.
(Assignee)

Updated

2 years ago
Attachment #8636012 - Attachment is obsolete: true
Attachment #8636012 - Flags: review?(makemyday)
Attachment #8636012 - Flags: approval-calendar-release+
Attachment #8636012 - Flags: approval-calendar-beta+
Attachment #8636012 - Flags: approval-calendar-aurora+
(Assignee)

Updated

2 years ago
Attachment #8636016 - Attachment description: Patch for 4.0.1.1 → Fix - v2
(Assignee)

Updated

2 years ago
Attachment #8636016 - Flags: approval-calendar-release+
Attachment #8636016 - Flags: approval-calendar-beta+
Attachment #8636016 - Flags: approval-calendar-aurora+
(Assignee)

Comment 17

2 years ago
Ok, this should do it, everything taken care of. Will need to skip c-c for now because of the tree closing.
(Assignee)

Comment 18

2 years ago
Backported to releases/comm-aurora changeset 9a718ca3cae1
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.3
(Assignee)

Comment 19

2 years ago
Backported to releases/comm-beta changeset b54342bc4cc5
Target Milestone: 4.3 → 4.2
(Assignee)

Comment 20

2 years ago
Backported to releases/comm-esr38 changeset be79b5e53f32
Target Milestone: 4.2 → 4.0.2
(Assignee)

Updated

2 years ago
Keywords: checkin-needed
(Assignee)

Comment 21

2 years ago
Created attachment 8637396 [details] [diff] [review]
Fix - v3

Thanks to MakeMyDay's quick mind, the last changesets fix the missing return. Here is the combined patch for comm-central once the tree opens again.
Attachment #8636016 - Attachment is obsolete: true
Attachment #8637396 - Flags: review+
Attachment #8637396 - Flags: approval-calendar-release+
Attachment #8637396 - Flags: approval-calendar-beta+
Attachment #8637396 - Flags: approval-calendar-aurora+
(Assignee)

Updated

2 years ago
Target Milestone: 4.0.2 → 4.0.1.1
(Assignee)

Comment 22

2 years ago
What a mess. Here is the missing set of push comments:

http://hg.mozilla.org/releases/comm-esr38/rev/e08fb68b3474
http://hg.mozilla.org/releases/comm-beta/rev/3a6adf92dcac
https://hg.mozilla.org/releases/comm-aurora/rev/3638ae3dc946
(Assignee)

Comment 23

2 years ago
url:        https://hg.mozilla.org/comm-central/rev/9cb4a949fd498774e864b77c8c1738f8cde6cc1e
changeset:  9cb4a949fd498774e864b77c8c1738f8cde6cc1e
user:       Philipp Kewisch <mozilla@kewis.ch>
date:       Sat Aug 08 11:06:25 2015 +0100
description:
Fix bug 674088 - Lightning hammers webdav server with repeated OPTIONS and PROPFIND when incorrectly configured as caldav. r=MakeMyDay
(Assignee)

Updated

2 years ago
Keywords: checkin-needed
You need to log in before you can comment on or make changes to this bug.