Typically guy who last changed something, broke something.
My approach to “broken (technical) things” is that everything tends to break all the time (by the law of entropy). Unless you put enormous efforts into maintaining a technical device, it will break sooner or later (in most cases, sooner). In this case, a part of the maintaining efforts is to find out why ETags don’t work, although they’re required by DAVdroid
When we update the server code, and something happens, we look at the server. I understand what you are saying regarding following the RFC and not loving the idea of workaround hacks. It is just weird that the 3 other things we have syncing are doing fine and now just davdroid is throwing the error.
To be honest, when I implemented the ETag check in the code, I didn’t think that it could be a problem. I just wanted to be sure that every resource has an ETag, so that the synchronization logic doesn’t to weird things, or crash with a
NullPointerException because the ETag is
null, or something like that. I thought (and still think) it was a good idea to force a well-defined sync state. Unfortunately, there are problems – now we have to solve them. Isn’t it a good thing to improve OwnCloud, so that CalDAV/CardDAV will work better in the future? (Of course, there’s still the possibility that the error is on DAVdroid’s side, even if I don’t think so in this special case.)
Yes we are on OwnCloud 8.1.3 and do use a shared address book. Its shared out by admin so all users can sync corporate contacts.
The other user had a shared calendar. He pointed me to https://github.com/owncloud/calendar/issues/832 and said that it affects only shared calendars. Maybe there’s a similar issue for shared address books.
I’ll be able to grab logs monday and begin seeing why e-tags aren’t making it, quick research shows it could be something with nginx, not even owncloud.
I don’t think so, because the questionable response is a 207 multi-get. nginx won’t intercept and change response bodies by itself.
ah thought you wanted server logs, i see just the davdroid ones. makes sense, here they are http://pastebin.com/eA92tyYF
Thanks. These are without verbose logs, aren’t they? With verbose logs, we would see the actual server response (and not only DAVdroid’s interpretation of it).
But as you can see:
[debug] Received <response> for https://firstname.lastname@example.org, status: null, properties: [getetag(DAV:): null,
For instance, this contact:
/email@example.com doesn’t have an ETag, nor Content-Type, nor any content (according to the server’s response).