3. Service discovery not working properly

Service discovery not working properly

  • M

    I have .well-known set up properly on Radicale, e.g. see how the redirect and authentication work to eventually yield a text/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 a PROFIND /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

    0
Log in to reply