MacOS (CardDav) to MDaemon (25.5 & 26) not work... | MDaemon Technologies Community Forum
  1. Forum
  2. MDaemon
  3. MacOS (CardDav) to MDaemon (25.5 & 26) not working, due to protocol bug

MacOS (CardDav) to MDaemon (25.5 & 26) not working, due to protocol bug

  • R

    I’m trying to sync Apple Contacts on macOS with an MDaemon 25.5.0 (and higher, all tested!) CardDAV account.

    Account setup succeeds and macOS accepts the account. In the macOS CardDAV logs I see:

    syncUseSyncReport:1
syncMaxMultiGetBatch:50
syncMaxRequestsPerAddressBook:5
Preparing to sync 1 containers
_handleAddsOrModifies:(0 items) removes:(0 items)
SYNCHRONIZATION ... Error (null)

    So macOS performs a real sync, but ends with 0 items.

    I tested the CardDAV collection manually with curl. A normal CardDAV addressbook-query works and returns all vCards correctly:

    REPORT /webdav/addressbook/
<card:addressbook-query ...>
→ HTTP/1.1 207 Multi-Status
→ many BEGIN:VCARD entries

    However, Apple MacOS appears to use DAV sync-collection. When I test that manually:

    REPORT /webdav/addressbook/
<D:sync-collection xmlns:D="DAV:">
  <D:sync-token/>
  <D:sync-level>1</D:sync-level>
  <D:prop><D:getetag/></D:prop>
</D:sync-collection>

    MDaemon returns:

    HTTP/1.1 400 Bad Request
<altn:webdav-version>25.5.0</altn:webdav-version>
<altn:exception>ALTN\DAV\Exception\Bad Request</altn:exception>
<altn:message>Your browser sent a request that this server could not understand.</altn:message>

    So it looks like:
    - CardDAV itself works  (iPhone is working and other client apps too)
    - vCards are present  (when checking with Curl and other client apps)
    - addressbook-query works
    - macOS uses sync-collection
    - MDaemon returns 400 on sync-collection
    - macOS then completes sync with 0 contacts and no visible error

    Is REPORT sync-collection supposed to be supported for CardDAV in MDaemon 25.5.0?

    Is there a setting to disable sync-report/sync-token support, or is this a known Apple Contacts compatibility issue?

    Tested with latest MacOS Tahoe 26.5

    0 likes
  • A

    Sync-collection is not supported.  What else does the log show is happening?  A client should fall back to a normal CardDAV addressbook-query, is macOS not doing that?

    Can you upload a full log that shows macOS attempting to sync the address book?

    What URL do you have configured in macOS to sync the address book?  If you create an Advanced account and point it directly at the addressbook.  For example:  https://mail.mydomain.com/webdav/principals/user@mydomain.com

    or 

    https://mail.mydomain.com/webdav/carddav/mydomain.com/user/

    Is macOS able to sync contacts?

    --
    Arron Caruth

    0 likes
  • R

    Hi Arron,

    Thanks for confirming that sync-collection is not supported.

    I tested this further and here are the exact facts I can reproduce.

    1. The CardDAV addressbook itself works

    This command returns HTTP 207 and many BEGIN:VCARD entries:

    curl -vk -u 'user@domain.tld' -X REPORT \
  -H 'Depth: 1' \
  -H 'Content-Type: application/xml; charset=utf-8' \
  --data '<?xml version="1.0"?><card:addressbook-query xmlns:D="DAV:" xmlns:card="urn:ietf:params:xml:ns:carddav"><D:prop><D:getetag/><card:address-data/></D:prop></card:addressbook-query>' \
  https://SERVER/webdav/addressbook/

    So the collection exists and contains contacts.

     

    2. A direct WebDAV sync-collection test fails

    This command returns HTTP 400 Bad Request on MDaemon 25.5 & 26

    curl -vk -u 'user@domain.tld' -X REPORT \
  -H 'Depth: 0' \
  -H 'Content-Type: application/xml; charset=utf-8' \
  --data '<?xml version="1.0"?><D:sync-collection xmlns:D="DAV:"><D:sync-token/><D:sync-level>1</D:sync-level><D:prop><D:getetag/></D:prop></D:sync-collection>' \
  https://SERVER/webdav/addressbook/

    The response is:

    HTTP/1.1 400 Bad Request
<altn:webdav-version>25.5.0</altn:webdav-version>
<altn:exception>ALTN\DAV\Exception\Bad Request</altn:exception>
<altn:message>Your browser sent a request that this server could not understand.</altn:message>

     

    3. macOS appears to use the sync-report path

    The Apple Contacts/CardDAV log shows:

    syncUseSyncReport:1
    Preparing to sync 1 containers
    Task ... sent request, body S 181
    Task ... received response, status 207
    _handleAddsOrModifies:(0 items) removes:(0 items)
    SYNCHRONIZATION ... Error (null)

    You can test that with this command:

    log stream --style compact --info \
  --predicate 'process == "AddressBookSourceSync" AND (subsystem CONTAINS "com.apple.contacts.carddav" OR subsystem CONTAINS "CFNetwork")'

    This is how I captured the Apple-side behavior. The exact request body is redacted by macOS, but the log clearly shows that Apple Contacts uses syncUseSyncReport:1 and then receives/imports 0 items.

    So macOS successfully discovers the account and one container, then runs a sync-report style sync. MDaemon returns HTTP 207, but Apple receives/imports 0 items.


    4. The classic URL and the principal url authenticates, the other not.
    - classic url: https://mail.mydomain.com/webdav/addressbook/  authenticates.
    - https://mail.mydomain.com/webdav/principals/user@mydomain.com authenticates.
    - https://mail.mydomain.com/webdav/carddav/mydomain.com/user/ does not even authenticate

    Discovery using the principal URL works

    Using the principal URL, macOS logs:

    principalPropertiesAtURL → HTTP 207
    containersAtURLs / home-set → HTTP 207
    Preparing to sync 1 containers

    So the /webdav/principals/... URL works for discovery and macOS finds one addressbook container. The failure happens later during the actual sync, where Apple logs:

    syncUseSyncReport:1
    _handleAddsOrModifies:(0 items) removes:(0 items)


    If you have a MacBook, MacMini, Studio or iMac at hand, please try to reproduce.

     

    Thanks in advance.

     

    0 likes
  • R

    @Arron I did just send a complete debugging/reproducable reply, but it said: Your message needs to be approved and now it's gone... can you approve it?

    0 likes
  • A

    Please enable debug logging for CalDAV & CardDAV by going to Setup | CalDAV & CardDAV in Remote Administration.  Set the Log level to Debug Logging.  Check the box to Enable HTTP request and response logging.  Then reproduce the issue.  Upload the content from the MDWebDAV folder along with the WebDAV-$DATE$.log file.

    Logging of the HTTP requests and responses will allow me to see all of the data that is sent between the client and the server, it should be used for debugging purposes only.  You should turn it off after you have reproduced the issue.

    You can upload all of the data to https://mdaemon.sharefile.com/r-rc3922c1eed334d4dbf5e34f0bd04ccd6

     

    --
    Arron Caruth

    0 likes
  • R

    I can't have it to log CardDAV for some reason. It does log other's users CalDAV requests, but no CardDAV for some reason.  And it's doing CardDAV for all iPhones.

    0 likes
  • A

    Do you have the log level set to debug?

    Do you have the logging of http requests and responses enabled?

    I'm looking at the logs from my test server and I'm seeing log entries for synching address books to an iPhone.  

    Verify the iPhones are actually synching.  I tried to do some testing using my iPhone and found that it was not actually connecting to the server.  I resolved it by updating to the latest version of iOS.

    If the webdav logging in MDaemon is configured correctly, you've verified the phones and mac are both actually connecting to the server, and you are still not seeing anything logged you can try using WireShark to capture the traffic on the MDaemon server.  On an active server it will capture all network traffic going to and from the server.  This could be a LOT of information very quickly.  

     

    --
    Arron Caruth

    0 likes
Please login to reply to this topic!

Participants