Wrong Server Response to inbox query leads to infinite loop of requests

RESOLVED FIXED in 1.0b2

Status

defect
--
major
RESOLVED FIXED
11 years ago
9 years ago

People

(Reporter: edouard.gaulue, Assigned: nomisvai)

Tracking

unspecified
1.0b2
Dependency tree / graph
Bug Flags:
blocking-calendar1.0 -
wanted-calendar1.0 +

Details

Attachments

(4 attachments, 3 obsolete attachments)

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.
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.
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.  
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.
0.8 for me, I'll test with a nightly.
I use lightning 0.8 64 bits.

As far as I know there is no nightly build for 64 bits. I'd like to.
With the mac OS X one, the bug can not be reproduced. Seems to be OK, thanks.
Closing bug based on comment #6. Relevant checkin was in bug 400835.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Duplicate of this bug: 434582
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...
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
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?
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.
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.
Needs more investigation to decide blocking status!
Flags: blocking-calendar1.0?
Keywords: qawanted
OS: Linux → All
Hardware: x86 → All
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?
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
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.
To avoid any misunderstanding: please read "when inbox is devoided" as "when inbox is empty".
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>
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.
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
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!
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.
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>
=========================
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!
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)
Attachment #405724 - Flags: review?(philipp) → review+
Comment on attachment 405724 [details] [diff] [review]
[checked in] don't poll inbox immediately after polling inbox

Looks good, r=philipp
pushed to comm-central
Status: NEW → ASSIGNED
Keywords: qawanted
Target Milestone: --- → 1.0
Attachment #405724 - Attachment description: don't poll inbox immediately after polling inbox → [checked in] don't poll inbox immediately after polling inbox
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 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-
This seems to be a duplicate of bug 514652. Easy to reproduce.

Jur.
Duplicate of this bug: 514652
Re-assigning to me after talking with Bruno.
Assignee: browning → simon.at.orcl
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)
Blocks: 520833
I haven't looked into your patch, but will this work with Kerberos, too? Or would that be another bug?
It should work (you are talking about SPNEGO right?) I but if you can email me a test server with credentials and setup instruction.
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?
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.
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).
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"
Posted patch patch without using observers (obsolete) — Splinter Review
Attachment #430765 - Attachment is obsolete: true
Attachment #430765 - Flags: review?(philipp)
Attachment #431698 - Flags: review?(philipp)
Attachment #426220 - Attachment is obsolete: true
Attachment #431698 - Attachment is obsolete: true
Attachment #431716 - Flags: review?(philipp)
Attachment #431698 - Flags: review?(philipp)
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+
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/112ba8740afe>

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 11 years ago10 years ago
Resolution: --- → FIXED
Target Milestone: 1.0 → 1.0b2
Attachment #431716 - Attachment description: Fixed associative array use and OPTIONS req error handling → [checked in] Fixed associative array use and OPTIONS req error handling
Duplicate of this bug: 520833
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 → ---
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+
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/d7f91b76511a>

Are all issues fixed now, or should we keep the bug open?
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.
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)
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)
Can somebody please review ?
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)
There is one instance of the "auth" object per calendar so this really isn't an issue.
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)
Pushed to comm-central http://hg.mozilla.org/comm-central/rev/399bdce3f814
Status: REOPENED → RESOLVED
Closed: 10 years ago9 years ago
Resolution: --- → FIXED
Duplicate of this bug: 572881
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.