[SOLVED] Evolution contacts webdav and Zimbra incompatible?

[gracedman]

Hello, all. We are having a nightmare of a time trying to find a Linux based front end to Zimbra other than ZWC (client does not want to use it as a front end). Both Kontact and Evolution seem to have either show stopping bugs or incompatibilities.

The big problem with Evolution was contacts. With their new webdav address book support, we thought we'd take another look. Once we got past the malformed DNS query (it asks for mycompany.com@zimbra.mycompany.com instead of simply zimbra.mycompany.com) by making explicit hosts entries, we encountered this error:


libebookbackendgoogle-Message: 'http://user@domain.com%40zimbra01.domain.com/dav/user@domain.com/Contacts/62DF2A0A-1FC19443-53B442AF.vcf' doesn't have mime-type text/x-vcard but 'text/directory; charset=utf-8'

This does not seem to be an Evolution bug but rather an incompatibility with Zimbra. How do we get Zimbra to give the contacts in the requested format?

Here is the documentation from the Evolution webdav contacts site:
* The webdav server has to support ETags and If-Match headers. ETags are only optional in the webdav standard but should be supported by nearly all servers implementations out there. Older apache versions (pre 2.2.8) have buggy If-Match handling, so you might have to enable the workaround for that in the settings.
* The webdav server has to know the x-vcard mimetype. (This is a little strict and is planned to be improved in a future version). You might have to add the following line to /etc/mime.types (on your server):

text/x-vcard vcf

Thanks - John

[gracedman]

We are getting closer. After looking at the REST documentation, we realized we could use a URI like:
http://zimbra.mycompany.com/dav/user...tacts/?fmt=vcf

This returns individual vcards of mime-type text/vcard. Is there any way to format the returned cards as text/x-vcard? Is there any additional option we can pass to the query? This problem really has us dead in the water. Both Kontact and Evolution and seriously broken when it comes to interoperating with Zimbra. This is the closest we've gotten to a working solution. Thanks - John

[jrdnyquist]

I'm in the same boat. I will keep watching in hopes of a solution.

[gracedman]

There is a patch available for evolution as the code rejects any vcards of type other than text/x-vcard. The patch is at https://bugzilla.gnome.org/show_bug.cgi?id=566330

However, I am having grief rebuilding the package (doesn't look like anything to do with the patch):

checking for GNOME_PLATFORM... configure: error: Package requirements
(glib-2.0 >= 2.16.1
gtk+-2.0 >= 2.14.0
ORBit-2.0 >= 2.9.8
libbonobo-2.0 >= 2.20.3
gconf-2.0 >= 2.0.0
libglade-2.0 >= 2.0.0
libxml-2.0 >= 2.0.0
libsoup-2.4 >= 2.3.0) were not met:

Package zlib was not found in the pkg-config search path.
Perhaps you should add the directory containing `zlib.pc'
to the PKG_CONFIG_PATH environment variable
Package 'zlib', required by 'GnuTLS', not found

zlib is installed. I did not check all the listed packages but the ones
I checked were installed with the latest versions. Any hints on how to fix this? We're rather desperate to get this going. Thanks - John

[gracedman]

We're almost there. We needed to use the zlib1g-dev package from Debian testing rather than Debian stable. Once that was installed, it compiled fine.

We needed to use a URI of the form:

http://zimbra.mydomain.com/dav/user@...tacts/?fmt=vcf

However, although we see the contacts now and can use them in our emails including auto-complete, we cannot save new contacts. Evolution returns an unhelpful "other error" message. The debug from the evolution-data-server says:

libebookbackendgoogle-WARNING **: create resource 'http://user@mydomain.com@zimbra.mydomain.com/dav/user@mydomain.com/Contacts/?fmt=vcf/298DA791-26023D54-54B99BB3.vcf' failed with http status: 406

Any reason why we are getting this code and how to enable write access?

Thanks - John

[gracedman]

This write access problem has been picked up in thread:
WebDAV Contacts - Gnome Evolution

[uxbod]

Closing this for the more complete thread.