Couldn't parse Multi-Status response on REPORT multi-get



  • I get following error:

    at.bitfire.davdroid.webdav.DavException: Invalid DAV response: Couldn't parse Multi-Status response on REPORT multi-get at at.bitfire.davdroid.webdav.WebDavResource.processMultiStatus(WebDavResource.java:380)...

    davdroid was just syncing fine before, but now I receive the error message. I already removed and added the account again. Doesn't resolve the issue.

    On my radicale server I see that the last sync was today in the morning and all my last added entries are in the contacts.vcf file. (Permissions and everything else is equal to the calendar file, where the sync is working fine.)

    I haven't found a solution to this issue. Any idea?



  • I just tried to create a backup and then use a vcf with only one random contact on the server. Then it syncs fine again.

    It seems that the error is in one of the contacts, right? Wired thing about it is that only davdroid uses the vcf and I haven't touched the vcf on the server (at least before today but now I am searching for the error).

    Removing the last two VCARDs where I made changes didn't help neither... Uff how do I find the error now in a file with around 200 contacts???



  • I just tried to create an empty vcf on the server and import the backup vcf on the phone with the People app (com.android.contacts). The import was successful, and then the first sync with the server is successful as well. So the vcf on the server (which was empty before the sync) has again the same size as the original vcf.

    But with the next sync the issue is there again:

    at.bitfire.davdroid.webdav.DavException: Invalid DAV response: Couldn't parse Multi-Status response on REPORT multi-get at at.bitfire.davdroid.webdav.WebDavResource.processMultiStatus(WebDavResource.java:380)...
    

  • developer

    It seems like the Radicale server has a problem with one of the contacts or its storage (thus the server error on REPORT). Is there any reason why you think this is related to DAVdroid?



  • To tell you the truth, I am not sure what the error means... And in the radicale debug I haven't seen an error. So I thought it is DAVdroid related.
    The radicale log seems okay!?
    https://gist.github.com/qfvldaa2xn/3250b133921c0bef1825

    I just played around again:

    1. It works with an empty vcf or just a random test contact VCARD.
    2. I found a an old vcf from in a backup that I made 10 days ago, and 10 days ago it was working like a charm without any problems (I can even see that in the REV: entries from new contacts that I created on the phone).

    In the first test it works just fine without any problems, and in the second it has the same error as above (even-though it was working with exactly that vcf a couple of days ago).

    I even removed radicale (pacman -Rs radicale) and installed it again. The problem persists.

    The radicale daemon status is:

    Aug 26 17:56:51 arch radicale[5083]: PROPFIND request at /radicale/Daniel/calendar.ics/ received
    Aug 26 17:56:51 arch radicale[5083]: REPORT request at /radicale/Daniel/calendar.ics/ received
    Aug 26 17:56:53 arch radicale[5083]: PROPFIND request at /radicale/Daniel/contacts.vcf/ received
    Aug 26 17:56:53 arch radicale[5083]: PROPFIND request at /radicale/Daniel/contacts.vcf/ received
    Aug 26 17:57:01 arch radicale[5083]: PROPFIND request at /radicale/Daniel/calendar.ics/ received
    Aug 26 17:57:01 arch radicale[5083]: REPORT request at /radicale/Daniel/calendar.ics/ received
    
    1. PROPFIND and REPORT for the calendar.
    2. PROPFIND and PROPFIND (????) for the contacts.
    3. PROPFIND and REPORT for the tasks in the calendar.ics.


  • I was able to reproduce the error (finally...). When I receive a message from an unknown number in whatsapp and then I click in whatsapp on "Add to contacts" and then I choose to synchronize it with DAVdroid then I get the error described above.

    When I remove the newly created contact, then it works like a charm again.

    Is this a DAVdroid error?


  • developer

    @qfvldaa2xn I don't know. Unfortunately, I don't have/use WhatsApp, so I can't test that…

    Maybe the contact doesn't have a name and the server rejects the contact, but with no response (instead of sending an HTTP error)?

    What server do you use? Please see What's required to diagnose a problem and provide the required information, especially the logs.



  • Now I realized that it not only happens with contacts created in WhatsApp (I only thought so as I was able to reproduce it with new WhatsApp contacts, but now I also have it with a contact outside of WhatsApp).

    Steps:

    1. I add a new contact, use the field name and the cel number.
    2. I sync DAVdroid contacts with my radicale server.
    3. I get the error message.
    4. I check on the server and the contact was indeed added to the contacts.vcf (even though I receive an error).

    The entry looks quite normal I would say:

    BEGIN:VCARD
    VERSION:3.0
    UID:[REMOVED]
    FN:FIRST LAST
    N:LAST;FIRST;;;
    TEL;TYPE=cell:+[REMOVED]
    PRODID:DAVdroid/0.8.4.1 (ez-vcard/0.9.6)
    REV:20150930T203151Z
    X-RADICALE-NAME:[REMOVED].vcf
    END:VCARD

    Here the log:
    https://gist.github.com/qfvldaa2xn/7059881df857b6d54af6

    Phone: DAVdroid 0.8.4.1
    Server: nginx 1.8.0-1 and radicale 0.10-1.
    With Evolution 3.16.5-1 I can use it without any problems.


  • developer

    Thanks for the logs. As you can see, nginx responds to the PROPFIND request that should list all contacts in the address book with this header:

    […]
    Content-Length: 65676[\r][\n]
    […]
    

    I didn't count the bytes of the response body, but the Apache HTTP client library which is used by DAVdroid thinks that only 16171 bytes have been received, although it should be 65676 as announced:

    Caused by: org.apache.http.ConnectionClosedException: Premature end of Content-Length delimited message body (expected: 65676; received: 16171)
    at org.apache.http.impl.io.ContentLengthInputStreamHC4.read(ContentLengthInputStreamHC4.java:180)
    

    So it thinks the response has been cut off and is thus incomplete and not valid, and it throws an exception, which is correctly interpreted as invalid DAV response by DAVdroid.

    DAVdroid disables compression when you take logs, so HTTP compression is not a possible explanation (the logs wouldn't be readable when compression is active).

    So first we'd have to find out how large the response really is (16171 or 65676 bytes), then we know where the problem is: either on server side or in the Apache HTTP client library.



  • Thank you for your quick response!

    @rfc2822 said:

    So first we'd have to find out how large the response really is

    How do I do that? :confused:


  • developer

    @qfvldaa2xn Don't have an idea except counting the bytes of the response from the logs ;)

    I have copied the response body including the "D/Wire (13314): http-outgoing-5" to a separate file, and it has a size of 43137 bytes. So, 65676 can't be right in any case. I guess the size will be 16171 bytes when you'd remove the meta artefacts from the logs.

    So I think that:

    • either nginx sends the wrong size (for whatever reason), and/or
    • the response body has been truncated indeed (network problems, firewall, …).


  • @rfc2822 said:

    • either nginx sends the wrong size (for whatever reason), and/or
    • the response body has been truncated indeed (network problems, firewall, …).

    But Evolution doesn't seem to have a problem. Here the log from the evolution debug:
    https://gist.github.com/qfvldaa2xn/a99507088a78bc4e9cfa

    edit: I just tried CardDAV-Sync on my phone and it also works without a problem. Is there another way to see how large the response really is?


  • developer

    Is there another way to see how large the response really is?

    According to the DAVdroid logs, there's no doubt that the received response is shorter than 65676 octets. To see what has been sent by your server, you may use nginx $bytes_sent log variable. What does the nginx log say for the questionable request/response?

    Is there a reason to doubt the ConnectionClosedException (premature end of Content-Length delimited message body) error message? You may capture the network connection with a tool like Wireshark and see how large the response is and whether the size matches the value of Content-Length.


Log in to reply
 

Looks like your connection to Bitfire App Forums was lost, please wait while we try to reconnect.