No contacts found

[kermit-the-frog]

Hi,

I have a problem with carddav and SabreDav 3.2.2. Carddav discovers all my addressbooks but does not retrieve any of the contacts in the addressbooks. I've enabled DEBUG and DEBUG_HTTP and here are my logs.

This is a brand new installation of Roundcube 1.2.4 and latest carddav. Everything is ok with my old installation of Roundcube 1.1 and carddav 1.0.

Kind regards, kermit-the-frog carddav.txt

[kermit-the-frog]

I've been looking at the wrong part of the logs. The important parts are:

[17-Mar-2017 22:56:08 +0100]: <dcda5c99> BACKEND: (cdfopen) list_records_propfind requesting https://mydomain.com:443/path_to_sabredav/addressbooks/user_name/work/ [RL 5]
[17-Mar-2017 22:56:09 +0100]: <dcda5c99> BACKEND: (cdfopen) Code: 207
[17-Mar-2017 22:56:09 +0100]: <dcda5c99> BACKEND: (cdfopen) success: array (
  'status' => 207,
  'headers' =>
  Httpful\Response\Headers::__set_state(array(
     'headers' =>
    array (
      'content-type' => 'application/xml; charset=utf-8',
      'transfer-encoding' => 'chunked',
      'connection' => 'keep-alive',
      'keep-alive' => 'timeout=15',
      'date' => 'Fri, 17 Mar 2017 21:56:08 GMT',
      'server' => 'Apache',
      'x-powered-by' => 'PHP/5.6.30',
      'x-sabre-version' => '3.2.2',
      'vary' => 'Brief,Prefer',
      'dav' => '1, 3, extended-mkcol, access-control, calendarserver-principal-property-search, calendar-access, calendar-proxy, calendarserver-subscribed, calendar-auto-schedule, calendar-availability, resource-sharing, calendarserver-sharing, addressbook',
    ),
  )),
  'body' => '<?xml version="1.0"?>
<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:cal="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/" xmlns:card="urn:ietf:params:xml:ns:carddav"><d:response><d:href>/path_to_sabredav/addressbooks/user_name/work/</d:href><d:propstat><d:prop><d:getcontenttype/><d:getetag/></d:prop><d:status>HTTP/1.1 404 Not Found</d:status></d:propstat></d:response><d:response><d:href>/path_to_sabredav/addressbooks/user_name/work/bbfe9394-289c-496d-8d5b-7128da6fc639.vcf</d:href><d:propstat><d:prop><d:getcontenttype>text/vcard; charset=utf-8</d:getcontenttype><d:getetag>&quot;ae4ba4de855579d645a2b66d97b84ce8&quot;</d:getetag></d:prop><d:status>HTTP/1.1 200 OK</d:status></d:propstat></d:response></d:multistatus>',
)
[17-Mar-2017 22:56:09 +0100]: <dcda5c99> BACKEND: (cdfopen) query_addressbook_multiget requesting https://mydomain.com:443/path_to_sabredav/addressbooks/user_name/work/ [RL 5]
[17-Mar-2017 22:56:09 +0100]: <dcda5c99> BACKEND: (cdfopen) Code: 500
[17-Mar-2017 22:56:09 +0100]: <dcda5c99> BACKEND: (cdfopen) success: array (
  'status' => 500,
  'headers' =>
  Httpful\Response\Headers::__set_state(array(
     'headers' =>
    array (
      'content-type' => 'application/xml; charset=utf-8',
      'transfer-encoding' => 'chunked',
      'connection' => 'keep-alive',
      'keep-alive' => 'timeout=15',
      'date' => 'Fri, 17 Mar 2017 21:56:09 GMT',
      'server' => 'Apache',
      'x-powered-by' => 'PHP/5.6.30',
      'x-sabre-version' => '3.2.2',
    ),
  )),
  'body' => '<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:sabredav-version>3.2.2</s:sabredav-version>
  <s:exception>ErrorException</s:exception>
  <s:message>Undefined index: name</s:message>
</d:error>
',
)
[17-Mar-2017 22:56:09 +0100]: <dcda5c99> BACKEND: (delete_unseen) deleted 0 contacts during server refresh
[17-Mar-2017 22:56:09 +0100]: <dcda5c99> BACKEND: (delete_unseen) deleted 0 groups during server refresh
[17-Mar-2017 22:56:09 +0100]: <dcda5c99> BACKEND: (refreshdb_from_server) server refresh took 1 seconds

As you can see an error 500 occurs when carddav tries to receive the VCARD.

By logging the requests in public function cdfopen($url, $http_opts, $carddav) and comparing them with successful requests of another carddav client (https://www.inf-it.com/open-source/clients/infcloud/), I discovered a bug in my Carddav-Server (https://github.com/fruux/sabre-dav/issues/952).

But there is still a bug within carddav: the sync token is stored in the database even though the error 500 has occured. So carddav never retries to receive the VCARD.

Kind regards, kermit-the-frog

[bernhy]

Hi Kermit,

have you already been able to solve this issue somehow? I run into the same currently, using SabreDAV 3.2.2, Roundcube 1.2.3 and current master of rcmcarddav. Retrieval of addressbook looks like this..

"PROPFIND /addressbooks/user/default/ HTTP/1.1" 401 536 "-" "RCM CardDAV plugin/2.0.4" "PROPFIND /addressbooks/user/default/ HTTP/1.1" 207 1036 "-" "RCM CardDAV plugin/2.0.4" "REPORT /addressbooks/user/default/ HTTP/1.1" 500 275 "-" "RCM CardDAV plugin/2.0.4" "PROPFIND /addressbooks/user/default/ HTTP/1.1" 401 536 "-" "RCM CardDAV plugin/2.0.4" "PROPFIND /addressbooks/user/default/ HTTP/1.1" 207 16581 "-" "RCM CardDAV plugin/2.0.4" "REPORT /addressbooks/user/default/ HTTP/1.1" 500 275 "-" "RCM CardDAV plugin/2.0.4"

Btw., 'list_records_propfind works' here, only 'query_addressbook_multiget' fails with rc 500. Is there any solution to get this working?

[jorgelzpz]

I believe this is caused by this issue: fruux/sabre-dav#932

[blind-coder]

This is weird, because if the REPORT method fails, it should use PROPFIND, which according to the log works (reply status 207). Could you give me an account on the Sabre/DAV server so I can try from this side?

[kermit-the-frog]

Fallback to PROPFIND fails because query_addressbook_multiget fails because of fruux/sabre-dav#952. You can fix it by changing lines 419 to 421 carddav_backend.php from

    <C:address-data>
        <C:allprop/>
    </C:address-data>

to

    <C:address-data/>

[blind-coder]

Does that have any negative effect? How does the output of a working connection differ between a query with and without allprop?

[kermit-the-frog]

Does that have any negative effect? How does the output of a working connection differ between a query with and without allprop?

I don't know. Sabredav does not work with allprop. Though someone should test with another carddav server.

[bernhy]

You can fix it by changing lines 419 to 421 carddav_backend.php from

Well, I already tried this, but doesnt help ..

[blind-coder]

I have been able to reproduce this, but unable to find a quick fix. I will look into this when I have more time.

[janmuennich]

The fix by kermit-the-frog did not work for me with SabreDAV 3.2.2. Only downgrading to SabreDAV 3.2.0 fixed the issue.

[Globulino]

I can confirm, that the fix by kermit-the-frog does work with SabreDAV 3.2.2. But before I additionally had to set in SabreDAV $aclPlugin->allowUnauthenticatedAccess = false; Only both settings get rid of the REPORT 500 errors.

[bernhy]

I can confirm that comment from Globulino did the trick, now its working. Only some php 7 warnings are left, but its not related to this issue.

[e-dschungel]

I confirm that both changes by @Globulino and @kermit-the-frog make carddav work together with vanilla sabreDAV 3.2.2.

[Offerel]

I have made the same changes in RCMCardDAV v3.0.3 and can confirm working to. Works with vanilla SabreDAV 3.2.2, SabreDAV 3.2.2 patched and OpenXChange DAV Server. Maybe this could be implemented for the next release v3.0.4.

[mstilkerich]

The current v4 branch will fall back to Propfind based sync and individual GET requests when the reports fail. It's slower, but works. This is about as much as I can do from the plugin side short of using an HTTP client that is not curl based (most are). The allprop element is also removed.

[mstilkerich]

carddavclient 1.0.0 now includes a workaround to enable usage of the fast sync methods with sabre dav.