@ksokol Apparantely you have entered http://192.168.43.33:1984/carldav/dav/test01@localhost.de/calendar as the URL, but it doesn’t support CardDAV (and it doesn’t sound like it should), so DAVdroid can’t detect an address-book.
You’ll have to create a separate account with a CardDAV-capable URL.
If you want to support CalDAV + CardDAV in one account, you may use well-known URLs.
@rfc2811 Thank you for your answer! Unfortunately, I managed to run calendar and addressbook sync with just one account in version 0.9.1.3!
In version 0.9.1.3 DAVdroid made the following request to the same version of the server: http://fpaste.org/355618/66240214/
DAVdroid version 0.9.1.3: http://fpaste.org/355619/66244114/
I think that it looks like a regression in version 1.x.
I can analyse the differences between version 0.9 and 1.0 if you like.
@ksokol said:
@rfc2811 Thank you for your answer! Unfortunately, I managed to run calendar and addressbook sync with just one account in version 0.9.1.3!
Yes, as far as I remember (0.9.x is some time ago for me, as I’m constantly working with the latest master version), DAVdroid 0.9.1.3 tried “/” without reason.
I think that it looks like a regression in version 1.x.
I don’t think so. If you enter a CalDAV URL, only CalDAV should be detected – except if there are well-known URLs. I don’t see any reason to try “/” for good luck, as DAVdroid 0.9.x did (if I remember correctly).
Or do you see any other problem here?
Why don’t you just configure well-known URLs? This would be the correct solution.
Finally, I managed to find the difference between DAVdroid 0.9 and 1.x regarding addressbook sync. Please take a look at https://gitlab.com/bitfireAT/davdroid/merge_requests/4.
Feedback is appreciated.
@ksokol Hello, thanks for the merge request. However, I can
OPTIONS doesn’t return DAV: addressbook), and there are no well-known URIs, finding an address book sounds confusing and strange for me (even if DAVdroid 0.9.x does so),In the case that OPTIONS does return DAV: addressbook, checkUserGivenURL will already query for the addressbook-home-set.
I grapped the code from here: https://gitlab.com/bitfireAT/davdroid/blob/d6cff63f2d9892ee4d1f4180776898f9026e309d/app/src/main/java/at/bitfire/davdroid/resource/DavResourceFinder.java (line 244 to line 275).
OPTIONS does return DAV: addressbook. My server does not support current-user-principal, though. That might be root cause. I will check my implementation.
@ksokol said:
OPTIONS does return DAV: addressbook. My server does not support current-user-principal, though. That might be root cause. I will check my implementation.
DAVdroid supports servers without current-user-principal support, for instance Synology DSM CalDAV. If the URL returns DAV: addressbook on OPTIONS, it should be checked for the addressbook-homeset property in
Can you maybe provide a test account so that I can have a look?
That’s what DAVdroid 0.9.x was doing so far. I sent you credentials for a test account on my server. Thank you for your help. I really appreciate it.
@ksokol Hello, the problem was that I didn’t expect the home set to be an address book (only that home sets contain address books). However, according to RFC 6352, address book sets may also be address books, so the collection enumeration had to be changed so that it now handles home sets which are their own collections.
Could you please try with latest master (fb0552d)?
@rfc2822 said:
fb0552d
Checked it with latest master(fb0552d). Thumbs up. It is working now. Thank you!
