Clarify the string format of AnySocketAddress

wintercg / proposal-sockets-api

Proposal for an API for establishing TCP connections in Non-Browser JavaScript runtime environments

https://sockets-api.proposal.wintercg.org/

Other

46 stars 2 forks source link

Clarify the string format of AnySocketAddress #13

Open dom96 opened 9 months ago

dom96 commented 9 months ago

Only hostname:port should be supported.

mmastrac commented 9 months ago

One consideration -- there may be some precedent for using tcp:// prefixes in connection strings which may allow for additional embedder flexibility:

https://activemq.apache.org/uri-protocols

While TCP is going to be the protocol used in 99.99% of all cases, hostname:port may be too ambiguous to parse alongside URLs if they are ever going to be accepted (eg: numeric ports overlap with the terrible numeric-only representation of IPv4 addresses -- 12345 == 0.0.48.57).

jasnell commented 9 months ago

If we make it so that the address supports absolute URL strings or hostname:port (https://github.com/wintercg/proposal-sockets-api/issues/16#issuecomment-1739809475) then I think we cover this. Host implementations would be free to decide which URL schemes they support in this. At a minimum, tcp:// could be required along with the bare hostname:port.

A host could disambiguate the URL case by effectively allow-listing the set of URL protocol prefixes they support, e.g. if the runtime only supports tcp:// and http://, then 12345:80 wouldn't ever be ambiguous. If the 12345 cannot be interpreted as one of the allowed protocols or as an IP address/hostname, then it is rejected.

dom96 commented 8 months ago

Yeah, I'd say the port should be required for the protocol-less variant and that should resolve the ambiguity.

Shall we say the implementation needs to support:

tcp:// (where the port is required to be specified)
http:// and https:// (where the port can be omitted and is then set automatically to 80, 443 respectively)
protocol-less where both a hostname and port must be specified delimited by a :

And MAY also support other protocols.

If we agree I'll add this to the spec.

jasnell commented 8 months ago

I would say that we should support, at a minimum:

tcp:// where host and port are required
All "special schemes" defined by the URL spec for which a default port is defined (https://url.spec.whatwg.org/#special-scheme). These include: ftp (port 21), http (port 80), https (port 443), ws (port 80), and wss (port 443).
protocol-less, which is assumed to be equivalent to tcp://