Android reports error after every calendar sync: DavException: Invalid DAV response: Couldn't parse Multi-Status response on REPORT multi-get

[AutoImport-ThomasSteinbach]

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

[rfc2822]

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.

[rfc2822]

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 /SOGo/dav/maxmuster/Calendar/personal/11.

If you look at your server’s response on the file-listing PROPFIND, you can find:

<D:href>/SOGo/dav/maxmuster/Calendar/personal/http:/tracks.example.com/tracks/todos/11</D:href>

This seems to be a server error. Calendar/personal should 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/11 is 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.

Summary:

1. There was a DAVdroid error in parsing the multi-status response. This has been fixed in fb33767e571b91cb78e267a05505e10c91ad3e16.
2. 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?