A theory that I think is worth exploring, I try to describe in the following words:
In the case of NextCloud, it is often also about nginx. When Joplin connects to a Nextcloud, Joplin uses a WebDAV stack. In this combination, there was already a problem that was solved with a workaround in Joplin (*)
After restarting Android - Joplin / after a reboot of Android, this collaboration works.
After switching from one Joplin profile to another Joplin profile, this collaboration does not work.
Why is that?
Could it be that when switching from one Joplin profile to another, not all variables that are sent to the server by the WebDAV stack are properly reset?
Is it possible that when changing profiles, an existing WebDAV connection is not properly terminated and the Nextcloud server therefore implicitly assumes that the next data still refers to the other profile?
Is there a way to ensure that the WebDAV stack is reliably reset to the same clean state it would be in after a reboot of Android, even when switching profiles, using a command or procedure in the Joplin code of the Android app?
(*) I would like to mention the following sources of my research in this context:
https://trac.nginx.org/nginx/ticket/1966
**Description]**
Some WebDAV clients that create collections do that without including the trailing slash. The logs offer no further explanation, and to a casual user the 409 error is confusing (as it indicates that the parent collection is absent).
RFC4918 recommends them to have a trailing slash, but given that several applications don't send a trailing slash, it stands to reason that it's common for servers to accept it. Section 5.2 even gives concrete guidance that in such a case, the server should accept and send a Content-Location header ("There is a standing convention").
Example clients that don't are webdav-js (https://github.com/dom111/webdav-js) and Stratospherix FileBrowser for Business; **some examples are around for other clients that employ workarounds** (eg. https://github.com/laurent22/**joplin**/issues/523).
and
laurent22 commented Jun 14, 2018 in GitHub
@ bradmcl, your fix should be part of the latest releases (Desktop and Android) so I guess we can close this issue?
Addendum 4 August 2024:
Meanwhile, it is suspected that the problem is related to the use of cookies in the WebDAV API.
Joplin itself does not use or set any cookies.
On Android, Joplin uses okhttp - and okhttp probably sets cookies itself, which leads to this problem when switching from one Joplin profile to another.
There might be a workaround by having Joplin send a “delete cookies” command before each request ( please excuse my amateurish wording ).
It might help the Joplin experts if we understood exactly what NextCloud does with the cookies in their WebDAV API.
Can someone provide us with such a description?