User Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0 Build ID: 20110615151330 Steps to reproduce: After updating TB from v3 to v5 and Lightning to 1.0b4 I cannot access CalDAV-Calendars anymore. Actual results: When loading the calendar, the Error-Console shows: Warnung: Fehler beim Lesen von Daten für Kalender: Caldav. Allerdings ist dieser Fehler wahrscheinlich vernachlässigbar, daher versucht das Programm fortzufahren. Fehlercode: DAV_NOT_DAV. Beschreibung: Die Ressource auf https://xxx/caldav/xxx/home/xxx/calendars/MyCalendar/ ist entweder keine DAV-Sammlung oder sie ist nicht verfügbar Warnung: Fehler beim Lesen von Daten für Kalender: CalDav. Allerdings ist dieser Fehler wahrscheinlich vernachlässigbar, daher versucht das Programm fortzufahren. Fehlercode: READ_FAILED. Beschreibung: Fehler: Assert failed: replay action failed: null, uri=https://xxx/caldav/xxx/home/xxx/calendars/MyCalendar/, result=2147500037, op=[xpconnect wrapped calIOperation] 2: [resource://calendar/modules/calUtils.jsm -> file:///C:/Dokumente%20und%20Einstellungen/xxx/Anwendungsdaten/Thunderbird/Profiles/o1sv94r6.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCachedCalendar.js:236] null 3: [file:///C:/Dokumente%20und%20Einstellungen/xxx/Anwendungsdaten/Thunderbird/Profiles/o1sv94r6.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calDavCalendar.js:1913] caldav_completeCheckServerInfo 4: [file:///C:/Dokumente%20und%20Einstellungen/xxx/Anwendungsdaten/Thunderbird/Profiles/o1sv94r6.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calDavCalendar.js:1401] checkDavResourceType_oSC Quelldatei: resource://calendar/modules/calUtils.jsm -> file:///C:/Dokumente%20und%20Einstellungen/xxx/Anwendungsdaten/Thunderbird/Profiles/o1sv94r6.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calUtils.js Zeile: 980 The calendar itself is completely empty. The Server is up and running, accessing it from a older TB version works
Please enable calendar.debug.log and calendar.debug.log in the advanced config editor (options > advanced > general > config editor) and then restart. You should get lots of debug info in the error console, please copy that stuff into a file and attach here. Also, what type of caldav server is it and do you know the version used?
I enabled debug.log and debug.log.verbose, and got some more debug output. Logfile is attached. The Server is a Oracle Beehive System, but don't know the version.
What happens if you enter https://server/caldav/xxx/home/user/calendars/MyCalendar/ in a browser? Maybe the url changed? Is this the oracle.com caldav server, or another one? You seem to be using the cache, you could try resetting the cache with one of the following methods: * Deactivate the cache, restart, reactivate the cache If that doesn't work: * Quit, remove/rename calendar-data/cache.sqlite in your profile folder.
The URLs haven't changed, also the servers configuration wasn't changed. The calendars are still working with the latest Thunderbird 3 and Lightning 1.0b2. When entering the URLs in a browser, the system shows a website to access the calendars entries. Every single entry is accessible as a ICS-File. Adding the ICS URL as a remote ICS-Calendar is not working. Downloading it and importing it then works, so I guess it's not the fileformat. Deactivating the cache as well as clearing cache.sqlite had no effect. Installing TB and Lightning from scratch with a new profile had no effect too. Only the calendars of this oracle systems are not working (on different machines, Windows as well as Linux). Remote ICS-Calendars of a Horde/Kronolith systems are still working perfectly.
Could you show us the logs without the cache enabled? Simon, maybe you have experienced this issue with oracle.com?
I just tried with cache enabled and again without cache. No effect at all, also the output in the logs stay the same.
If you go with a browser to : https://<host:port>/caldav/<enterprise>/Help.html and copy the url exactly as it is from the "Configuring Lightning" section, is it working? percent encoding of the url can make a difference. You could also email me the full logs without the hostname obfuscated. Knowing what the http code was returned on the propfind call would also help (I'm surprised it's not logged with the trace enabled). If you are using windows you could use Fiddler ( http://www.fiddler2.com/fiddler2/ ) to trace the requests sent by Lightning and see the http code returned by the server.
The URL is exactly as given in the Help.html. I now replaced the https with http, and checked the traffic in Wireshark. The Server answers with a Error 301 Moved Permanently. I'll now try to downgrade to TB3 with Lightning 1.0b2, this combination worked and still works for colleagues. Then I'll recheck the traffic and see if there is any difference in the PROPFIND
It is usually expected that the server will respond with a 301 (redirect) if you try to connect to it without encryption, it will redirect to https... So that is most likely not the error you would get when using the proper https url. I've been using TB5 w/ Lightning since it was released on Beehive 2.0.x servers without any problems so this is most likely a configuration issue. I will email you from my work address.
Hello, we use Beehive version 18.104.22.168 too. After update to TB 5.0 and Lightning 1.0b4 some users can access there calendar without problem. Other users get the error messages from above. (errorcode) Fehlercode: DAV_NOT_DAV (errorcode) Fehlercode: READ_FAILED All users used the same syntax for the url. All users must use HTTPS with username and password. We try it also with fresh installation of TB and Lightning. Problem: Lightning never asks for username and password!
Hi, we are also using Beehive 22.214.171.124 . After upgrading to TB5 and Lightning 1.0b4 we are facing the problem that no user is able to access his calendar. We are using the correct https-url. I think the problem is the authentication. Like at Ronald's system, no auth-request is coming up, even after deleting all saved passwords an authentication data.
Simon, any updates on this? If we need a fix for this it needs to happen asap.
Unfortunately I haven't found the time to trace the calls with fiddler yet. I hope I find the time for this tests tomorrow.
Hello, I played a little bit with fiddler. I upload two sessions. do_work.saz -> very old TB with Lightning installation. (starting with TB 2.0 or so...) updated to TB 5.0 with Lightning (latest nightly build) do_not_work.saz -> fresh TB 5.0 with Lightning (latest nightly build) In both cases I used http connection with the same account. If I understand it right in do_work.saz I got "HTTP 401" in do_not_work.saz I got "HTTP 301"
some strange in the logs do work "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20090812 Lightning/0.9 Thunderbird/188.8.131.52 Mnenhy/0.7.5.0 Lightning/1.0b4pre" do not work "ser-Agent: Mozilla/5.0 (Windows NT 5.0; rv:5.0) Gecko/20110624 Thunderbird/5.0 Lightning/1.0b4pre"
Attachment #545899 - Attachment description: it does work → it does not work
The content of attachment 545898 [details] has been deleted by Dave Miller [:justdave] <firstname.lastname@example.org> who provided the following reason: contains passwords The token used to delete this attachment was generated at 2011-07-14 16:52:23 PDT.
The content of attachment 545899 [details] has been deleted by Dave Miller [:justdave] <email@example.com> who provided the following reason: contains passwords The token used to delete this attachment was generated at 2011-07-14 16:52:35 PDT.
After further investigations (I actually forgot we changed some server side configuration to make this work), this seems to be a server side configuration issue, 184.108.40.206 Beehive servers are not yet certified to run tb 5 w/ lighting 1.0b4 and as a result some protection code kicks in unnecessarily. Please have the admin of the Beehive servers contact Oracle support (or send me an email) to get instructions on how to apply the configuration profile on the beehive server to resolve this issue.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
Hi, here the Statement of Oracle Support: Notes 06-Jul-2011 10:25:55 GMT+02:00 AM Oracle Support Unscheduled Generic Note ------------------------ Issue is due to change in the user-agent string information being passed by Lightning to the server. There is already an internal bug filed for this and is planned to be fixed in Beehive 220.127.116.11 Bug 12568319: [ER] SUPPORT UPCOMING THUNDERBIRD 5.0 WITH LIGHTNING 1.0B4 You can refer the below bug for more information on the issue https://bugzilla.mozilla.org/show_bug.cgi?id=660522
There is a (dirty) Workaround to make it run with TB5: In the profile directory (where the prefs.js is located) create a new file "user.js" with the following text: user_pref("general.useragent.override", "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:18.104.22.168) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11"); Restart TB and it should work
Thank you Florian, it works
Created attachment 546107 [details] dirty workaround for Beehive 22.214.171.124 just copy the file to TB5 profile directory where prefs.js is located
Hello Florian, it also works for me. Thank you very much.
Simon, sounds like you are doing some special casing in Beehive for Lightning? Is there anything we can do to make it more conforming so that special casing is not needed? If so, maybe you could file/reference a bug to fix that.
You need to log in before you can comment on or make changes to this bug.