Service discovery does not seem to take into account port number

[zeekoe]

Problem scope

• I'm sure that this is a DAVx⁵ problem.

App version

• I'm using the latest available DAVx⁵ version.

Android version and device/firmware type

Android

Steps to reproduce

1. Configure a nextcloud server to use a non-standard HTTPS port
2. Try auto-discovery with the base URL

Actual result

See that it does not work, but instead that the standard HTTP port (443) is being used

Expected result

The non-standard HTTPS port used for service discovery

Further info

I didn't check the logs yet on the most recent version, but it still doesn't work.
I always got it to work with something like /remote.php/principals/users/<username/something-i-forgot. Need to check that out, but I don't have access to my server logs here, trying to set up the new device.

[rfc2822]

I always got it to work with something like /remote.php/principals/users/<username/something-i-forgot.

You can probably look it up at https://www.davx5.com/tested-with/

The non-standard HTTPS port used for service discovery

Correct, currently we use the default HTTPS port for auto discovery to follow RFC 6764, which says

If an SRV record is not found, the client will need to prompt the user to enter the FQDN and port number information directly or use some other heuristic, for example, using the extracted "domain" as the FQDN and default HTTPS or HTTP port numbers. In this situation, clients MUST first attempt an HTTP connection with TLS.

We could however use the given port number, too.

• However that brings some problems. What if the user for instance enters http://example.com:80 – should we use port number 80 for HTTPS (and service detection should only be HTTPS)? Or only if the protocol is HTTPS?
• Also, what if users just paste in some wrong URL (including a wrong port number, but correct domain name), and the server is on the HTTPS port as to be expected?
• Is there a specific reason for your server not to be in port 443?
• Is setting SRV/TXT record an option for you? Then you can specify port 444 in the record and auto-detection will just detect it. This is my favorite option.

[zeekoe]

Thanks for your reply!
Hmm, clear reasons. Thanks also for the pointer; I got it working again for now.
The reason for not using the default port started around 2 years ago, when my logs were flooded with log4j exploit requests. Nothing happened as I didn't have a java web server exposed to the outside world, but this made it clear to me that my server was not hidden in a corner of the internet as I thought up to then, but somehow quite known.

For that reason, setting up a DNS record saying "hi all, the server really is here at this secret port" is not what I want. ;)

But then perhaps I'm one of very few. Your explanation makes it clear that temporarily opening up port 443 at service discovery time might also work.

One option could be to extend the service discovery to the provided port as well, in case port 443 gives timeouts?

As for port 80; I think it's not a problem these days to not support plain unsecured HTTP, now we all have easy access to HTTPS.

[user8446]

I too use a random high port with nextcloud and noticed this as well when setting it up. I actually overlooked it at first because my server address went off the screen.

Maybe a simple note in the "Login with Nextcloud" screen or in the nextcloud docs section?

[rfc2822]

What note would you add (exact text)? I belive I still don't understand the problem – the given port number should just work, especially with Login with Nextcloud?

[zeekoe]

Let me try to rephrase: the given port number, if Nextcloud runs only on that port number, does not work. Also not with "Login with Nextcloud". That is because the service discovery seems to use the default HTTPS port only, and not the given port number.

In other words: me, as well as user8446, expected the "Login with Nextcloud" to work when we provided the Nextcloud URL. Instead, it timed out. A note explaining this (or extending the service discovery to the given port) might help.

[rfc2822]

I cannot reproduce this.

1. I have set up a Nextcloud on https://my-server:444/nextcloud (not running on port 443).
2. DAVx⁵ "Login with Nextcloud", base URL my-server:444/nextcloud.
3. Works without problems, all collections detected & synced

Can you please provide steps to reproduce the problem?

[user8446]

To reproduce in my case:

1. Nexcloud app -> Sync calendar and contacts
2. On the DAVx5 "Login with Nextcloud" screen (see below), I simply clicked "Login" to continue
3. I received the timeout error
4. The populated server address is missing my port used (my-subdomain.my-domain.com is populated instead of my-subdomain.my-domain.com:####)
5. Also since the server address continues off of the screen, I missed that this was the issue when it timed out