I found the solution. Because the new lôôk of the software made me loose my way (my fault). The solution was that I was putting in the wrong code in, so it could not get to my server. Thanks for this super App.
Android reports error after every calendar sync: DavException: Invalid DAV response: Couldn't parse Multi-Status response on REPORT multi-get
Version: 0.7.2 from Google Play
Running on: Galaxy S5 SM-G900F; Android 5.0; Kernel 3.4.0-4209230 dpi@SWDD6015 #1; Build LRX21T.G900FXXU1BOB7
Connected to: SOGo (updated on 2015-03-29) running on Debian 7 root server
After every sync following exception is thrown:
E/davdroid.DavSyncAdapter(22823): Invalid DAV response E/davdroid.DavSyncAdapter(22823): at.bitfire.davdroid.webdav.DavException: Invalid DAV response: Couldn't parse Multi-Status response on REPORT multi-get E/davdroid.DavSyncAdapter(22823): ...
See full log with exception at line 4735 at https://gist.githubusercontent.com/ThomasSteinbach/7fe1b06c1b8424694fae/raw/gistfile1.txt
This issue is caused by fact that the requested file doesn’t exist on the server:
<D:response><D:href>/SOGo/dav/maxmuster/Calendar/personal/11</D:href><D:status>HTTP/1.1 404 Not Found</D:status></D:response>
but DAVdroid doesn’t expect a multi-get response to fail. Will have a look at it.
Ok, this problem is now fixed and DAVdroid shows a 404 error notification when a multi-get response indicates status 404 for a requested resource.
However, then there’s the question: Why does DAVdroid request
/SOGo/dav/maxmuster/Calendar/personal/11? The preceding PROPFIND response doesn’t even contain
If you look at your server’s response on the file-listing PROPFIND, you can find:
This seems to be a server error.
Calendar/personalshould contain the resources directly, and not in a directory structure called
/http:/tracks.example.com/tracks/todos/. Apparently, there’s something wrong with the TODOs. If
http:/tracks.example.com/tracks/todos/11is the file name, it should have been encoded.
DAVdroid expects the requested files to be directly in the requested folder (since it sets
Depth: 1), so it requests <folder> + /11 (where 11 is the file name). This requests fails with 404.
- There was a DAVdroid error in parsing the multi-status response. This has been fixed in fb33767e571b91cb78e267a05505e10c91ad3e16.
- There’s still a problem on the server side (with TODOs, details see above).
Do you agree? Can you please open an issue in the SOGo bug tracker, providing the DAVdroid logs and this issue as reference?