client apps shall find subdirectory of nextcloud installation via service discovery (.well-known directory)

[vacy]

⚠️ Before posting ⚠️

• [X] This is a bug, not a question or an enhancement.
• [X] I've searched for similar issues and didn't find a duplicate.
• [X] I've written a clear and descriptive title for this issue, not just "Bug" or "Crash".
• [X] I agree to follow Nextcloud's Code of Conduct.

Steps to reproduce

1. I set up the 4 well-known uri's as described here: https://docs.nextcloud.com/server/latest/admin_manual/issues/general_troubleshooting.html#service-discovery-label
2. kde's kontact works to login with login to https://domain.tld
3. nextclouds client at least for android expects to add the subdirectory to the login, while 3rd party apps work with service discovery

Expected behaviour

i expect nextcloud to follow same service discovery as 3rd party apps do. Thatfor i would expect its a bug and just doesnt work while its supposed to

Actual behaviour

nextclouds android client (maybe all clients?) just fire the request to the domain for the /status.php uri and expect it to work. you'd need to add the subdirectory.

Android version

13

Device brand and model

google pixel 4a

Stock or custom OS?

Stock

Nextcloud android app version

3.29.0

Nextcloud server version

28.0.5

Using a reverse proxy?

No

Android logs

No response

Server error logs

[06/May/2024:11:41:17 +0200] "GET /status.php HTTP/1.1" 404 16 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.29.0"

Additional information

No response

[joshtrichards]

There essentially is service discovery for plain WebDAV already since you only need to enter https://example.com/ or https://example.com/nextcloud/ (rather than https://example.com/remote.php/dav/files/USERNAME/ orhttps://example.com/nextcloud/remote.php/dav/files/USERNAME/).

https://docs.nextcloud.com/server/latest/user_manual/en/files/access_webdav.html#official-nextcloud-desktop-and-mobile-clients

i expect nextcloud to follow same service discovery as 3rd party apps do. Thatfor i would expect its a bug and just doesnt work while its supposed to

Those apps are making CardDAV/CalDAV connections not straight WebDAV connections. They need special URLs with or without a subdirectory-style installation. So the current behavior is expected and not a bug.

I know of no standardized /.well-known/ URI we could even use to accomplish what you're talking about.

[vacy]

@joshtrichards thanks for your reply on this one :)

I didn't think of a violation of RFC standard, I am sorry about that. But I've had a quick read into RFC5785 and found section [1.1] and [5.1] to be helpful. 1.1 indicates this inquiry of mine would be covered by the purpose of well-known uris.

Though its stated in 3. you'd have to to be registered as an official URI. How to do that is outlined in 5.1. On the other hand [wikipedia] lists some known .well-known/uris and apple is listed with some... Now the catch is.. [IANA] does not know about them, seems like, apple didnt care about registration eventhough RFC is referring to MUST register.

Anyways.. registration is a path I would assume is feasible.

Looking at IANAs register [IANA] is also indicating that proprietary registrations are allowed as you'd see with matrix' registrations.

Do you think its feasible to go into that process of registering an well-known URI for this very service? I guess the login process for thousands of users would step up a bit in their experience.

That name could then end up in .well-known/nextcloud or also refering a canonical domain, similar how to android apps register their names e.g. .well-known/com.nextcloud.login

[1.1] https://datatracker.ietf.org/doc/html/rfc5785#section-1.1 [5.1] https://datatracker.ietf.org/doc/html/rfc5785#section-5.1 [IANA] https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml [wikipedia] https://en.wikipedia.org/wiki/Well-known_URI#List_of_well-known_URIs