Closed
Bug 435854
Opened 16 years ago
Closed 14 years ago
Wrong Server Response to inbox query leads to infinite loop of requests
Categories
(Calendar :: Provider: CalDAV, defect)
Calendar
Provider: CalDAV
Tracking
(Not tracked)
RESOLVED
FIXED
1.0b2
People
(Reporter: edouard.gaulue, Assigned: nomisvai)
References
Details
Attachments
(4 files, 3 obsolete files)
3.26 KB,
patch
|
Fallen
:
review+
|
Details | Diff | Splinter Review |
7.88 KB,
patch
|
Fallen
:
review+
|
Details | Diff | Splinter Review |
2.98 KB,
patch
|
Fallen
:
review+
|
Details | Diff | Splinter Review |
4.59 KB,
patch
|
Fallen
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Build Identifier: 2008033118 When sunbird is misconfigured and try to access a forbidden calendar, it seems that as soon as it gets that response it tries to get it again (if passwd has been saved of course). I've got 2 calendars on a apache2 davical server : one is well configure and the other not. I'm sending tens of request by second to try to get the one which is forbidden. It leads to a stupid CPU and brandwith usage on the client side, and it totally kill the server in case of to much misconfiguration in the society. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Comment 1•16 years ago
|
||
I reproduced this bug on Sunbird, on Mac OS X. When trying to add a forbidden CalDav Calendar, Sunbird sends a message telling that the calendar is disabled : There has been an error reading data for calendar: (null). It has been disabled until it is safe to use it. The resource at *** is either not a DAV collection or not available But, at the same time, something like 10 requests per second are sent to the caldav server. With my configuration, the problem does not reappear if I close Sunbird and relaunch it.
Reporter | ||
Comment 2•16 years ago
|
||
When I relaunch thunderbird, it loads my normal calendar and give me a error message concerning the forbidden one. Starting that time I can unselect the calendar or even remove it, that's to late. Even restarting thunderbird with the calendar being unselected leads to the same error.
Comment 3•16 years ago
|
||
What version of Sunbird are you using? This may have been fixed already, so if you are using 0.8 or earlier please retest with a current nightly.
Comment 4•16 years ago
|
||
0.8 for me, I'll test with a nightly.
Reporter | ||
Comment 5•16 years ago
|
||
I use lightning 0.8 64 bits. As far as I know there is no nightly build for 64 bits. I'd like to.
Comment 6•16 years ago
|
||
With the mac OS X one, the bug can not be reproduced. Seems to be OK, thanks.
Comment 7•16 years ago
|
||
Closing bug based on comment #6. Relevant checkin was in bug 400835.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Comment 9•16 years ago
|
||
I was able to reproduce this problem with Lightning 0.9 RC2 by configuring a CalDAV calendar with a bad URL (the 2 commas shouldn't be there), e.g., https://caldav.oracle.com/caldav/Ent1/home/bernard.desruisseaux%40caldav.o,,racle.com/calendars/MyCalendar Lightning submits an OPTIONS request on /caldav/Ent1/home/bernard.desruisseaux%40caldav.o,,racle.com/calendars/ followed by a PROPFIND request on /caldav/Ent1/home/bernard.desruisseaux%40caldav.o,,racle.com/calendars/MyCalendar and then the same OPTIONS requests and so on...
Updated•16 years ago
|
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Comment 10•15 years ago
|
||
I'm experiencing a similar issue with TB 3.0b2 + Lightning 1.0pre, along with a Darwin Calendar Server 1.2 (gnu/linux) instance. The server is hogged by bursts of 36 requests per second by the misbehaving client. {IP} - {user} [29/Jun/2009:19:45:58 +0200] "PROPFIND /calendars/__uids__/4630ce30-09f6-527a-8a9a-7afd6eee3a16/inbox/ HTTP/1.1" 207 410 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1b3pre) Gecko/20090223 Lightning/1.0pre Thunderbird/3.0b2" [19.2 ms] this is one sample (taken by DCS' access.log) The guid shown is correctly related to {user}, but it seems that accessing the 'inbox' is not allowed: {DAV:}current-user-privilege-set (access forbidden) This is what can be read from page properties when accessing the URL shown on the log with the same credential set used by lightning. Lightning is currently configured to fetch: http://<serverip>:8080/calendars/users/{user}/calendar/ And I get no errors on its interface. Everything works as expected. A note about configuration: I applied custom values for: calendar.caldav.sched.enabled => true calendar.itip.notify-replies => true My limited vision of the situation suggests me that could be either a server likewise client problem. However, I just wonder: what about throttling in such situations?
Comment 11•15 years ago
|
||
From my limited vew it seems that the this.calendar.pollInbox() in calDavRequestHandlers causes the problem. But I'm not too sure about this. At least this is one of the three places where pollInbox() is called. Also it doesn't seem resonable to rerequest the inbox when a query is finished.
Comment 12•15 years ago
|
||
You mean: http://mxr.mozilla.org/comm-central/source/calendar/providers/caldav/calDavRequestHandlers.js#189 ? I have additional debug information, taken from the Error Console: ----------SNIP---------- CalDAV: send(http://<serverip>:8008/calendars/__uids__/4630ce30-09f6-527a-8a9a-7afd6eee3a16/inbox/): <?xml version="1.0" encoding="UTF-8"?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:getcontenttype/> <D:getetag/> </D:prop> </D:propfind> CalDAV: recv: <multistatus> <response> <href>/calendars/__uids__/4630ce30-09f6-527a-8a9a-7afd6eee3a16/inbox/</href> <propstat> <prop> <getcontenttype>httpd/unix-directory</getcontenttype> <getetag>"3BE28-1000-4A48CBA7"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> ----------SNIP---------- This is repeated for ever. I still cannot find a stiff way to reproduce it. It always happens with some users, meanwhile a specific one has no problems at all (the only relevant thing that changes among them are just the events. They share the same delegation model and groups). Latest tested package: windows-xpi 1.9.1 (1.0pre) (pre-)built yesterday.
Comment 13•15 years ago
|
||
Needs more investigation to decide blocking status!
Comment 14•15 years ago
|
||
It seems this is related to the scheduling inbox being a http/unix-directory, rather than a calendar collation. Can someone give me a test account on a such server?
Comment 15•15 years ago
|
||
Hi Philipp, contact me in private. I can give you access to real data and server as we are in same country. (But data need to be kept private) So you can test and see the trouble. I've remade test with 0.8 and 0.9 ( they are working ! ) 1.0pre are bugging see report at https://bugzilla.mozilla.org/show_bug.cgi?id=501660
Comment 16•15 years ago
|
||
I'm presently able to add a significant detail to the depiction of the problem. It seems that the loop is triggered only when the inbox is devoided of pending ics files. In this specific case (as described in my previous comment) requests never stop. If I manage to add the "failing" user as attendee for any event, Lightning/CalDAV server chat becomes: ----------SNIP---------- CalDAV: send(http://192.168.100.6:8008/calendars/__uids__/2e0b72d0-d795-5456-85e1-f4642d7912d3/inbox/): <?xml version="1.0" encoding="UTF-8"?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:getcontenttype/> <D:getetag/> </D:prop> </D:propfind> CalDAV: recv: <multistatus> <response> <href>/calendars/__uids__/2e0b72d0-d795-5456-85e1-f4642d7912d3/inbox/</href> <propstat> <prop> <getcontenttype>httpd/unix-directory</getcontenttype> <getetag>W/"3FE16-1000-4A4B759D"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/calendars/__uids__/2e0b72d0-d795-5456-85e1-f4642d7912d3/inbox/986921ce05adefac8c903807efd5481d.ics</href> <propstat> <prop> <getcontenttype>text/calendar</getcontenttype> <getetag>"10d05d87a12afc9af5392f17d4675fd1"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> ----------SNIP---------- (note the enumeration of the ics). In this case, Lightning does *NOT* misbehave. To give out more details about the server side (even I don't think that is relevant): Debian 5.0.1 calendarserver 1.2.dfsg-8 python-twisted-calendars 0.2.0.svn19773-5 Philip, if you still need an account, just mail me.
Comment 17•15 years ago
|
||
To avoid any misunderstanding: please read "when inbox is devoided" as "when inbox is empty".
Comment 18•15 years ago
|
||
With sunbird 1.0pre ( release of 4July like previous release ) there always one of my 12 schedule bugging asking constanly something it doesn't exist ::1 - - [05/Jul/2009:14:35:36 +0200] "PROPFIND /caldav.php/hopital/home/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:36 +0200] "PROPFIND /caldav.php/orange/home/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:36 +0200] "PROPFIND /caldav.php/vacances/home/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:36 +0200] "PROPFIND /caldav.php/noir/home/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:36 +0200] "PROPFIND /caldav.php/vert/home/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:36 +0200] "PROPFIND /caldav.php/army/home/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:37 +0200] "PROPFIND /caldav.php/bleu/home/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:37 +0200] "PROPFIND /caldav.php/bras/home/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:37 +0200] "PROPFIND /caldav.php/hopital/home/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:37 +0200] "PROPFIND /caldav.php/maladie/home/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:37 +0200] "PROPFIND /caldav.php/special/home/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:37 +0200] "PROPFIND /caldav.php/vacances/home/ HTTP/1.1" 207 321 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:37 +0200] "PROPFIND /caldav.php/army/home/ HTTP/1.1" 207 318 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:37 +0200] "PROPFIND /caldav.php/orange/home/ HTTP/1.1" 207 319 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:37 +0200] "PROPFIND /caldav.php/noir/home/ HTTP/1.1" 207 317 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:37 +0200] "PROPFIND /caldav.php/hopital/home/ HTTP/1.1" 207 321 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:37 +0200] "PROPFIND /caldav.php/vert/home/ HTTP/1.1" 207 316 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "PROPFIND /caldav.php/bras/home/ HTTP/1.1" 207 318 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "PROPFIND /caldav.php/bleu/home/ HTTP/1.1" 207 318 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "PROPFIND /caldav.php/hopital/home/ HTTP/1.1" 207 321 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "PROPFIND /caldav.php/maladie/home/ HTTP/1.1" 207 320 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/army/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "PROPFIND /caldav.php/special/home/ HTTP/1.1" 207 319 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/vacances/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/orange/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/noir/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/hopital/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/vert/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/bras/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/bleu/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/hopital/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/maladie/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/special/ HTTP/1.1" 401 60 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/army/ HTTP/1.1" 200 20 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/orange/ HTTP/1.1" 200 20 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/vacances/ HTTP/1.1" 200 20 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/noir/ HTTP/1.1" 200 20 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/hopital/ HTTP/1.1" 200 20 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/vert/ HTTP/1.1" 200 20 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/bras/ HTTP/1.1" 200 20 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/bleu/ HTTP/1.1" 200 20 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/hopital/ HTTP/1.1" 200 20 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/maladie/ HTTP/1.1" 200 20 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "PROPFIND /caldav.php/army/ HTTP/1.1" 207 297 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "OPTIONS /caldav.php/special/ HTTP/1.1" 200 20 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "PROPFIND /caldav.php/vert/ HTTP/1.1" 207 296 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "PROPFIND /caldav.php/noir/ HTTP/1.1" 207 297 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "PROPFIND /caldav.php/orange/ HTTP/1.1" 207 298 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "PROPFIND /caldav.php/vacances/ HTTP/1.1" 207 299 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "PROPFIND /caldav.php/maladie/ HTTP/1.1" 207 299 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "PROPFIND /caldav.php/bras/ HTTP/1.1" 207 297 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "PROPFIND /caldav.php/hopital/ HTTP/1.1" 207 299 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "PROPFIND /caldav.php/hopital/ HTTP/1.1" 207 299 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "PROPFIND /caldav.php/bleu/ HTTP/1.1" 207 297 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "PROPFIND /caldav.php/special/ HTTP/1.1" 207 299 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:38 +0200] "PROPFIND /caldav.php/army/home/ HTTP/1.1" 207 593 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:39 +0200] "PROPFIND /caldav.php/maladie/home/ HTTP/1.1" 207 4748 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:39 +0200] "PROPFIND /caldav.php/bras/home/ HTTP/1.1" 207 6804 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:39 +0200] "PROPFIND /caldav.php/vacances/home/ HTTP/1.1" 207 12207 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:39 +0200] "PROPFIND /caldav.php/hopital/home/ HTTP/1.1" 207 19797 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:39 +0200] "PROPFIND /caldav.php/noir/home/ HTTP/1.1" 207 27400 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:41 +0200] "REPORT /caldav.php/army/home/ HTTP/1.1" 207 1106 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:39 +0200] "PROPFIND /caldav.php/vert/home/ HTTP/1.1" 207 30094 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:40 +0200] "PROPFIND /caldav.php/hopital/home/ HTTP/1.1" 207 19797 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:41 +0200] "REPORT /caldav.php/maladie/home/ HTTP/1.1" 207 9903 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:41 +0200] "REPORT /caldav.php/bras/home/ HTTP/1.1" 207 13763 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:41 +0200] "REPORT /caldav.php/vacances/home/ HTTP/1.1" 207 23203 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:41 +0200] "PROPFIND /caldav.php/special/home/ HTTP/1.1" 207 27480 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:41 +0200] "REPORT /caldav.php/hopital/home/ HTTP/1.1" 207 46469 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:42 +0200] "REPORT /caldav.php/noir/home/ HTTP/1.1" 207 65952 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:43 +0200] "REPORT /caldav.php/hopital/home/ HTTP/1.1" 207 46469 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:39 +0200] "PROPFIND /caldav.php/orange/home/ HTTP/1.1" 207 72016 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:43 +0200] "REPORT /caldav.php/vert/home/ HTTP/1.1" 207 63602 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:44 +0200] "REPORT /caldav.php/special/home/ HTTP/1.1" 207 57936 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:39 +0200] "PROPFIND /caldav.php/bleu/home/ HTTP/1.1" 207 103541 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:46 +0200] "REPORT /caldav.php/orange/home/ HTTP/1.1" 207 163198 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - vert [05/Jul/2009:14:35:47 +0200] "REPORT /caldav.php/bleu/home/ HTTP/1.1" 207 224325 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" ::1 - - [05/Jul/2009:14:36:10 +0200] "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.2.10 (Linux/SUSE) mod_ssl/2.2.10 OpenSSL/0.9.8h DAV/2 PHP/5.2.9 with Suhosin-Patch (internal dummy connection)" ::1 - vert [05/Jul/2009:14:36:50 +0200] "PROPFIND /caldav.php/noir/.in/ HTTP/1.1" 207 218 "-" "Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.1.1pre) Gecko/20090704 Calendar/1.0pre" This last line is repeated over & over. If I remove this schedule, sunbird is bugging with another. This don't happen with stable 0.9 ######### Here the sunbird debug (simple) messages ########### It's a cutted version CalDAV: refresh completed with status 207 at http://ical/caldav.php/bleu/home/ CalDAV: refresh completed with status 207 at http://ical/caldav.php/orange/home/ CalDAV: refresh completed with status 207 at http://ical/caldav.php/special/home/ CalDAV: refresh completed with status 207 at http://ical/caldav.php/vert/home/ CalDAV: refresh completed with status 207 at http://ical/caldav.php/hopital/home/ CalDAV: refresh completed with status 207 at http://ical/caldav.php/noir/home/ CalDAV: refresh completed with status 207 at http://ical/caldav.php/hopital/home/ CalDAV: refresh completed with status 207 at http://ical/caldav.php/vacances/home/ CalDAV: refresh completed with status 207 at http://ical/caldav.php/bras/home/ CalDAV: refresh completed with status 207 at http://ical/caldav.php/maladie/home/ CalDAV: refresh completed with status 207 at http://ical/caldav.php/army/home/ As you can see the ok is given for schedule "noir" but after it was asking empty etag like this extract from debug CalDAV: send(http://ical/caldav.php/noir/.in/): <?xml version="1.0" encoding="UTF-8"?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:getcontenttype/> <D:getetag/> </D:prop> </D:propfind> CalDAV: recv: <multistatus> <response> <href>/caldav.php/noir/.in/</href> <propstat> <prop> <getcontenttype>httpd/unix-directory</getcontenttype> <getetag>""</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> CalDAV: send(http://ical/caldav.php/noir/.in/): <?xml version="1.0" encoding="UTF-8"?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:getcontenttype/> <D:getetag/> </D:prop> </D:propfind> CalDAV: recv: <multistatus> <response> <href>/caldav.php/noir/.in/</href> <propstat> <prop> <getcontenttype>httpd/unix-directory</getcontenttype> <getetag>""</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> CalDAV: send(http://ical/caldav.php/noir/.in/): <?xml version="1.0" encoding="UTF-8"?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:getcontenttype/> <D:getetag/> </D:prop> </D:propfind> CalDAV: recv: <multistatus> <response> <href>/caldav.php/noir/.in/</href> <propstat> <prop> <getcontenttype>httpd/unix-directory</getcontenttype> <getetag>""</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus>
Comment 19•15 years ago
|
||
After we check all part of installation, It was found that the logging user has not the right on one schedule. leading to have create some strange collection (.in) on the serveur. We clean all wrong collection, clean the sunbird password manager and start with a user having all rights on the caldav server. We got succes, no more strange loop and bizarre access. For our opinion : it's closed on our side. But the trouble remain. If user have only read-access, or no acccess to the collection sunbird start bugging.
Comment 20•15 years ago
|
||
I think we should be more robust, it would be nice to have this for 1.0, but given it is something that can be fixed server-side, I won't block 1.0 for it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted-calendar1.0+
Flags: blocking-calendar1.0?
Flags: blocking-calendar1.0-
Summary: Infinite loop when requesting forbidden calendar lead to 100% server CPU → Wrong Server Response to inbox query leads to infinite loop of requests
Comment 21•15 years ago
|
||
In my specific case, the only thing that I can do on server side is to add an invitation to the lightning user and ask him/her to never reply the request. So, in my specific case let's say that can be fixed server-side, but it seems to be a very delicate workaround to me!
Comment 22•15 years ago
|
||
Also on my side, all errors encountered could be managed on the server-side. Event if it's could be a huge work. It would be nice to have a check inside sunbird, that stop it to ask information if it's the same over and over something between 50 to 100 requests. As there some of work to polish the 1.0 version, go on. But don't close this bug before it's really closed by some patches.
Comment 23•15 years ago
|
||
I've also reproduced this bug with Lightning on Windows Vista. When Lightning receive 401 from server, it attempts again and again in infinite loop (stopped Thunderbird after it sended 19000 unsuccessful PROPFIND). And, note!, it sends strange Pragma and Cache-Control fields - with growing number of 'no-cache' in these fields: =========== first request ============= PROPFIND /~postmaster/ HTTP/1.1 Host: myserver User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ru; rv:1.9.1.1) Gecko/20090715 Lightning/1.0pre Thunderbird/3.0b3 Accept: text/xml Accept-Language: ru,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: utf-8,*;q=0.1 Keep-Alive: 300 Connection: keep-alive Content-Length: 160 Content-Type: text/xml; charset=utf-8 Depth: 0 Authorization: Basic cG9... Pragma: no-cache Cache-Control: no-cache <D:propfind xmlns:D="DAV:" xmlns:CS="http://calendarserver.org/ns/"> <D:prop> <D:resourcetype/> <D:owner/> <CS:getctag/> </D:prop> </D:propfind> ====================== second =============== PROPFIND /~postmaster/ HTTP/1.1 Host: myserver User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ru; rv:1.9.1.1) Gecko/20090715 Lightning/1.0pre Thunderbird/3.0b3 Accept: text/xml Accept-Language: ru,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: utf-8,*;q=0.1 Keep-Alive: 300 Connection: keep-alive Content-Length: 160 Content-Type: text/xml; charset=utf-8 Depth: 0 Authorization: Basic cG9... Pragma: no-cache, no-cache Cache-Control: no-cache, no-cache <D:propfind xmlns:D="DAV:" xmlns:CS="http://calendarserver.org/ns/"> <D:prop> <D:resourcetype/> <D:owner/> <CS:getctag/> </D:prop> </D:propfind> ================================= 3rd ================= PROPFIND /~postmaster/ HTTP/1.1 Host: myserver User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ru; rv:1.9.1.1) Gecko/20090715 Lightning/1.0pre Thunderbird/3.0b3 Accept: text/xml Accept-Language: ru,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: utf-8,*;q=0.1 Keep-Alive: 300 Connection: keep-alive Content-Length: 160 Content-Type: text/xml; charset=utf-8 Depth: 0 Authorization: Basic cG9... Pragma: no-cache, no-cache, no-cache Cache-Control: no-cache, no-cache, no-cache <D:propfind xmlns:D="DAV:" xmlns:CS="http://calendarserver.org/ns/"> <D:prop> <D:resourcetype/> <D:owner/> <CS:getctag/> </D:prop> </D:propfind> =========================
Comment 24•15 years ago
|
||
A fine point regarding this bug that still prevents us to use the iTip routing for invitation (creating a lot of interaction problems among windows and mac users), is that this is triggered by setting: calendar.caldav.sched.enabled = true enabling internal routing (and not via iMip) of the invitations. I'm using TB 3.0b3 with lightning 1.0pre, nightly build 7 Sep 2009 on windows. Same thing happens if I use TB 3.0b2 + lightning 1.0pre on mac. No news at all? thanks!
Comment 25•15 years ago
|
||
I kind of suspect that there are a couple of different issues under discussion here, but this patch should deal with the trigger for this bug: calling pollInbox() immediately after polling the inbox on servers where the inbox is a separate collection from the principal's main calendar.
Assignee: nobody → browning
Attachment #405724 -
Flags: review?(philipp)
Updated•15 years ago
|
Attachment #405724 -
Flags: review?(philipp) → review+
Comment 26•15 years ago
|
||
Comment on attachment 405724 [details] [diff] [review] [checked in] don't poll inbox immediately after polling inbox Looks good, r=philipp
Comment 27•15 years ago
|
||
pushed to comm-central
Updated•15 years ago
|
Updated•15 years ago
|
Attachment #405724 -
Attachment description: don't poll inbox immediately after polling inbox → [checked in] don't poll inbox immediately after polling inbox
Comment 28•14 years ago
|
||
The core of the problem lies in calAuthUtils where irrespective of the previous state we keep sending the same authentication details from login-manager. Instead we should ensure that if a login attempt failed with the stored username/password, then we prompt the user to give new details.
Attachment #426220 -
Flags: review?(philipp)
Comment 29•14 years ago
|
||
Comment on attachment 426220 [details] [diff] [review] Check if the stored password was already used before using it again. >diff --git a/calendar/base/modules/calAuthUtils.jsm b/calendar/base/modules/calAuthUtils.jsm >--- a/calendar/base/modules/calAuthUtils.jsm >+++ b/calendar/base/modules/calAuthUtils.jsm >@@ -40,16 +40,18 @@ > Components.utils.import("resource://calendar/modules/calUtils.jsm"); > > /* > * Authentication helper code > */ > > EXPORTED_SYMBOLS = ["cal"]; // even though it's defined in calUtils.jsm, import needs this > cal.auth = { >+ mAlreadyTriedTheStoredPassword: {}, >+ > /** > * Auth prompt implementation - Uses password manager if at all possible. > */ > Prompt: function calPrompt() { > // use the window watcher service to get a nsIAuthPrompt impl > this.mPrompter = Components.classes["@mozilla.org/embedcomp/window-watcher;1"] > .getService(Components.interfaces.nsIWindowWatcher) > .getNewAuthPrompter(null); >@@ -237,25 +239,31 @@ cal.auth.Prompt.prototype = { > if (!this.mTriedStoredPassword) { > pw = this.getPasswordInfo(aPasswordRealm); > } > > if (pw && pw.found) { > this.mTriedStoredPassword = true; > aUser.value = pw.username; > aPwd.value = pw.password; >- return true; >- } else { >- return this.mPrompter.promptUsernameAndPassword(aDialogTitle, >- aText, >- aPasswordRealm, >- aSavePassword, >- aUser, >- aPwd); >+ >+ if (!cal.auth.mAlreadyTriedTheStoredPassword[aPasswordRealm]) { This might cause a strict warning. Instead, we should check: if (!(aPasswordRealm in cal.auth.mAlreadyTriedTheStoredPassword)) { > if (!this.mTriedStoredPassword) { > pw = this.getPasswordInfo(hostRealm); > } ... >+ if (!cal.auth.mAlreadyTriedTheStoredPassword[hostRealm]) { I'm a bit confused now. We have two variables that both get checked, and have similar names. What does each do? Why do we need two of those? Please use a different name, maybe something (iiuc) like mStoredPasswordFailed ? Also, some comments up where the variables are defined on the object would be nice. r- for now to get a new patch with comments considered.
Attachment #426220 -
Flags: review?(philipp) → review-
Comment 30•14 years ago
|
||
This seems to be a duplicate of bug 514652. Easy to reproduce. Jur.
Assignee | ||
Comment 32•14 years ago
|
||
Re-assigning to me after talking with Bruno.
Assignee: browning → simon.at.orcl
Assignee | ||
Comment 33•14 years ago
|
||
This patch uses an observer on http-on-examine-response to detect failed login attempts using a stored password, if a failed login attempt is detected, the credentials are removed from the password store. Note that this patch is done on top of the patch submitted for bug 550291 .
Attachment #430765 -
Flags: review?(philipp)
Comment 34•14 years ago
|
||
I haven't looked into your patch, but will this work with Kerberos, too? Or would that be another bug?
Assignee | ||
Comment 35•14 years ago
|
||
It should work (you are talking about SPNEGO right?) I but if you can email me a test server with credentials and setup instruction.
Comment 36•14 years ago
|
||
I not to familiar with the Kerberos internals, but opposed to a passoword, the ticket is provided by the Kerberos client not the user. I was therefore wondering how Lightning will behave. Will the user get a password request if he hasn't got a valid ticket?
Assignee | ||
Comment 37•14 years ago
|
||
Looking at bug 391493 I don't think Kerberos is even supported by Lighting. But if it was, i see 2 options: 1) The password store is used (which would be weird), it would most likely work because the patch relies on the fact that the Authorization header is set (as defined in basic/digest auth AND SPNEGO) in the request that fails so it would work the same way it works for basic/digest auth. 2) The password store is NOT used, kerberos is not affected by this bug, if a kerberos enabled client spins, it must be for another reason than what is described in this bug. That being said I might be wrong and if someone has a working server setup I would be happy to test it.
Comment 38•14 years ago
|
||
Yes, Kerberos works (I commented on the other bug), because I'm using it. ;-) I did watch the spinning, when my session timed out (DOSing the Sever). While I'm not able to get you an account I can run some tests if you tell me what to look for (I already did some hacking in Lightning, but never got it to the stage of patch-quality).
Assignee | ||
Comment 39•14 years ago
|
||
If you can apply the patch you could try to reproduce the problem by simply letting your session time out and see what happens. Also you could confirm that you see/don't see some sort of saved password for your Kerberos account there: Tools->Options->Security->Passwords->"Saved Passwords"
Assignee | ||
Comment 40•14 years ago
|
||
Attachment #430765 -
Attachment is obsolete: true
Attachment #430765 -
Flags: review?(philipp)
Assignee | ||
Updated•14 years ago
|
Attachment #431698 -
Flags: review?(philipp)
Assignee | ||
Comment 41•14 years ago
|
||
Attachment #426220 -
Attachment is obsolete: true
Attachment #431698 -
Attachment is obsolete: true
Attachment #431716 -
Flags: review?(philipp)
Attachment #431698 -
Flags: review?(philipp)
Comment 42•14 years ago
|
||
Comment on attachment 431716 [details] [diff] [review] [checked in] Fixed associative array use and OPTIONS req error handling Yes, I like this patch. I've added a comment for cal.auth.Prompt, but otherwise r=philipp.
Attachment #431716 -
Flags: review?(philipp) → review+
Comment 43•14 years ago
|
||
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/112ba8740afe> -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 14 years ago
Resolution: --- → FIXED
Target Milestone: 1.0 → 1.0b2
Updated•14 years ago
|
Attachment #431716 -
Attachment description: Fixed associative array use and OPTIONS req error handling → [checked in] Fixed associative array use and OPTIONS req error handling
Assignee | ||
Comment 45•14 years ago
|
||
I am re-opening this bug because while the fix stops the spin there are also 2 side effects which I do not find acceptable: 1) If many calendars are configured for the same host the nsIAuthPrompt2 implementation can (very often in my tests) be called for the same host which will result in a unnecessary password prompt for one of the calendars. 2) If for some reason the server returns another status code (ie: 503 service unavailable) the server will also end up prompting the user (which it shouldn't). The first fix I submitted does not have these issues so I would like it to be re-evaluated to replace the applied fix: https://bug435854.bugzilla.mozilla.org/attachment.cgi?id=430765 I will try one more thing on monday that might avoid the observer on all http requests but I'm not optimistic that it will work...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 46•14 years ago
|
||
Attachment #434119 -
Flags: review?(philipp)
Comment 47•14 years ago
|
||
Comment on attachment 434119 [details] [diff] [review] Patch that fixes unnecessary password prompts when multiple calendars on the same host are configured. Wow this works? Nice solution! r=philipp
Attachment #434119 -
Flags: review?(philipp) → review+
Comment 48•14 years ago
|
||
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/d7f91b76511a> Are all issues fixed now, or should we keep the bug open?
Assignee | ||
Comment 49•14 years ago
|
||
Yes, keeping a cal.auth.Prompt instance in each provider instances resolves the issue of many threads retrieving saved passwords at the same time, I also tested with various non-401 http error code and the behavior is good (it is not prompting for the password). I will keep an eye open for http digest potential issues however, which might happen if the auth token times out(It will not spin but might prompt for the password) I just don't have a setup with http digest enabled at the moment.
Comment 50•14 years ago
|
||
If Thunderbird works via HTTP-proxy and Lightning attempts to issue OPTIONS/PROPFIND commands to WebDAV server, and if proxy returns 407 code (NTLM auth required), and Lightning failed to authenticate (because of new issues with network.auth.force-generic-ntlm=false in latest Firefox and Thunderbird) - it falls into infinite loop of such "407" queries, get a lot of CPU, and none of password queries to user. (Mozilla/5.0 (Windows; U; Windows NT 6.0; ru; rv:1.9.2.2pre) Gecko/20100302 Lightning/1.0b2pre Lanikai/3.1b1)
Assignee | ||
Comment 51•14 years ago
|
||
I also fixed the error handling in the pseudo-synchronization call used for digest auth and changed the synch method from HEAD to OPTIONS because from personal experience, HEAD on a calendar collection can be pretty expensive while OPTIONS is almost a NOOP.
Attachment #436021 -
Flags: review?(philipp)
Comment 52•14 years ago
|
||
Can somebody please review ?
Comment 53•14 years ago
|
||
Comment on attachment 436021 [details] [diff] [review] This patch fixes an issue with Digest Auth prompting when the auth token expires What happens for multiple non-digest calendars on the same realm? Wouldn't there be more than one request per 60 seconds normally this way?
Attachment #436021 -
Flags: feedback?(simon.at.orcl)
Assignee | ||
Comment 54•14 years ago
|
||
There is one instance of the "auth" object per calendar so this really isn't an issue.
Comment 55•14 years ago
|
||
Comment on attachment 436021 [details] [diff] [review] This patch fixes an issue with Digest Auth prompting when the auth token expires In that case r=philipp.
Attachment #436021 -
Flags: review?(philipp)
Attachment #436021 -
Flags: review+
Attachment #436021 -
Flags: feedback?(simon.at.orcl)
Assignee | ||
Comment 56•14 years ago
|
||
Pushed to comm-central http://hg.mozilla.org/comm-central/rev/399bdce3f814
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Comment 58•13 years ago
|
||
The resolution of this bug has created a regression (Bug #588799) Specifically the changes made in http://hg.mozilla.org/comm-central/diff/112ba8740afe/calendar/providers/caldav/calDavCalendar.js
You need to log in
before you can comment on or make changes to this bug.
Description
•