response to PROPFIND xmlhttprequest truncated

Cardbook for Thunderbird Forums Main Forum response to PROPFIND xmlhttprequest truncated

This topic contains 16 replies, has 2 voices, and was last updated by  CardBook 1 week, 3 days ago.

  • Author
    Posts
  • #1098

    mf
    Participant

    Using a Synology carddav server I managed to sync addressbooks on Android (DAVDroid) and Windows using Thunderbird and Cardbook. Great! I really appreciate your work!

    Unfortunately, I have problems with one addressbook that has more than 400 contacts. It syncs on Android but not with Cardbook. The individual contacts seem to be fine. I tried syncing different subsets of them, they all work up to 180 contacts. Adding any further contact however (as well as adding all 400+ contacts at once), causes subsequent syncs to fail with an XML error (no root node found).

    Debugging using the Thunderbird tools revealed that the response to the PROPFIND request is truncated. E.g, the last lines (line 4433 to line 4438) of the response look like this:

    <response>
    <href>/addressbooks/users/user/addressbook/e274761f-dceb-4fa6-9afd-db5f458c345e.vcf</href>
    <propstat>
    <prop>
    <getcontenttype>text/vcard;charset=utf-8</getcontenttype>
    <getetag>”079e9434af826

    the content length according to the reply header should be 177517, truncation occurs after 155308 bytes. I’ve tried on different machines (Windows 7, Windows 10) and with varying cardbook sync settings.

    I would be very greatful for any hint (maybe some Thunderbird (network) parameter that can cause such behaviour?)

    Best,

    Michael

     

  • #1108

    CardBook
    Keymaster

    why do you need to set it to 400… let it to 100 and make multiples syncs if the first one does not retrieve all you contacts… I can’t do anything for this truncation…

  • #1110

    mf
    Participant

    Thanks a lot for your quick reply. But mulitple syncs won’t help. The problem is that no sync of any contact works as soon as the addressbook contains more than 180 contacts.

    (Loading them into an empty adressbook for the first time from a file will result in an upload to the server, so I can get the 400+ contacts into my addressbook and to the server but after that nothing will be synced anymore, even when I change a single contact, while e.g. DAVDroid still syncs).

    Also if there are already more than 180 contacts on the server when I create a new cardbook addressbook to sync with it, no contacts will be downloaded from the server.

    (As long as I initally load 180 contacts or less, all changes to them get synced, as soon as I add one more contact, nothing will be synced).

    Too bad. Had hoped that an asynchronous handling of the PROPFIND request might have helped.

  • #1111

    CardBook
    Keymaster

    are you sure it’s not linked with your Synology setup ?… I’ve got lot of Synology users and that’s the first time I see such a truncation problem…

  • #1112

    CardBook
    Keymaster

    may you send me the CardBook log in debug mode to see this truncation ? (especially the result of the PROPFIND request)

  • #1115

    mf
    Participant

    Here’s the CardBook log in debug mode (set to 500 lines) with the server name replaced:

     

    2017.09.08 15:39:58:377 : Mobil: Suche Kontakte …
    2017.09.08 15:39:58:386 : Mobil : debug mode : method : (new String(“PROPFIND”))
    2017.09.08 15:39:58:387 : Mobil : debug mode : body : (new String(“<?xml version=\”1.0\” encoding=\”utf-8\”?><D:propfind xmlns:D=\”DAV:\”><D:prop><D:getcontenttype/><D:getetag/></D:prop></D:propfind>”))
    2017.09.08 15:39:58:387 : Mobil : debug mode : headers : (new String(“({depth:\”1\”, ‘content-type’:\”application/xml; charset=utf-8\”, ‘User-Agent’:\”Thunderbird CardBook/21.9\”, Authorization:\”Basic bWljaGFlbDpJbEJQLGRUdg==\”})”))
    2017.09.08 15:39:58:387 : Mobil : debug mode : username : (new String(“michael”))
    2017.09.08 15:39:58:387 : Mobil : debug mode : url : (new String(“https://[skipped.my.server]:8443/addressbooks/users/michael/addressbook/”))
    2017.09.08 15:39:59:404 : Mobil : debug mode : cardbookRepository.cardbookServerSyncRequest : (new Number(1))
    2017.09.08 15:40:00:417 : Mobil : debug mode : cardbookRepository.cardbookServerSyncRequest : (new Number(1))
    2017.09.08 15:40:01:482 : Mobil : debug mode : cardbookRepository.cardbookServerSyncRequest : (new Number(1))
    2017.09.08 15:40:02:494 : Mobil : debug mode : cardbookRepository.cardbookServerSyncRequest : (new Number(1))
    2017.09.08 15:40:03:508 : Mobil : debug mode : cardbookRepository.cardbookServerSyncRequest : (new Number(1))
    2017.09.08 15:40:04:521 : Mobil : debug mode : cardbookRepository.cardbookServerSyncRequest : (new Number(1))
    2017.09.08 15:40:05:533 : Mobil : debug mode : cardbookRepository.cardbookServerSyncRequest : (new Number(1))
    2017.09.08 15:40:06:547 : Mobil : debug mode : cardbookRepository.cardbookServerSyncRequest : (new Number(1))
    2017.09.08 15:40:07:581 : Mobil : debug mode : cardbookRepository.cardbookServerSyncRequest : (new Number(1))
    2017.09.08 15:40:08:595 : Mobil : debug mode : cardbookRepository.cardbookServerSyncRequest : (new Number(1))
    2017.09.08 15:40:09:609 : Mobil : debug mode : cardbookRepository.cardbookServerSyncRequest : (new Number(1))
    2017.09.08 15:40:10:622 : Mobil : debug mode : cardbookRepository.cardbookServerSyncRequest : (new Number(1))
    2017.09.08 15:40:11:635 : Mobil : debug mode : cardbookRepository.cardbookServerSyncRequest : (new Number(1))
    2017.09.08 15:40:12:655 : Mobil : debug mode : cardbookRepository.cardbookServerSyncRequest : (new Number(1))
    2017.09.08 15:40:13:667 : Mobil : debug mode : cardbookRepository.cardbookServerSyncRequest : (new Number(1))
    2017.09.08 15:40:14:680 : Mobil : debug mode : cardbookRepository.cardbookServerSyncRequest : (new Number(1))
    2017.09.08 15:40:15:692 : Mobil : debug mode : cardbookRepository.cardbookServerSyncRequest : (new Number(1))
    2017.09.08 15:40:16:049 : Mobil : debug mode : Connection status : Failed : NetworkError
    2017.09.08 15:40:16:049 : Mobil : debug mode : Security Information :
    2017.09.08 15:40:16:050 : Mobil : debug mode : Security state of connection :
    2017.09.08 15:40:16:050 : Mobil : debug mode : Secure connection
    2017.09.08 15:40:16:050 : Mobil : debug mode : Common name (CN) : finkis.mynetgear.com
    2017.09.08 15:40:16:050 : Mobil : debug mode : Issuer : Let’s Encrypt
    2017.09.08 15:40:16:050 : Mobil : debug mode : Organisation :
    2017.09.08 15:40:16:051 : Mobil : debug mode : SHA1 fingerprint : 22:83:4D:71:C7:4F:B4:89:64:5E:E6:AE:93:C3:6C:F1:BD:1D:10:6D
    2017.09.08 15:40:16:051 : Mobil : debug mode : Valid from Freitag, 08. September 2017 11:19:00
    2017.09.08 15:40:16:051 : Mobil : debug mode : Valid until Donnerstag, 07. Dezember 2017 11:19:00
    2017.09.08 15:40:16:051 : Mobil : debug mode : response etag : (new String(“\”89913f7f11490be7a776b48003f9f7c6\””))
    2017.09.08 15:40:16:051 : Mobil: Synchronisation fehlgeschlagen (Schritt: serverSyncCards, URL: https://[skippedmyserver]:8443/addressbooks/users/michael/addressbook/, Status: 0)
    2017.09.08 15:40:16:704 : Mobil : debug mode : cardbookRepository.cardbookServerSyncRequest : (new Number(1))
    2017.09.08 15:40:16:704 : Mobil : debug mode : cardbookRepository.cardbookServerSyncResponse : (new Number(1))
    2017.09.08 15:40:16:705 : Mobil: Synchronisation mit dem Server nicht möglich.
    2017.09.08 15:40:16:706 : Alle Synchronisationen beendet.

  • #1116

    CardBook
    Keymaster

    you’ve got a network error : check your firewall|proxy access (this is a common error with Synology ;O)

  • #1117

    mf
    Participant

    And the reply to the corresponding request (shortened in the middle) as of the Thunderbird Debugger:

    <?xml version=’1.0′ encoding=’UTF-8′?>
    <multistatus xmlns=’DAV:’>
    <response>
    <href>/addressbooks/users/michael/addressbook/</href>
    <propstat>
    <prop>
    <getcontenttype>httpd/unix-directory</getcontenttype>
    <getetag>”89913f7f11490be7a776b48003f9f7c6″</getetag>
    </prop>
    <status>HTTP/1.1 200 OK</status>
    </propstat>
    </response>
    <response>
    <href>/addressbooks/users/michael/addressbook/002cb247-afe4-4aad-8bc9-b131498e7570.vcf</href>
    <propstat>
    <prop>
    <getcontenttype>text/vcard;charset=utf-8</getcontenttype>
    <getetag>”8d57a70a2af1d4e535de7afb98fe2db9″</getetag>
    </prop>
    <status>HTTP/1.1 200 OK</status>
    </propstat>
    </response>
    <response>
    <href>/addressbooks/users/michael/addressbook/0031864d-f1b9-4b82-acb3-22909915716a.vcf</href>
    <propstat>
    <prop>
    <getcontenttype>text/vcard;charset=utf-8</getcontenttype>
    <getetag>”803786e96e2d3695d8e057d3cf5c4c5b”</getetag>
    </prop>
    <status>HTTP/1.1 200 OK</status>
    </propstat>
    </response>
    <response>
    <href>/addressbooks/users/michael/addressbook/003fa012-0602-47ee-8ab5-b33d832f2579.vcf</href>
    <propstat>
    <prop>
    <getcontenttype>text/vcard;charset=utf-8</getcontenttype>
    <getetag>”bbd9800ed8a1bade5e658bc7ac60d342″</getetag>
    </prop>
    <status>HTTP/1.1 200 OK</status>
    </propstat>
    </response>
    <response>
    <href>/addressbooks/users/michael/addressbook/0042e95d-8ea0-43fe-bad8-f22381b41505.vcf</href>
    <propstat>
    <prop>
    <getcontenttype>text/vcard;charset=utf-8</getcontenttype>
    <getetag>”eff4880af8198bc4ca6077e2dc2c1442″</getetag>
    </prop>
    <status>HTTP/1.1 200 OK</status>
    </propstat>
    </response>

    […]

    <response>
    <href>/addressbooks/users/michael/addressbook/e1914d2b-192d-4d99-b6f2-0abfefe9577d.vcf</href>
    <propstat>
    <prop>
    <getcontenttype>text/vcard;charset=utf-8</getcontenttype>
    <getetag>”d1077d3c915a3fd1940f88c90b9702e2″</getetag>
    </prop>
    <status>HTTP/1.1 200 OK</status>
    </propstat>
    </response>
    <response>
    <href>/addressbooks/users/michael/addressbook/e1adce61-59e7-4525-91e0-12147327dbaf.vcf</href>
    <propstat>
    <prop>
    <getcontenttype>text/vcard;charset=utf-8</getcontenttype>
    <getetag>”ab4bf7923f477bd511ae74ac92b13ed3″</getetag>
    </prop>
    <status>HTTP/1.1 200 OK</status>
    </propstat>
    </response>
    <response>
    <href>/addressbooks/users/michael/addressbook/e274761f-dceb-4fa6-9afd-db5f458c345e.vcf</href>
    <propstat>
    <prop>
    <getcontenttype>text/vcard;charset=utf-8</getcontenttype>
    <getetag>”079e9434af826

     

  • #1118

    CardBook
    Keymaster

    strange that they are different… but in your case, which has happened a lot check the requests at your proxy and|or firewall…

  • #1119

    mf
    Participant

    How could this be then, that the vey same addressbook syncs when I simply delete 200 contacts on the server?

    As of debugging the cardbookWebDAV.js this is just the default error message when status is 0, and status is 0 because the XML reply could not be parsed. Error console:

    XML-Verarbeitungsfehler: Kein Wurzel-Element gefunden
    Adresse: https://nas.finkis.at:8443/addressbooks/users/michael/addressbook/
    Zeile Nr. 4438, Spalte 32: addressbook:4438:32

    and this is because the server response is truncated at exactly line 4438:32.

    Pasting this truncated response in an editor yields 155308 characters, while the Content-Length header field (Thunderbird Debugger Headers) of the response is

    Content-Length: “177517”

    So I do not believe in a network error (how would the repsonse arrive)?

    That CardDAV syncs normally makes me also think that it is not a server-side setup issue. (Also, if it were the server that would have any limitation in response length, it is probable that it would also set the content-length header appropriately).

     

  • #1120

    mf
    Participant

    Sorry did not read your last reply before sending off mine. Yes I’ll check firewall settings, could happen in the middle.

  • #1121

    CardBook
    Keymaster

    very interesting, try this (I got this from a user) :

    CardBook needs port 5006 (WebDAV SSL) opened for some reason this was screwed after an update of the router firmware.

  • #1122

    mf
    Participant

    I’ve tried with the most liberal router settings and turning off the Windows firewall, it didn’t help.

    Then I tried Outlook with Outlook caldav synchronizer plugin on the same machine (with router back to normal config and firewall on) and this worked. So I think router and firewall can be excluded as well.

    I then tried Thunderbird with Inverse SOGo connector and it also failed. It uses httprequest rather than xmlhttprequest but again the response is truncated. So I am back to my inital conjecture and pretty sure that it is a Thunderbird implementation/setup issue. However, if it is an implementation issue, I now think it cannot be handeled at the add-on level. So I’ll have to query Mozilla …

    Thanks a lot for your attention and patience …

    … and that great CardBook extension!

  • #1123

    CardBook
    Keymaster

    thanks a lot for your investigations : I’m very interested by the Mozilla response, so keep me in touch ! :O)

  • #1124

    CardBook
    Keymaster

    … are you sure that Synology send untruncated responses ?

  • #1132

    mf
    Participant

    Yes, used curl tool (with method, headers and data set as reported in Thunderbird Debugger) to send the request from a (cygwin) shell and get the server reply (piped into a file). It is well-formed XML and has exactly 177517 characters (i.e., exatly the content length reported also in the response header by the Thunderbird Debugger).

  • #1142

    CardBook
    Keymaster

You must be logged in to reply to this topic.