The REPORT addressbook-query spec confuses me: I think it’s saying that not specifying a filter nor a set of properties should be the same as not filtering (i.e. do the same as unparameterized PROPFIND) and that the return format is the same as PROPFIND.
The only difference is that REPORT addressbook-query only returns address resources (VCards), while PROPFIND returns anything in that collection. As you can read in RFC 6352 5.2:
Address book collections MUST only contain address object resources and collections that are not address book collections.
So, there MUST NOT be other resources like .ics files or photo assets in the same collection, so this would not be a potential problem. However, there may be non-address book-sub-collections, i.e. a “photos/” sub-collection. This would be returned by PROPFIND, but not by REPORT addressbook-query.
Also, I have seen servers that use address book sub-collections (which is not allowed). In this case, they’re also returned by PROPFIND, but not by REPORT addressbook-query.
For synchronization, we’re not interested in any sub-collections or other data than the addresses themselves, so in my opinion, REPORT addressbook-query is the right way to do it.
That error is somehow being triggered via at least 4 layers of indirection that I can’t follow here. I wish I could get the server to just tell me that $name it’s being called on. I don’t care about which $name it chooses, I care about all the $names.
As far as I know, there are several owncloud/contacts issues on GitHub that deal with this problem: a member resource can’t be found for some reason (404), so the whole collection REPORT returns 404.
So, as a compatibility measure, would you add 404 to the list of fallback cases? If PROPFIND also 404s then you know the thing is really gone. I will bother the ownCloud people to see if they have a clue in the meantime.
Ok, thanks. When thinking about which error codes should be used for the workaround, I didn’t choose 404 because it indicates a hard error and there’s nothing much to interpret (while all other error codes may at least have an understandable reason to be returned). I will consider adding 404 to an upcoming version version of DAVdroid, but please report this to/fix this in OwnCloud 🙂
What a painful protocol; there shouldn’t be two ways to get the exact same bytes.
They’re not exactly the same (see above). Note that PROPFIND is plain WebDAV (you don’t need a CardDAV server to synchronize using PROPFIND/GET/PUT/DELETE, a WebDAV server would be enough), while REPORT addressbook-query is CardDAV, so it makes sense (to me) that a CardDAV server is able to process such requests correctly – it’s more or less the essence of the CardDAV extension to WebDAV.
I really really appreciate DAVDroid; I was using proprietary implementations before, and before that exporting to my SDcard whenever I remembered (which ended badly multiple times), and before that Google. DAVDroid is the thing that lets me rely on my phone to behave sensibly in the cloud era.
Thanks 😃 That’s the goal of DAVdroid, and I’m happy when its useful for you.