# Very high latency on Card/Cal/WebDAV due to HTTP "Authorization Basic" **URL:** \ **Category:** ℹ️ Support\ **Tags:** caldav, nc29, android, carddav, ldap, webdav, aio\ **Created:** [August 5, 2024, 5:26am UTC](https://help.nextcloud.com/t/very-high-latency-on-card-cal-webdav-due-to-http-authorization-basic/200107 "2024-08-05T05:26:19Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![nzeid](https://help.nextcloud.com/letter_avatar/nzeid/32/5_5575768a8748004e209b776fc1b2916d.png) [@nzeid](https://help.nextcloud.com/u/nzeid)\ **Post date:** [August 5, 2024, 5:26am UTC](https://help.nextcloud.com/t/very-high-latency-on-card-cal-webdav-due-to-http-authorization-basic/200107/1 "2024-08-05T05:26:19Z")
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? ---
**Author:** ![SysKeeper](https://help.nextcloud.com/letter_avatar/syskeeper/32/5_5575768a8748004e209b776fc1b2916d.png) [@SysKeeper](https://help.nextcloud.com/u/SysKeeper)\ **Post date:** [August 5, 2024, 5:28am UTC](https://help.nextcloud.com/t/very-high-latency-on-card-cal-webdav-due-to-http-authorization-basic/200107/2 "2024-08-05T05:28:32Z")
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 ---
**Author:** ![nzeid](https://help.nextcloud.com/letter_avatar/nzeid/32/5_5575768a8748004e209b776fc1b2916d.png) [@nzeid](https://help.nextcloud.com/u/nzeid)\ **Post date:** [August 8, 2024, 7:07am UTC](https://help.nextcloud.com/t/very-high-latency-on-card-cal-webdav-due-to-http-authorization-basic/200107/3 "2024-08-08T07:07:17Z")
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. ---
**Author:** ![system](https://help.nextcloud.com/user_avatar/help.nextcloud.com/system/32/29333_2.png) [@system](https://help.nextcloud.com/u/system)\ **Post date:** [August 16, 2024, 7:08am UTC](https://help.nextcloud.com/t/very-high-latency-on-card-cal-webdav-due-to-http-authorization-basic/200107/4 "2024-08-16T07:08:11Z")
This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.