Calling `port()` with a default port returns None unexpectedly

[TomPridham]

• Note that this crate implements the URL Standard not RFC 1738 or RFC 3986

Describe the bug
related to #28
This was an issue way back in 2014, but doesn't seem like it was ever really addressed.
I would expect calling port() on http://example.com to return 80. It is really confusing that it would return a None. It's even worse when you set the port explicitly http://example.com:80 and it still seems like it isn't working correctly because it still returns None.

I could update the docs to have an example of the port being ignored, but it seems like it would just make more sense to have port() actually return the port and do what is suggested in this comment

[valenting]

I would think the docs are pretty clear on this issue.

https://docs.rs/url/2.5.2/url/struct.Url.html#method.port

You want port_or_known_default. Do you feel like the docs are missing something?

Note that changing the behaviour of port is a breaking change, and not something we'd consider doing at the moment.

[link2xt]

Can you add another API that returns Some(443) for "https://example.com:443" and None for https://example.com?

I need to distinguish between these cases because when user scans a QR code, in the first case this is likely an HTTPS proxy URL and in the second case it is likely a normal URL that I want to offer to open in a browser:
chatmail/core#5980

As a workaround I will now try to look at .authority() and see if it ends in :443 when scheme is https (and :80 for http), but this seems to be really hacky.
EDIT: does not work as default port is also removed from .authority().

[link2xt]

Another way to fix this would be to add an option to ParseOption to disable default ports.

[link2xt]

As a workaround I now replace http:// or https:// with foobarbaz:// before parsing. This disables all sort of normalization for ports, also does not add / path when the path originally does not exist.

[TomPridham]

Sorry about the really late reply. I think when I was looking originally, the examples in my editor got truncated like this

It is called out in the docs, but that sentence didn't make sense to me initially and the first sentence makes it seem like it would always return the port if it's there. I think we were also expecting the behavior @link2xt was asking for, where if there is a port set at all it would be Some, if not set it would be None
It would make most sense to me if that exception for default ports was removed, but I understand not wanting to ship a breaking change like that

[link2xt]

In my case I want to know if the port is there or not, i.e. distinguish between https://example.org:443 and https://example.org. When scanned from the QR code the first one is treated as a proxy (offering user to setup HTTPS CONNECT proxy) and in the second one it is likely just a website and we offer to open a browser.

[emilk]

We just ran into this problem too. In particular, we want to use the port the user specified, buy only if it is specified, otherwise default to our own choice of port (e.g. 12345). That is: foo:42 should result in port 42, but foo should result in port 12345. Currently there is no way to accomplish this using url, afaict

[link2xt]

@emilk We replace scheme before parsing as a workaround:
https://github.com/chatmail/core/blob/ab47d6f6119723005866c6ffe6f49c6aea1e328f/src/qr.rs#L324-L337

[wpdevelopment11]

@valenting

I think this issues can be closed actually.

If you don't like that port returns None for the default ports, you can use port_or_known_default.

If you want to distinguish between the https://example.com:443 and https://example.com (explicitly and implicitly specified port) case then it's a different issue, which is discussed here.

Because now this issue is hijacked by people who want the second thing. This is not what the original issue is about.

[Manishearth]

Yeah that makes sense.

Given that this is attempting to follow the standard, which doesn't distinguish, I think it's unlikely we'll add additional tracking for this. Not strongly opposed to it, but it seems unlikely. Worth looking at what it might look like as an implementation.