SOGo: Importing contacts from server fails (Received vCard without data, ignoring)


  • In the DAVx log I can see that all contacts are sent, but no contacts are imported to android.

    Sogo version: 5.1.0
    DAVx version: 3.3.12

    Here is an example from the log:

    2021-08-22 16:44:15 439 [HttpClient] <?xml version="1.0" encoding="utf-8"?>
    <D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:carddav"><D:response><D:href>/SOGo/dav/artur/Contacts/personal/ef2474ac-eddd-4447-b287-8ddfb4d1b9b7.vcf</D:href><D:propstat><D:prop><C:address-data>&#65279;BEGIN:VCARD
    VERSION:3.0
    PRODID:+//IDN bitfire.at//DAVx5/2.4.0.1-ose ez-vcard/0.10.5
    UID:ef2474ac-eddd-4447-b287-8ddfb4d1b9b7
    FN:M K
    N:K;M
    ORG:slt
    TEL;TYPE=cell:+49 12345
    REV:2019-05-17T09:21:34Z
    END:VCARD</C:address-data><D:getetag>&#65279;&quot;gcs00000000&quot;</D:getetag><D:getcontenttype>&#65279;text/x-vcard</D:getcontenttype></D:prop><D:status>HTTP/1.1 200 OK</D:status></D:propstat></D:response></D:multistatus>
    2021-08-22 16:44:15 439 [syncadapter.ContactsSyncManager] Processing CardDAV resource ef2474ac-eddd-4447-b287-8ddfb4d1b9b7.vcf
    2021-08-22 16:44:15 440 [syncadapter.ContactsSyncManager] Received vCard without data, ignoring
    

    The log is full with entries: [syncadapter.ContactsSyncManager] Received vCard without data, ignoring

    debug-info.txt

  • developer

    @arwie Hi,

    Is that reproducible with a new address book? How are the addresses created? How can I reproduce the problem?


  • @rfc2822 Just tested with a new address book with the same result.

    Also just checked:
    New contacts created on Android are synced to the server, but not from Server to Android.

    Why does DAVx write in the log that received vCards are without data, while they are obviously not?

  • developer

    @arwie said in SOGo: Importing contacts from server fails (Received vCard without data, ignoring):

    @rfc2822 Just tested with a new address book with the same result.

    Also just checked:
    New contacts created on Android are synced to the server, but not from Server to Android.

    Why does DAVx write in the log that received vCards are without data, while they are obviously not?

    I don’t know; I have to reproduce the problem first. There was never a problem with SOGo, but I’ll have a look.

  • developer

    I wonder what the entity 65279 at the beginning of the vCard is:

    BEGIN:VCARD

    Looks like a BOM and it seems like it would prevent ez-vcard from parsing the vCard.

  • developer

    @arwie Do you know why (and since when) SOGo inserts a BOM at the beginning? I have never seen this and I think it’s breaking the vCard.


  • @rfc2822 I don’t know why they are doing it. My installation is several years old, I’m updating it regularly, but just now I noticed this problem.

    It must have happened between v5.0.0 and v5.1.0


  • @rfc2822 I see this problem with DAVx 3.3.12 and SOGo 5.1.0

    New events created on Android are synced to the server, but the same events edited (on Android) are not synced (changes are reverted)

    I recently updated SOGo from 5.0.0 to 5.1.0

    2021-08-22 18:46:08 663 [syncadapter.CalendarSyncManager] Preparing upload of event a2d8b8d6-fee6-4642-9a46-d71156fe9697.ics
    	PARAMETER #0 = Event=[alarms=[], attendees=[], categories=[], classification=CLASS:PUBLIC, color=null, description=null, dtEnd=DTEND;VALUE=DATE:20210826, dtStart=DTSTART;VALUE=DATE:20210814, duration=null, exDates=[], exRules=[], exceptions=[], lastModified=null, location=null, opaque=true, organizer=null, rDates=[], rRules=[], recurrenceId=null, status=STATUS:CONFIRMED, summary=Urlaub, unknownProperties=[], url=null, userAgents=[org.withouthat.acalendarplus], sequence=4, uid=a2d8b8d6-fee6-4642-9a46-d71156fe9697]
    2021-08-22 18:46:08 654 [syncadapter.SyncManager] Preparing synchronization
    2021-08-22 18:46:08 654 [syncadapter.SyncManager] Querying server capabilities
    2021-08-22 18:46:08 654 [HttpClient] --> PROPFIND http://localhost/SOGo/dav/familie/Calendar/3CF9-538DD700-1-7F405B80/
    2021-08-22 18:46:08 654 [HttpClient] Content-Type: application/xml; charset=utf-8
    2021-08-22 18:46:08 654 [HttpClient] Content-Length: 241
    2021-08-22 18:46:08 654 [HttpClient] Depth: 0
    2021-08-22 18:46:08 654 [HttpClient] Accept-Encoding: br,gzip
    2021-08-22 18:46:08 654 [HttpClient] 
    2021-08-22 18:46:08 654 [HttpClient] <?xml version='1.0' encoding='UTF-8' ?><propfind xmlns="DAV:" xmlns:CAL="urn:ietf:params:xml:ns:caldav" xmlns:CARD="urn:ietf:params:xml:ns:carddav"><prop><n0:getctag xmlns:n0="http://calendarserver.org/ns/" /><sync-token /></prop></propfind>
    2021-08-22 18:46:08 654 [HttpClient] --> END PROPFIND (241-byte body)
    2021-08-22 18:46:08 654 [at.bitfire.dav4jvm.BasicDigestAuthHandler] Adding Basic authorization header for http://localhost/SOGo/dav/familie/Calendar/3CF9-538DD700-1-7F405B80/
    2021-08-22 18:46:08 663 [HttpClient] --> PUT http://localhost/SOGo/dav/artur/Calendar/personal/a2d8b8d6-fee6-4642-9a46-d71156fe9697.ics
    2021-08-22 18:46:08 663 [HttpClient] Content-Type: text/calendar;charset=utf-8
    2021-08-22 18:46:08 663 [HttpClient] Content-Length: 325
    2021-08-22 18:46:08 663 [HttpClient] If-Match: "\"gcs00000003\""
    2021-08-22 18:46:08 663 [HttpClient] Accept-Encoding: br,gzip
    2021-08-22 18:46:08 663 [HttpClient] 
    2021-08-22 18:46:08 663 [HttpClient] BEGIN:VCALENDAR
    VERSION:2.0
    PRODID:DAVx5/3.3.12-ose ical4j/3.0.28 (org.withouthat.acalendarplus)
    BEGIN:VEVENT
    DTSTAMP:20210822T164608Z
    UID:a2d8b8d6-fee6-4642-9a46-d71156fe9697
    SEQUENCE:4
    SUMMARY:Urlaub
    DTSTART;VALUE=DATE:20210814
    DTEND;VALUE=DATE:20210826
    CLASS:PUBLIC
    STATUS:CONFIRMED
    END:VEVENT
    END:VCALENDAR
    
    2021-08-22 18:46:08 663 [HttpClient] --> END PUT (325-byte body)
    2021-08-22 18:46:08 654 [HttpClient] <-- 207 Multi-Status http://localhost/SOGo/dav/familie/Calendar/3CF9-538DD700-1-7F405B80/ (22ms)
    2021-08-22 18:46:08 663 [at.bitfire.dav4jvm.BasicDigestAuthHandler] Adding Basic authorization header for http://localhost/SOGo/dav/artur/Calendar/personal/a2d8b8d6-fee6-4642-9a46-d71156fe9697.ics
    2021-08-22 18:46:08 654 [HttpClient] Date: Sun, 22 Aug 2021 16:46:08 GMT
    2021-08-22 18:46:08 654 [HttpClient] Server: SOPE 4.9.37/WebDAV
    2021-08-22 18:46:08 654 [HttpClient] Content-Type: text/xml; charset="utf-8"
    2021-08-22 18:46:08 654 [HttpClient] X-Dav-Error: 200 No error
    2021-08-22 18:46:08 654 [HttpClient] Ms-Author-Via: DAV
    2021-08-22 18:46:08 654 [HttpClient] Pragma: no-cache
    2021-08-22 18:46:08 654 [HttpClient] Content-Length: 369
    2021-08-22 18:46:08 654 [HttpClient] Cache-Control: no-cache
    2021-08-22 18:46:08 654 [HttpClient] Keep-Alive: timeout=5, max=91
    2021-08-22 18:46:08 654 [HttpClient] Connection: Keep-Alive
    2021-08-22 18:46:08 663 [HttpClient] <-- 412 Precondition Failed http://localhost/SOGo/dav/artur/Calendar/personal/a2d8b8d6-fee6-4642-9a46-d71156fe9697.ics (13ms)
    2021-08-22 18:46:08 654 [HttpClient] 
    2021-08-22 18:46:08 663 [HttpClient] Date: Sun, 22 Aug 2021 16:46:08 GMT
    2021-08-22 18:46:08 654 [HttpClient] <?xml version="1.0" encoding="utf-8"?>
    <D:multistatus xmlns:D="DAV:" xmlns:a="http://calendarserver.org/ns/"><D:response><D:href>/SOGo/dav/familie/Calendar/3CF9-538DD700-1-7F405B80/</D:href><D:propstat><D:status>HTTP/1.1 200 OK</D:status><D:prop><a:getctag>1623343442</a:getctag><D:sync-token>1623343442</D:sync-token></D:prop></D:propstat></D:response></D:multistatus>
    2021-08-22 18:46:08 663 [HttpClient] Server: Apache/2.4.48 (Unix) PHP/8.0.9 Phusion_Passenger/6.0.10
    2021-08-22 18:46:08 654 [HttpClient] <-- END HTTP (369-byte body)
    2021-08-22 18:46:08 663 [HttpClient] Content-Length: 187
    2021-08-22 18:46:08 663 [HttpClient] Content-Type: text/html; charset="iso-8859-1"
    2021-08-22 18:46:08 654 [syncadapter.SyncManager] Sending local deletes/updates to server
    2021-08-22 18:46:08 663 [HttpClient] Keep-Alive: timeout=5, max=94
    2021-08-22 18:46:08 663 [HttpClient] Connection: Keep-Alive
    2021-08-22 18:46:08 663 [HttpClient] 
    2021-08-22 18:46:08 663 [HttpClient] <?xml version="1.0" encoding="ISO-8859-1"?>
    <html xmlns="http://www.w3.org/1999/xhtml">
    <body><h3>An error occurred during object publishing</h3><p>Precondition Failed</p></body>
    </html>
    
    2021-08-22 18:46:08 663 [HttpClient] <-- END HTTP (187-byte body)
    2021-08-22 18:46:08 654 [syncadapter.SyncManager] Removed 0 record(s) from server
    2021-08-22 18:46:08 663 [syncadapter.SyncManager] Resource has been modified on the server before upload, ignoring
    2021-08-22 18:46:08 663 [syncadapter.SyncManager] Didn't receive new ETag after uploading, setting to null
    2021-08-22 18:46:08 654 [syncadapter.SyncManager] Sent 0 record(s) to server
    2021-08-22 18:46:08 654 [syncadapter.SyncManager] Local sync state = {"type":"SYNC_TOKEN","value":"1623343442"}, remote sync state = {"type":"SYNC_TOKEN","value":"1623343442"}
    2021-08-22 18:46:08 654 [syncadapter.SyncManager] Remote collection didn't change, no reason to sync
    2021-08-22 18:46:08 654 [syncadapter.TasksSyncAdapterService] Task sync complete
    2021-08-22 18:46:08 654 [syncadapter.SyncAdapterService] Sync for (org.dmfs.tasks, Account {name=artur@cloud.local, type=bitfire.at.davdroid}) finished
    	PARAMETER #0 = SyncResult: stats []
    
  • developer

    @arwie This looks like a server problem to me. Can you please contact SOGo about this?

  • developer

    @arwie Did you modify the contacts on the server between the synchronizations? If not, can you please provide steps to reproduce?

    The server reports that the contacts have been edited on the server in the meanwhile. This is a conflict and DAVx5’s strategy is “server always wins”, so it will download the current contact from the server.


  • @rfc2822 No I did not modify the event on the server (this is a calendar issue)

    Steps to reproduce:

    1. Create a new event on Android
    2. Sync -> Event appears on SOGo
    3. Modify same event on Android
    4. Sync -> Event is reset on Android
  • developer

    @arwie Sounds strange. Which SOGo version? Maybe there’s something wrong with your SOGo installation, because of all the sudden problems?


  • @rfc2822 If I directly download the vcf file with Firefox I don’t see any BOM in the beginning:

    GET http://cloud/SOGo/dav/artur/Contacts/personal/ef2474ac-eddd-4447-b287-8ddfb4d1b9b7.vcf

    [client@tuxedo Downloads]$ hexdump -C ef2474ac-eddd-4447-b287-8ddfb4d1b9b7.vcf 
    00000000  42 45 47 49 4e 3a 56 43  41 52 44 0d 0a 56 45 52  |BEGIN:VCARD..VER|
    00000010  53 49 4f 4e 3a 33 2e 30  0d 0a 50 52 4f 44 49 44  |SION:3.0..PRODID|
    00000020  3a 2b 2f 2f 49 44 4e 20  62 69 74 66 69 72 65 2e  |:+//IDN bitfire.|
    00000030  61 74 2f 2f 44 41 56 78  35 2f 32 2e 34 2e 30 2e  |at//DAVx5/2.4.0.|
    00000040  31 2d 6f 73 65 20 65 7a  2d 76 63 61 72 64 2f 30  |1-ose ez-vcard/0|
    00000050  2e 31 30 2e 35 0d 0a 55  49 44 3a 65 66 32 34 37  |.10.5..UID:ef247|
    00000060  34 61 63 2d 65 64 64 64  2d 34 34 34 37 2d 62 32  |4ac-eddd-4447-b2|
    00000070  38 37 2d 38 64 64 66 62  34 64 31 62 39 62 37 0d  |87-8ddfb4d1b9b7.|
    
    
  • developer

    @arwie DAVx5 uses REPORT addressbook-multiget. Maybe the problem only occurs when using the REPORT.

  • developer

    @rfc2822 The getetag and getcontenttype fields also have aBOM that shouldn’t be there. Looks like there is a general server-side problem with the multiget response.


  • @rfc2822 As I looked around it seems that BOM is part of XML. Shouldn’t your XML parsing library handle it?

  • developer

    @arwie No, according to the standard, there shouldn’t be byte-order-marks. Also, no other server sends them. It’s for UTF-16 text files, not to insert it to the beginning of every single UTF-8 XML field.

    Please contact your server support about this.

  • developer

    I have merged the two topics because they have the same root cause (BOMs inserted everywhere). This is about the events problem:

    This is most probably because your server modifies the ETags by inserting a byte-order-mark every time. So ETags are not equal (sometimes with, sometimes without BOM) when they should be equal, so clients will think the contents have changed and re-download the items every time.


  • @rfc2822 I am the server support 🙂

    My server is an arch linux machine. A week ago I updated everything and now encounter this problem.

    I tried to downgrade sogo and sope to working versions (from 1 year ago) but the problem remained.

    Sogo/Sope use libxml2/libwbxml/libexpat for xml handling. I guess an updated version of one of these cause the problem. (They have a lot of BOM handling code…)

  • developer

    @arwie I see… maybe there are SOGo forums where you can get some ideas. Unfortunately I’m not experienced with SOGo internals.

Similar topics