Option to keep default port

[lutovich]

Currently parsed URL does not contain port when its value is the default for the specified protocol:

parse("http://localhost:80").port === ''
parse("https://localhost:443").port === ''

It would be great to have an option/parameter to keep the port number even if it is the default for the protocol.

This would be useful when default port is defined by the environment/application requirements and is different from the standard. For example, an application might want to interpret http://localhost as http://localhost:8080 and not http://localhost:80. Only http://localhost:80 will be interpreted as http://localhost:80. Right now after URL has been parsed there is no way to know if port was not specified or default port was specified.

I'd be glad to provide a PR for this. Not sure if it fine to just add a 4th parameter to the URL function.

P.S. thanks for this library, it is really convenient and simple to use!

[3rd-Eden]

Yes, no, maybe.

The current behavior is modeling the way node and browser parse URL's. We currently already support 3 different URL arguments, adding a 4th argument would really over bloat it given how small this specific use case would be. If were to decide to change to URL(str, options) pattern and break the API, I could see this something simple to add.

I guess we could change the API to str, options, not sure how useful the current API is.

Thoughts?

[lpinca]

I'm not very happy with adding an additional parameter either as I think this is an edge case. In some cases we can't be consistent with both legacy and WHATWG URL parsers because they have different behaviours.

[lutovich]

I definitely agree that adding 4th parameter is not pretty. URL(str, options) would be great but it's an incompatible API change and will require a major release. Do not know if it's acceptable for the library to make such a change.

[lutovich]

Out of curiosity, why is hiding of the default port needed? Is it to be compatible with other browser/node URL parsers? Imho it is a bit of a surprising behavior, especially for parsing.

[lpinca]

Yes, see https://url.spec.whatwg.org/#port-state.

[Christilut]

Came across this issue trying to find out why url-parse wouldn't parse my port number. Odd behavior if you ask me. Didn't see this in the docs either.

[3rd-Eden]

I'm more than happy to merge any documentation updates ;-)

[julien-f]

Hi,

Came across this issue, due to cURL using 1080 as default port for HTTP proxy.

An alternative solution would be to provide a new getter always returning the port, even if it's the one by default.

[iaktern]

Yes, see https://url.spec.whatwg.org/#port-state.

Hi, I assume you refer to this sentence:

3. Set url’s port to null, if port is url’s scheme’s default port, and to port otherwise.

It would actually help, if port is really set to JS null :) Then we can differentiate if url-parse removed the port or that it was intentionally not set in the input:

new Url('https://github.com/foo/bar') => { port: '', ... }
new Url('https://github.com:80/foo/bar') => { port: null, ... }