668463 - Loading a CalDAV Calendar fails on TB 5.0 with Lightning 1.0b4

Status: RESOLVED INVALID

(Calendar :: Provider: CalDAV, defect)

Description

[Florian B]

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

Comment 1

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

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?

Comment 2

[Florian B]

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.

Comment 3

[Florian B]

Attachment: Logfile with debug.log and debug.log.verbose enabled

Comment 4

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

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.

Comment 5

[Florian B]

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.

Comment 6

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

Could you show us the logs without the cache enabled?

Simon, maybe you have experienced this issue with oracle.com?

Comment 7

[Florian B]

I just tried with cache enabled and again without cache. No effect at all, also the output in the logs stay the same.

Comment 8

[Simon Vaillancourt]

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.

Comment 9

[Florian B]

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

Comment 10

[Simon Vaillancourt]

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.

Comment 11

[Ronald B]

Hello,
we use Beehive version 2.0.1.5 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!

Comment 12

[Christian Hauser]

Hi,

we are also using Beehive 2.0.1.5 .
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.

Comment 13

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

Simon, any updates on this? If we need a fix for this it needs to happen asap.

Comment 14

[Florian B]

Unfortunately I haven't found the time to trace the calls with fiddler yet. I hope I find the time for this tests tomorrow.

Comment 15

[Ronald B]

Attachment: it works

Comment 16

[Ronald B]

Attachment: it does not work

Comment 17

[Ronald B]

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"

Comment 18

[Ronald B]

some strange in the logs

do work
"User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 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"

Comment 19

[Dave Miller [:justdave]]

The content of attachment 545898 [details] has been deleted by
    Dave Miller [:justdave] <[e-mail]>
who provided the following reason:

contains passwords

The token used to delete this attachment was generated at 2011-07-14 16:52:23 PDT.

Comment 20

[Dave Miller [:justdave]]

The content of attachment 545899 [details] has been deleted by
    Dave Miller [:justdave] <[e-mail]>
who provided the following reason:

contains passwords

The token used to delete this attachment was generated at 2011-07-14 16:52:35 PDT.

Comment 21

[Simon Vaillancourt]

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, 2.0.1.5 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.

Comment 22

[Christian Hauser]

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 2.0.1.6
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

Comment 23

[Florian B]

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:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11"); 

Restart TB and it should work

Comment 24

[Christian Hauser]

Thank you Florian, it works

Comment 25

[Christian Hauser]

Attachment: dirty workaround for Beehive 2.0.1.5

just copy the file to TB5 profile directory where prefs.js is located

Comment 26

[Ronald B]

Hello Florian, it also works for me. Thank you very much.

Comment 27

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

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.