Radicale compatibility to Z-push ActiveSync

[vijaysar]

Hello Guillame and owners,

I have been trying to make Z-push work with Radicale backend for caldav and carddav. The Z-push-contrib client caldav libraries have trouble walking through the collections and finding calendar/contacts database to pull and specific elements to pull and make available over Activesync. Can you help resolve this by enabling support for the client library to work with Radicale? It seems like a godo use case for both Radicale and z-push activesync. Z-push currently works fine with Sabre and davical from my testing.

Issue: https://github.com/fmbiete/Z-Push-contrib/issues/268 Other related issues: https://github.com/fmbiete/Z-Push-contrib/issues/35 https://github.com/fmbiete/Z-Push-contrib/issues/34

Thanks

[liZe]

I'll look at this and see if the problem is easy to solve or not.

[polytan02]

That would be a really nice achievement making radicale and z-push work together.

[liZe]

@polytan02 @ericavijay Could you try the current master branch of Radicale? Many changes have been made during the last weeks, they probably solve this issue.

[liZe]

Feel free to reopen if you have something new about this.

[ghost]

This problem has to do with z-push code I have noticed that z-push is not able to detect the addressbook correctly. A piece of code in z_carddav.php looks select the addressbook as a vcard because of the line

text/vcard and It will not return a address book URL. I have change a piece off code in z-push and I will ask the developers of z-push if the they can maken the changes. I have got i working with radicale now.

[GloomyDay]

@Powercommy Can you post your changed piece of code?

[ghost]

I did not change that must only change the order a bit after that it works like a charm. Hope it helps you

z_carddav_snippet.txt

[rpc-scandinavia]

Thank you "ghost". Z-Push ActiveSync works well with Radicale CalDAV, but Radicale CardDAV do not work. I found this thread, describing a fix to the problem.

I modified the "/usr/local/lib/z-push/include/z_carddav.php" file around line 660. There he (ghost) swapped the first two IF conditions (with the respective content):

if (isset($response->propstat->prop->resourcetype->addressbook)) { // It's an addressbook

and

if ((strlen($this->url_vcard_extension) > 0 && preg_match('/'.$this->url_vcard_extension.'/', $response->href) && !(isset($response->propstat->prop->resourcetype) && isset($response->propstat->prop->resourcetype->addressbook))) || preg_match('/vcard/', $response->propstat->prop->getcontenttype) || isset($response->propstat->prop->{'address-data'}) || isset($response->propstat->prop->{'addressbook-data'})) { // It's a vcard

so the "addressbook" condition and code comes first and the "vcard" condition and code comes second.

With this modification, Z-Push ActiveSync works with Radicale CardDAV.

This problem has to do with z-push code I have noticed that z-push is not able to detect the addressbook correctly. A piece of code in z_carddav.php looks select the addressbook as a vcard because of the line text/vcard and It will not return a address book URL.

I have change a piece off code in z-push and I will ask the developers of z-push if the they can maken the changes. I have got i working with radicale now.

[matidau]

https://github.com/Z-Hub/Z-Push/issues/67#issuecomment-2292561908

I've tracked this down to the addressbook collection response xml->response->propstat->prop->resourcetype->addressbook has the contenttype set to text/vcard xml->response->propstat->prop->getcontenttype

Other DAV servers have this set to application/octet-stream.

This should probably be addressed in Radicale.

Are you open to fixing this in Radicale?

[pbiering]

Can you please lookup what is defined in RFC? Switching unconditionally the content-type can break other clients by accidents.

But to cover support, can you create a PR which is able to conditionally switch the content-type based on a global option (at least for testing) and user-agent?

[matidau]

Hi @pbiering,

I've looked through RFC 6352 CardDAV and can't find a specification for what the Content-Type is of an Address Book collection or a GET on an Address Book collection must or should return.

Looking at RFC 4918 section 9.4 and 15.5 it leaves it open that vcards can de returned

GET, when applied to a collection, may return the contents of an "index.html" resource, a human-readable view of the contents of the collection, or something else altogether.

Name: getcontenttype

Purpose: Contains the Content-Type header value (from Section 14.17 of [RFC2616]) as it would be returned by a GET without accept headers.

Based on this I will need to change Z-Push to allow for it. Also it is easier for me to change it in Z-Push as I'm more familiar with the code.

This issue is good to close again.