Thunderbird is failing autodiscovering Address Books

[roughnecks]

Hello,
after having successfully set up calendars auto-discover in TB, I noticed that address books can be imported only if specifying the full URL provided by Radicale's webpage.

When adding an email account in TB it should support discovering both remote calendars and address books, since it tells you so, but even trying manually to add a CardDAV A.book, specifying only the dav.domain.tld, and not the full A.book URL, it fails and tells this:

https://i.imgur.com/GINEjQr.jpeg

No address books could be found to be imported

To be noted: I'm trying this, logging in with just username and not "email"

https://termbin.woodpeckersnest.space/1rkrpq

I'm running Radicale from Debian 12, not sure who the fault is.. Radicale or Thunderbird, since calendars work after the small patch reported here

[pbiering]

Hmm, works with

• Calendar: Thunderbird's internal implementation
• Addressbooks: Thunderbird in combination with CardBook Add-on
  both shows available calendars or addressbooks and let me choose what to subscribe

[roughnecks]

But TB now has native support for both, why using an extension?

[roughnecks]

But TB now has native support for both, why using an extension?

Oh, misread your post. Well, there's something wrong with my setup then, because it doesn't work with or without the extension.

[jonassmedegaard]

Try check that your front-end web server properly handles meta-requests for caldav and carddav.

One way to do that is with the following from a command-line (replacing USERNAME and CALENDARHOST to local values:

wget -u USERNAME https://CALENDARHOST/.well-known/carddav/

[roughnecks]

-u isn't a valid switch

wget --http-user roughnecks https://dav.example.com/.well-known/carddav/

returns an index.html with the frontend page: <title>Radicale Web Interface</title>

Anyway, I did some more test with internal TB CardDAV support and I can confirm that it doesn't find any address book unless I pass it the full URL, as listed in Radicale web interface. If I pass the base domain (dav.example.com) no address books can be found.

At this point I'm not even sure if this is correct:

    location / {
        return 301  /radicale/;
    }

    location /radicale/ { # The trailing / is important!
        proxy_pass http://[::1]:5232/; # The / is important!
        proxy_set_header  X-Script-Name /radicale;
        proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header  Host $http_host;
        proxy_pass_request_headers on;
        proxy_pass_header Authorization;
        }

But if I remove the first 301, I cannot point anything to the base domain, I'm forced to give it the /radicale/ path.

[jonassmedegaard]

whops, I meant curl, not wget.

For wget use options --user --ask-password --spider.

[roughnecks]

wget --user simone --ask-password --spider https://dav.example.tld/.well-known/carddav/
Password for user ‘simone’:
Spider mode enabled. Check if remote file exists.
--2024-07-17 20:39:13--  https://dav.example.tld/.well-known/carddav/
Resolving dav.example.tld (dav.example.tld)... IP-Redacted, IP-Redacted
Connecting to dav.example.tld (dav.example.tld)|IP-Redacted|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://dav.example.tld/radicale/ [following]
Spider mode enabled. Check if remote file exists.
--2024-07-17 20:39:13--  https://dav.example.tld/radicale/
Connecting to dav.example.tld (dav.example.tld)|IP-Redacted|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: /radicale/.web [following]
Spider mode enabled. Check if remote file exists.
--2024-07-17 20:39:13--  https://dav.example.tld/radicale/.web
Connecting to dav.example.tld (dav.example.tld)|IP-Redacted|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: /radicale/.web/ [following]
Spider mode enabled. Check if remote file exists.
--2024-07-17 20:39:13--  https://dav.example.tld/radicale/.web/
Connecting to dav.example.tld (dav.example.tld)|IP-Redacted|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5704 (5.6K) [text/html]
Remote file exists and could contain further links,
but recursion is disabled -- not retrieving.

[roughnecks]

#1160

[roughnecks]

Just to be more specific, I have these configurations in my base domain https://domain.tld (not the dav. subdomain)

   location /mail {
        try_files /.well-known/autoconfig/mail/config-v1.1.xml =404;
   }

   location /.well-known/caldav {
        return 301 https://dav.domain.tld;
   }

   location /.well-known/carddav {
        return 301 https://dav.domain.tld;
   }

Mail accounts are automatically configured by TB, calendars also work now after this patch #1536 (comment)
so the only thing left are address books.

I have a shared VPS and I would like for users to be able to configure their mail account in TB and get everything set up at once - mail, calendars and address books.

[jonassmedegaard]

#1160

Yes, Radicale does not handle those hints. That's the reason I suggested you to try check that your front-end web server handles it.

[roughnecks]

Ok, then I pasted what you wanted to see, right?

[jonassmedegaard]

I guess - it seems you shared a mangled output with some dummy domains, where the use or not of subdomain "dav" seemingly does not correlate with your own described setup.
But really I didn't mean for you to show it to me, only suggested a check that you could do on your own, so if you know what you mangled and how it is corresponds with your setup, then you've succesfully checked your setup and can move on to other causes of failure.

[roughnecks]

I just replaced "myrealdomain.tld" with "example.tld", so when you see "dav.example.tld" that is "dav.myrealdomain.tld"

meaning: I haven't mangled anything else but the base domain name and tld.

Anyway, thanks for your help.

[roughnecks]

Calendars: dav.woodpeckersnest.space

Calendars: woodpeckersnest.space

Address Book: dav.woodpeckersnest.space

(no address books were found to be added for specified account)

Address Book: woodpeckersnest.space

(connection failed)

Address Book: full URL

What I mean is, I have the same setup for caldav and carddav, so why the difference?
Now I posted my domain, so everything is more clear... woodpeckersnest.eu should be the same as .space, I own both of them.

[jonassmedegaard]

Perhaps helpful to examine logfiles of your front-end web server, to understand exactly what your Thunderbird client is requesting in each test case, and try derive a pattern from that.

[itglob]

this is because Radicale terminate all DAV request to url like /username/

for example baikal server response /dav.php/principals/username/
to current-user-principal and /dav.php/addressbooks/username/ to addressbook-home-set

but thunderbird has some "optimization" in file /thunderbird-115.13.0/comm/mailnews/addrbook/modules/CardDAVUtils.jsm

let triedURLs = new Set();
async function tryURL(url) {
if (triedURLs.has(url)) {
return;
}
triedURLs.add(url);

[roughnecks]

Hi,
I've done some more tests and I can confirm that only caldav discovery works from thunderbird:

These logs are about adding an address book with "username" and root "domain.tld"

 - - [11/Sep/2024:15:42:11 +0200] "PROPFIND /.well-known/carddav HTTP/2.0" 301 169 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0 Thunderbird/128.2.0"
 - - [11/Sep/2024:15:42:11 +0200] "PROPFIND /radicale/ HTTP/2.0" 401 61 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0 Thunderbird/128.2.0"
 - trooper [11/Sep/2024:15:42:24 +0200] "PROPFIND /radicale/ HTTP/2.0" 207 186 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0 Thunderbird/128.2.0"
 - trooper [11/Sep/2024:15:42:24 +0200] "PROPFIND /radicale/trooper/ HTTP/2.0" 207 216 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0 Thunderbird/128.2.0"

The same applies for "username" and radicale address at "dav.domain.tld"

 - - [11/Sep/2024:15:43:13 +0200] "PROPFIND /.well-known/carddav HTTP/2.0" 301 169 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0 Thunderbird/128.2.0"
 - - [11/Sep/2024:15:43:13 +0200] "PROPFIND /radicale/ HTTP/2.0" 401 61 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0 Thunderbird/128.2.0"
 - trooper [11/Sep/2024:15:43:20 +0200] "PROPFIND /radicale/ HTTP/2.0" 207 186 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0 Thunderbird/128.2.0"
 - trooper [11/Sep/2024:15:43:20 +0200] "PROPFIND /radicale/trooper/ HTTP/2.0" 207 216 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0 Thunderbird/128.2.0"

In both these cases TB says it cannot find any address book.

Last is the log for "username" and full address book link, as reported in radicale's webui:

 - trooper [11/Sep/2024:15:43:20 +0200] "PROPFIND /radicale/trooper/ HTTP/2.0" 207 216 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0 Thunderbird/128.2.0"
 - - [11/Sep/2024:15:44:33 +0200] "PROPFIND /radicale/trooper/80b45131-xxx-xxxx-xxxx/ HTTP/2.0" 401 61 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0 Thunderbird/128.2.0"
 - trooper [11/Sep/2024:15:44:39 +0200] "PROPFIND /radicale/trooper/80b45131-xxx-xxxx-xxxx/ HTTP/2.0" 207 348 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0 Thunderbird/128.2.0"

This is successful.

[itglob]

hi,
you test different hostname, but question is URI (https://fqdn/URI - https://en.wikipedia.org/wiki/Uniform_Resource_Identifier).
this all about understanding RFC and strange Thunderbird code

[pbiering]

started now a client status page in Wiki: https://github.com/Kozea/Radicale/wiki/Client-Status

[ctapmex]

got a ticket - https://bugzilla.mozilla.org/show_bug.cgi?id=1925006

[roughnecks]

got a ticket - https://bugzilla.mozilla.org/show_bug.cgi?id=1925006

Thanks!

[ctapmex]

fixed - checked on the nightly build from "10-Feb-2025 12:00" thunderbird-137.0a1.enka.linux-x86_64.tar.xz

[roughnecks]

that's nice to hear, did you test it personally?

edit: think so, now it's just a matter of time 😊

[ctapmex]

Yes, l tested it

[roughnecks]

Well, thanks a bunch @ctapmex
Yesterday I was bored and upgraded Thunderbird from ESR to release, so I'm running 139.x now - and it's working just fine, I didn't touch a single bit in my configuration.

Closing here :)