Out of Range Port Numbers

[gflohr]

In URI 1.76 you can pass port numbers greater than 65535 without error:

$ perl -MURI -e "CORE::say URI->new('https://xyz:65536')->canonical->port"
65536

[karenetheridge]

Is there a specific RFC that limits the range? I would think that this range might go higher in the future, or be left open.

[gflohr]

Sure: https://tools.ietf.org/html/rfc793#section-3.1

[gflohr]

@karenetheridge This limit is hardcoded into every operating system with internet support, into zillions of pieces of hardware, into the browser you are reading this message with (try new URL('http://localhost:65536/') in the javascript console). It's not an arbitrary limit, it is a hard limit. You cannot just change it. It would be IPv7.

[simbabque]

The RFC you've posted is for TCP, not IP. From a URI point of view we don't know what protocol we're speaking though. Depending on the scheme, it might not be TCP or UDP (which both are limited to 65335). With http(s) we are probably quite sure that it's always going to be TCP, so this request is not completely unreasonable I believe.

On the other hand, there could be a lot of code that for testing purposes depends on this to work, and we'd be breaking that.

[gflohr]

Maybe it makes sense to limit the scope of the ticket to the http(s) scheme. The relevant specification is then RFC2616 which specifies in section 1.4:

HTTP communication usually takes place over TCP/IP connections. The
default port is TCP 80 [19], but other ports can be used. This does
not preclude HTTP from being implemented on top of any other protocol
on the Internet, or on other networks. HTTP only presumes a reliable
transport; any protocol that provides such guarantees can be used;
the mapping of the HTTP/1.1 request and response structures onto the
transport data units of the protocol in question is outside the scope
of this specification.

So theoretically, it would be possible to define URLs with the http scheme that have other semantics for the port, as long as it is a sequence of decimal digits, and the port can default to 80.

But then there is a gap between that academic point of view and the use of URLs as a living standard as implemented by all browsers. And that gap limits the usefulness of the URI module because the module's notion of an http(s) URL significantly differs from that of all major browsers (see also #68 and #69).

I agree that from a strict - acually relaxed ;) - standard's point of view, every sequence of decimal digits must be accepted for the port.

But what about introducing a feature switch that activates the conventions and restrictions that real-world http software use? Or build that into the canonical() method, as an option?

Maybe this discussion would fit better into the context of #68 and #69. According to the standard, http://127.0.0.1:8080/ and http://0x7f.1:0008080/ are probably very different URIs/URLs. But every browser I have at hand treats them as identical locators, and it can be a subtle source of bugs or even security problems if that is not taken into account.