Closed Bug 918899 Opened 12 years ago Closed 12 years ago

Thunderbird/24.0 Lightning/2.6b3 don’t display Zarafa CalDAV calendar any more / status code 401

Categories

(Calendar :: Provider: CalDAV, defect)

Product:
Calendar
Component:
Provider: CalDAV
Version:
Lightning 2.6
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: ralph, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36 Steps to reproduce: Today TB and LN upgraded from Thunderbird/17.0.8 Lightning/1.9.1 to Thunderbird/24.0 Lightning/2.6b3. Actual results: From this moment, my CalDAV calendar on a Zarafa server is not displayed any more. LN: The calendar is not available at the moment. (in German, so the message in English may differ) Zarafa server log: Fri Sep 20 18:12:10 2013: [10153] 37.24.146.65 - xxmynamexx [20/Sep/2013:18:12:10 +0200] "REPORT /caldav/xxmynamexx/Kalender/ HTTP/1.1" 207 145031 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 Lightning/1.9.1" Fri Sep 20 18:12:11 2013: [10153] 37.24.146.65 - xxmynamexx [20/Sep/2013:18:12:11 +0200] "REPORT /caldav/xxmynamexx/ HTTP/1.1" 301 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 Lightning/1.9.1" Fri Sep 20 18:12:12 2013: [10153] 37.24.146.65 - xxmynamexx [20/Sep/2013:18:12:12 +0200] "REPORT /caldav/xxmynamexx/Kalender/ HTTP/1.1" 207 151840 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 Lightning/1.9.1" Fri Sep 20 18:12:12 2013: [10153] 37.24.146.65 - xxmynamexx [20/Sep/2013:18:12:12 +0200] "REPORT /caldav/xxmynamexx/ HTTP/1.1" 301 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 Lightning/1.9.1" Fri Sep 20 18:12:12 2013: [10153] 37.24.146.65 - xxmynamexx [20/Sep/2013:18:12:12 +0200] "REPORT /caldav/xxmynamexx/Kalender/ HTTP/1.1" 207 33420 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 Lightning/1.9.1" Fri Sep 20 18:40:55 2013: [11361] 37.24.146.65 - - [20/Sep/2013:18:40:55 +0200] "PROPFIND /caldav/xxmynamexx/ HTTP/1.1" 401 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 Lightning/2.6b3" Fri Sep 20 18:40:55 2013: [11361] 37.24.146.65 - xxmynamexx [20/Sep/2013:18:40:55 +0200] "PROPFIND /caldav/xxmynamexx/ HTTP/1.1" 207 1240 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 Lightning/2.6b3" Expected results: LN should access calendar as before.
The same on Arch linux, which has latest TB and LN releases too.
Severity: normal → blocker
I tested with several combinations of TB and LN and from Lightning/2.0b1 on the CalDAV URI in LN has to be /caldav/xxmynamexx/Kalender/ instead of /caldav/xxmynamexx/ As it can be seen in the description above, the Zarafa server sent a "301 Moved Permanently" with clients before Lightning/2.0b1 which leads to the correct URI.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Hmm this has been the third time I've seen this. /caldav/xxmynamexx/ is the principal URL, right? Accessing this one has never worked in Lightning, it always had to be the collection URL. Is this maybe a server side rewrite thats auto-directing users to the default calendar?
CalDAV access on a Zarafa server is described here: http://doc.zarafa.com/7.1/Administrator_Manual/en-US/html-single/index.html#_calendar_access On this Zarafa server I access my own default calendar. Before LN 2.0b1 this URI worked:/caldav/xxmynamexx/ For every request with this URI, Zarafa responded with status code 301 and with the succeeding request /caldav/xxmynamexx/Kalender the response was status code 207 and the calendar got displayed. However, starting with LN 2.0b1 (without changing anything on the Zarafa side) /caldav/xxmynamexx/ stopped working and has to be /caldav/xxmynamexx/Kalender
Sorry, it is /caldav/xxmynamexx/Kalender/ (with a trailing slash)
Same problem, Zarafa user too. For me URL is: http://<server>:8080/caldav/<user>
Same problem with lightning 2.6.1
So this works in Lightning 1.9.1 and Thunderbird 17, but fails with Lightning 2.0b1 and Thunderbird 18.0b1?
One problem seems to be, that Zarafa changed the URI over time. Some time ago it happened to be http://server:8080/caldav/ for user’s own default calendar. With Zarafa 7.1, which is installed on my box, the URI is supposed to be http://server:8080/caldav/<user>/<calendar> for the user’s own default calendar (see manual). With Zarafa 7.1 I had /caldav/xxmynamexx/, which worked unless LN 2.0b1. Before LN 2.0b1 the Zarafa server responded with status code 301 and with the succeeding request /caldav/xxmynamexx/Kalender/ the response was status code 207 and the calendar got displayed. With LN 2.0b1 LN stopped working for me and the URI has to be /caldav/xxmynamexx/Kalender/ at first place to get it working.
That's strange ... when I just go to https://server/caldav/ with Firefox (and Zarafa 7.1) I get ICS file properly downloaded. Why Lightning cannot do it, when Firefox can?
The old sunbird app works quite happily too ...
You need to log in before you can comment on or make changes to this bug.