Closed Bug 574610 Opened 15 years ago Closed 15 years ago

Regression: network calendars using CalDAV and eGroupware no longer work

Categories

(Calendar :: Provider: CalDAV, defect)

Product:
Calendar
Component:
Provider: CalDAV
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: nigel, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4 GTB7.0 ( .NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1 In tools->options->certificates->view certificates: server tab, the server certificate is there as it is being used by IMAP. On the previous version of this and Thunderbird you have to add a security exception for HTTPS for that server, but if you try to do that now it says that the certificate is already being allowed. On the error console, you get this. Warning: There has been an error reading data for calendar: xxxxx. However, this error is believed to be minor, so the program will attempt to continue. Error code: DAV_NOT_DAV. Description: The resource at https://xxx.xxx.xxx/egroupware/groupdav.php/calendar is either not a DAV collection or not available. Bear in mind that this error only happened after the upgrade. It was fine before that, the server is still up and running and it works with the older version or Thunderbird/lightning. I also get this: xxx.xxx.xxx : potentially vulnerable to CVE-2009-3555 Reproducible: Always Steps to Reproduce: 1. New calendar... 2. On the network 3. CalDAV, location https://xxx.xxx.xxx/egroupware/groupdav.php/calendar 4. Name xxxxx Actual Results: Yellow triangle with exclamation mark next to calendar: The calendar xxxxx is momentarily not available. Expected Results: Calendar view populated with events and no yellow triangle.
Does this happens only for CalDAV? What happens if you try to subscribe to a iCalendar (*.ics) file via HTTPS on your server?
Firstly, I have tried this on a machine inside the network on HTTP and not HTTPS and you still get the same problem. This means that my assumption that this was to do with certificates looks like it was incorrect. I have tried opening an iCal URL and this works, and the one event in that shows up on the calendar. The trouble is, of course, each .ics URL on the server contains just one event on the CalDAV server, so this is not in any way usable as a solution. So it looks like a regression has been introduced in the CalDAV client (unless, of course, people think that eGroupware has ceased to be CalDAV compliant).
I have now tried iCal on HTTPS and that works, so it would definitely appear not to be certificate related.
I also get this error in the error console: Warning: There has been an error reading data for calendar: xxxxxx. However, this error is believed to be minor, so the program will attempt to continue. Error code: READ_FAILED. Description: (but there is no description) The Apache access log gives this: nnn.nnn.nnn.nnn - xxxxx [26/Jun/2010:11:22:01 +0100] "PROPFIND /egroupware/groupdav.php/calendar/ HTTP/1.1" 207 1037 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1" which is as you would expect, and there is nothing in the Apache error log, so there is nothing going wrong at HTTP level. Note also, that this is the only access entry. You would expect Lightning to then go on the read all the events, but it doesn't.
Summary: Network calendars with self-signed certificates can't be accessed → Regression: network calendars using CalDAV and eGroupware no longer work
Component: Security → Provider: CalDAV
I've turned on calendar verbose debugging and here is what comes out of the error console: CalDAV: Status 207 on initial PROPFIND for calendar xxxxxx CalDAV: Authentication scheme for xxxxxx is Basic Warning: There has been an error reading data for calendar: xxxxxx. However, this error is believed to be minor, so the program will attempt to continue. Error code: DAV_NOT_DAV. Description: The resource at http://xxx.xxx.xxx/egroupware/groupdav.php/xxxxxx/calendar is either not a DAV collection or not available Warning: There has been an error reading data for calendar: xxxxxx. However, this error is believed to be minor, so the program will attempt to continue. Error code: READ_FAILED. Description:
Are you really using the correct URL? We don't auto detect the right url from its base url yet like iCal does, you need to specify the exact url of the calendar collection.
I restarted Thunderbird (as this seemed necessary to pick up the verbose cal logging setting), and this was also emitted between the last "CalDav:" and the first "Warning:"... CalDAV: recv: <?xml version="1.0" encoding="utf-8"?> <D:multistatus xmlns:D="DAV:"> <D:response xmlns:ns0="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/" xmlns:ns1="urn:ietf:params:xml:ns:caldav" xmlns:ns2="http://calendarserver.org/ns/"> <D:href>/egroupware/groupdav.php/xxxxxx/calendar/</D:href> <D:propstat> <D:prop> <D:owner>Xxxxx Xxxxxxx</D:owner> <D:resourcetype><collection /><vevent-collection xmlns="http://groupdav.org/" /><calendar xmlns="urn:ietf:params:xml:ns:caldav" /></D:resourcetype> <ns1:supported-calendar-component-set xmlns:ns1="urn:ietf:params:xml:ns:caldav"><ns1:comp name="VEVENT"/></ns1:supported-calendar-component-set> <D:supported-report-set><supported-report><report><urn:ietf:params:xml:ns:caldav>calendar-multiget</urn:ietf:params:xml:ns:caldav></report></supported-report></D:supported-report-set> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> <D:propstat> <D:prop> <ns2:getctag/> </D:prop> <D:status>HTTP/1.1 404 Not Found</D:status> </D:propstat> </D:response> </D:multistatus> Thus, line 1357 of calDavCalendar.js - "var multistatus = cal.safeNewXML(str);" - must be throwing an exception, possibly due to the 404.
Yes, it is the correct URL. Remember: I had all this correct and working with TB3.0x/L1.0b1, I changed nothing and upgraded to TB3.1/L1.0b2 and it stopped working.
I did a bit of googling around and found this: http://markmail.org/thread/xtlyfwvjzts5qsnh It seems that this may not be the first time this problem has been encountered. Mr Kewisch: I notice your name is among the respondents.
In 1.0b2 we added querying for supported-report-set. Its possible that eGroupware doesn't answer this report correctly. I get the following errors when validating the xml you posted: bug574610:17: namespace error : Failed to parse QName 'urn:ietf:' <D:supported-report-set><supported-report><report><urn:ietf:params:xml:ns:caldav ^ bug574610:17: namespace error : Namespace prefix urn on ietf:params:xml:ns:caldav is not defined <D:supported-report-set><supported-report><report><urn:ietf:params:xml:ns:caldav ^ Could you try this with a newer version of eGroupware?
QA Contact: calendar → caldav-provider
The server is eGroupWare Version 1.6.003, which is the latest version according to http://www.egroupware.org/
That tag is listed here: http://www.iana.org/assignments/xml-registry/ns.html If you open the caldav URL with a web browser, part of what you get is this: Properties Namespace Name Value DAV current-user-principal <href>http://jeeves/egroupware/groupdav.php/principals/users/xxxxxx/</href> DAV owner Xxxxxx Xxxxxxx DAV principal-URL <href>http://xxx.xxx.xxx/egroupware/groupdav.php/principals/users/xxxxxx/</href> DAV alternate-URI-set <href>MAILTO:xxxxxx@xxx.xxx.xxx</href> CalDAV calendar-user-address-set <href>MAILTO:xxxxxx@xxx.xxx.xxx</href> DAV principal-collection-set <href>/egroupware/groupdav.php/principals/users/</href><href>/egroupware/groupdav.php/principals/groups/</href> CalDAV calendar-home-set <href>/egroupware/groupdav.php/xxxxxx/calendar/</href> CardDAV addressbook-home-set <href>/egroupware/groupdav.php/xxxxxx/</href> DAV displayname Xxxxx Xxxxxxx DAV resourcetype <collection /><vevent-collection xmlns="http://groupdav.org/" /><calendar xmlns="urn:ietf:params:xml:ns:caldav" /> GroupDAV component-set VEVENT CalDAV calendar-description Xxxxx Xxxxxxx CalDAV supported-calendar-component-set <comp xmlns="urn:ietf:params:xml:ns:caldav"><VEVENT xmlns="" /></comp> DAV supported-report-set <supported-report><report><urn:ietf:params:xml:ns:caldav>calendar-multiget</urn:ietf:params:xml:ns:caldav></report></supported-report>
I put some extra debug in and its definitely falling over at line 1359 of calDavCalendar.js, which is an exception thrown by cal.safeNewXML(str). Tracing it further, I find that the thing that throws the exception is the statement: new XML(aStr.trim().replace(/^<\?xml[^>]*>\s*/g, "")) in calProviderUtils.jsm (line 129). ???!!!???
The XML in question is specifically this bit: <D:supported-report-set> <supported-report> <report> <ietf:params:xml:ns:caldav>calendar-multiget</ietf:params:xml:ns:caldav> </report> </supported-report> </D:supported-report-set> The problem is that "ietf" is not a validly defined namespace, so the xml is plain wrong. The namespaces defined are ns0, ns1 and ns2. I believe the correct reply should be: <D:supported-report-set> <supported-report> <report> <ns1:calendar-multiget/> </report> </supported-report> </D:supported-report-set> I read this out of rfc3253, section 3.1.5. Specifically it states the structure is: <!ELEMENT supported-report-set (supported-report*)> <!ELEMENT supported-report report> <!ELEMENT report ANY> ANY value: a report element type This means that a "supported-report-set" has multiple "supported-report" children, which has one "report" child, which has ANY report element type. The report element type in this case is <calendar-multiget/>, in the caldav namespace (which is defined as ns1 in this case). (In reply to comment #13) > I put some extra debug in and its definitely falling over at line 1359 of > calDavCalendar.js, which is an exception thrown by cal.safeNewXML(str). Tracing > it further, I find that the thing that throws the exception is the statement: > > new XML(aStr.trim().replace(/^<\?xml[^>]*>\s*/g, "")) This fits with my theory. Doing the following in xpcshell: new XML("<ietf:params:xml:ns:caldav>calendar-multiget</ietf:params:xml:ns:caldav>") gives me the following error: 1: SyntaxError: invalid XML qualified name: 1: <parent xmlns=""><ietf:params:xml:ns:caldav>calendar-multiget</ietf:params:xml:ns:caldav></parent> Therefore this is (again) an egroupware bug (sorry!). Please file a bug at the egroupware bugtracker, feel free to reference this bug for explaining whats going wrong there.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
> The problem is that "ietf" is not a validly defined namespace, so the xml is > plain wrong. The namespaces defined are ns0, ns1 and ns2. Sorry, I was looking at the sanatized XML, of course I mean that "urn" is not a valid namespace. > 1: SyntaxError: invalid XML qualified name: > 1: <parent > xmlns=""><ietf:params:xml:ns:caldav>calendar-multiget</ietf:params:xml:ns:caldav></parent> The same error happens when adding "urn:".
Problem is solved now in EGroupware svn for all branches. Thanks for supporting the EGroupware project. Ralf
You need to log in before you can comment on or make changes to this bug.