Suddenly it worked.
Service discovery not working properly
-
I have
.well-known
set up properly on Radicale, e.g. see how the redirect and authentication work to eventually yield atext/calendar
resource:% GET -C "madduck@madduck.net:$(pass caldav.madduck.net/madduck@madduck.net | head -1)" -eSd https://caldav.madduck.net/.well-known/caldav GET https://caldav.madduck.net/.well-known/caldav 401 Unauthorized Connection: close Date: Thu, 22 Nov 2018 04:27:07 GMT Server: Apache/2.4.25 (Debian) WWW-Authenticate: Basic realm="Radicale" Content-Length: 466 Content-Type: text/html; charset=iso-8859-1 Strict-Transport-Security: max-age=31536000 Title: 401 Unauthorized GET https://caldav.madduck.net/.well-known/caldav 303 See Other Location: /madduck@madduck.net/calendar.ics/ GET https://caldav.madduck.net/madduck@madduck.net/calendar.ics/ 200 OK ETag: "792243342b8910dda23247a582a14d25" Content-Length: 1363953 Content-Type: text/calendar Last-Modified: Thu, 22 Nov 2018 00:53:06 +0000
This works with all other clients, but when I try to connect to this server from DavDroid (2.0.5-ose from FDroid), it doesn’t yield the proper resources. Here are the requests made to the server:
[pid: 1061|app: 0|req: 196/221] 202.78.240.10 (madduck@madduck.net) {58 vars in 867 bytes} [Thu Nov 22 05:30:00 2018] PROPFIND / => generated 50 bytes in 5 msecs (HTTP/1.1 207) 3 headers in 128 bytes (3 switches on core 1) [pid: 1061|app: 0|req: 197/222] 202.78.240.10 (madduck@madduck.net) {50 vars in 833 bytes} [Thu Nov 22 05:30:02 2018] PROPFIND /.well-known/carddav => generated 0 bytes in 1 msecs (HTTP/1.1 303) 1 headers in 75 bytes (1 switches on core 0) [pid: 1061|app: 0|req: 198/223] 202.78.240.10 (madduck@madduck.net) {50 vars in 833 bytes} [Thu Nov 22 05:30:03 2018] PROPFIND /.well-known/carddav => generated 0 bytes in 1 msecs (HTTP/1.1 303) 1 headers in 75 bytes (0 switches on core 1) [pid: 1061|app: 0|req: 199/224] 202.78.240.10 (madduck@madduck.net) {50 vars in 901 bytes} [Thu Nov 22 05:30:05 2018] PROPFIND /madduck@madduck.net/addressbook.vcf/ => generated 355 bytes in 6 msecs (HTTP/1.1 207) 3 headers in 129 bytes (3 switches on core 0) [pid: 1061|app: 0|req: 200/225] 202.78.240.10 (madduck@madduck.net) {46 vars in 773 bytes} [Thu Nov 22 05:30:07 2018] OPTIONS /madduck@madduck.net/ => generated 0 bytes in 3 msecs (HTTP/1.1 200) 2 headers in 173 bytes (1 switches on core 1) [pid: 1061|app: 0|req: 201/226] 202.78.240.10 (madduck@madduck.net) {58 vars in 867 bytes} [Thu Nov 22 05:30:08 2018] PROPFIND / => generated 50 bytes in 7 msecs (HTTP/1.1 207) 3 headers in 128 bytes (2 switches on core 0) [pid: 1061|app: 0|req: 202/227] 202.78.240.10 (madduck@madduck.net) {50 vars in 829 bytes} [Thu Nov 22 05:30:10 2018] PROPFIND /.well-known/caldav => generated 0 bytes in 2 msecs (HTTP/1.1 303) 1 headers in 72 bytes (1 switches on core 1) [pid: 1061|app: 0|req: 203/228] 202.78.240.10 (madduck@madduck.net) {50 vars in 829 bytes} [Thu Nov 22 05:30:11 2018] PROPFIND /.well-known/caldav => generated 0 bytes in 1 msecs (HTTP/1.1 303) 1 headers in 72 bytes (1 switches on core 0) [pid: 1061|app: 0|req: 204/229] 202.78.240.10 (madduck@madduck.net) {58 vars in 867 bytes} [Thu Nov 22 05:30:13 2018] PROPFIND / => generated 50 bytes in 4 msecs (HTTP/1.1 207) 3 headers in 128 bytes (3 switches on core 1)
You can see how the request for
.well-known/carddav
yields the correct URL, but then there is aPROFIND /madduck@madduck.net/
which makes no sense. Finally, even though.well-known/caldav
is also queried twice (why twice?), the redirect is not honoured.Consequently, upon opening DavDroid, there is only a CardDAV section to this account.
Worse yet, however, trying to refresh the collections list for CardDAV results in more requests like
PROPFIND /madduck@madduck.net/
. Looking into the debug output, I see that the SQLite dump only has one entry for CardDAV, and it’s got the wrong principal:4 | madduck@madduck.net | carddav | https://caldav.madduck.net/madduck@madduck.net/ |
Only after I manually update the SQLite database and shove it into place, then will DavDroid see the actual collections.
If this is a bug, where do I report it?
If this is not a bug, what is going on?
Thanks,
martin