ICal and Addressbook connecting to eGroupware - various bugs?

Question

Hi all,
given CalDAV and CardDAV as standardized protocols, it shouldn't be too much of a problem to connect to private calendar and addressbook servers, you'd think... For some year's I'm running a eGroupware server, and while this product is far from being bug free, I believe it's basically massive bugs in Apple's Ca*DAV protocols that keep the synchronization from working. Let's start with iCal:
Originally, eGroupware's CalDAV implementation returned fully qualified URIs (like https://www.example.com/egroupware/calendar/) for all kinds of properties, e.g. calendar-home-set. As a result, iCal sent requests with the path //www.example.com/egroupware/calendar - i.e. instead of properly parsing the URI, it just stripped off the protocoll indicator and tried to treat the remaining string as a path.
As the CalDAV standard doesn't make any hint if URIs should be supplied as fully qualified or relative URIs, returning full URIs seems to be the safer bet, and iCal's reaction on this is IMHO as clearly a bug as it can be. Nevertheless, I patched eGroupware to supply relative URIs, and hey ho, iCal integrates fine with eGroupware now. By the way, eGroupware has some hard coded behaviour to supply only the events of one month back by default, but you can patch that behaviour as well, of course.
Now to Addressbook, and that's where I'm beyond my wits First of all, it is not possible to configure a CardDAV server in Addressbook itself, as the GUI is massively broken (just try to setup a CardDAV server https://www.example.com/egroupware/addressbook/ and you'll end up with a configured URL https://www.exmaple.com:443/egroupware/addressbook/:443<null> or something even more broken. You need to edit the file "Application Support/AddressBook/Sources/78E03291-22C9-4E27-9852-8480AD6A0F03/Configuration. plist" manually.
Now, still Addressbook sends a PROPFIND requst for current-user-privilege-set to /directory/ to the server. Don't know what kind of result the programmers expected from this, but on my CalDAV server nothing at all resides under that path, also it's not mentioned in the CalDAV as a general concept. After it got a 405 Method Not Allowed to this request, Addressbook continues sending more sensible requests, so it might not be an actual problem - I'm not sure.
Next is a PROPFIND query for addressbook-home-set to /egroupware/groupdav.php/addressbook/ wich is a perfectly expected behaviour from the standard. But first, the server replies with 401 Unauthorized. Addressbook then repeats the request, this time including the correct HTTP BASIC authentication information. Now, the server tries its best to handle this request according to standards. I quote the full response here, perhaps some pro spots a mistake in the response I'm to dumb to see:
HTTP/1.1 207 Multi-Status
Date: Sun, 06 Sep 2009 14:51:58 GMT
Server: Apache/2.2.12 (Debian)
X-Powered-By: PHP/5.2.10-2.2
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Expires: Thu, 19 Nov 1981 08:52:00 GMT
X-Dav-Powered-By: eGroupWare CalDAV/CardDAV/GroupDAV server
X-WebDAV-Status: 207 Multi-Status
Content-Length: 486
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/xml; charset="utf-8"
<?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:carddav">
<D:href>/egroupware/groupdav.php/addressbook/</D:href>
<D:propstat>
<D:prop>
<ns1:addressbook-home-set><D:href>/egroupware/groupdav.php/addressbook/</D:href ></ns1:addressbook-home-set>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
I read the CardDAV RFC over and over again, but this seems to be as correct a response as you could wish. Note: out of the box eGroupware doesn't generate the D:href sub-element to ns1:addressbook-home-set but directly puts the URI as content of that element. This is not correct according to the CardDAV standard, but iCal is ignoring exactly the same mistake of the CalDAV implementation of eGroupware. It doesn't make a difference for Addressbook either - both variants lead to the error message 'Von CardDAV-Server Fehler (207) für den Benutzer "xxx" erhalten.' This is a strange message to show, as 207 is not an error code. Of course I patched eGroupware to return 200 OK as HTTP status (contradicting the standard), and hey ho, in Konsole you'll see an error message stating "Expected multi-status response but got status code: 200".
So - Addressbook actually expects and checks for 207 Multi-Status, i.e. the message on the GUI is giving us no indication on the actual problem. Some easy checks proved that Addressbook wouldn't react any different if the server replies with plain nonsense (e.g. syntax errors in the XML file). So, obviously, Addressbook can't cope with an aspect of the response it gets, fails to generate any log or message box about the problem, and sets a misleading error indication on the GUI.
And now? Does anybody have a good hint what could Addressbook make work here? When can fixes to iCal and Addressbook realistically be expected, if at all?

Answer 1

Hello Pelzi,
Same problem here with iCal an eGroupware. Since I opgraded to SnowLeopard, my Calander isn't syncing anymore.
*iCal sends this:*
PROPFIND //192.168.3.199/egroupware/groupdav.php/calendar/ HTTP/1.1
Host: 192.168.3.199
User-Agent: DAVKit/4.0 (729); CalendarStore/4.0 (965); iCal/4.0 (1362); Mac OS X/10.6 (10A432)
Authorization: Basic ******
Depth: 1
Content-Type: text/xml
Content-Length: 143
Connection: keep-alive
<?xml version="1.0" encoding="utf-8"?>
<x0:propfind xmlns:x0="DAV:">
<x0:prop>
<x0:getetag/>
<x0:resourcetype/>
</x0:prop>
</x0:propfind>
*And Groupdav replies:*
HTTP/1.1 405 Method Not Allowed
Date: Mon, 07 Sep 2009 13:41:34 GMT
Server: Apache/2.2.3 (Linux/SUSE)
Vary: accept-language,accept-charset
Accept-Ranges: bytes
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
Content-Language: en
1e
<?xml version="1.0" encoding="
af
ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>Method not allowed!</title>
<link rev="made" href="mailto:"[email protected]" />
<style type="text/css"><!--/--><![CDATA[/*><!--/
body { color: #000000; background-color: #FFFFFF; }
a:link { color: #0000CC; }
p, address {margin-left: 3em;}
span {font-size: smaller;}
/]]>/--></style>
</head>
<body>
Method not allowed!
The
PROPFIND
method is not allowed for the requested URL.
If you think this is a server error, please contact
the webmaster.
If anyone has a solution?
Message was edited by: HansH8