Very high latency on Card/Cal/WebDAV due to HTTP "Authorization Basic"

[nzeid]

Nextcloud version (using AIO): 29.0.2
Operating system and version: Rocky Linux 9.4

Before I did much deeper into the source code, I wanted to see if perhaps any expert Nextcloud devs know anything right off the top of their heads about this phenomenon. Barring this tiny but frustrating quirk, Nextcloud is working very well for us.

The all-things-WebDAV endpoint is https://myserver.com/remote.php/dav/.... My current deploy sees WebDAV traffic to this exact endpoint from three sources: the Nextcloud web portal itself (e.g. https://myserver.com/apps/contacts), Thunderbird, Roundcube, and an Android Phone.

When a request goes out from inside the Nextcloud portal, it contains the HTTP header field requesttoken: ... and the round trip takes 100ms.

When a request goes out from Thunderbird or Roundcube, it contains the HTTP header field Authorization: Basic ... and the round trip takes 600-800ms.

I haven’t dug into Android yet to see what the HTTP message looks.

600-800ms is a lot for a mundane request and while it doesn’t make WebDAV usage unbearable, it’s noticeably slow. My theory here is that because those WebDAV messages bearing the Authorization Basic header field contain a username and password, the entire authentication flow has to run for each and every single one of those messages. Since I’m using LDAP to manage users on this deploy, these messages are suffering from the combined latency of proxying the credentials to LDAP and awaiting authentication on the LDAP server itself.

All that said:

1. Is this theory correct?
2. If it isn’t, what are other possible offenders?
3. If it is, how can I make external clients not use the Authorization Basic header field? Shouldn’t there be support for Authorization Bearer?

[SysKeeper]

It is recommended that you don’t use username/password directly in clients, but instead create an app token and use that one as login from the apps. IIRC, this should help with the issue you’re seeing

[nzeid]

Switched the aforementioned devices to use the “app password” generated by Nextcloud in the “Devices & sessions” page. This brought the end-to-end latency down to ~150ms, which is now only slightly higher than what I see within the Nextcloud contacts page. This seems to confirm my theory.