[pratyahava]

this is a nice idea, but idk why, in macos if i do `nc -l 127.0.0.1 gopher` and then try to open url "http://127.0.0.1:gopher/" - safari does not open it, no requests visible in the `nc` output.

also `curl -v http://127.0.0.1:gopher/` gives error message

  * URL rejected: Port number was not a decimal number between 0 and 65535
  * Closing connection
  curl: (3) URL rejected: Port number was not a decimal number between 0 and 65535

so the ports are named, it is nice, but in practice it does not make life easier.

[bandie91]

> http://...:gopher

is it http or gopher? :)

[pratyahava]

i chose gopher port just as an example. try with any other service name mapped to a port number from /etc/services and the result will be the same. the OP's goal was to use many http/https services, so we are talking about many http(s) services.

i just wanted to make the point that even if you have service names in /etc/services, it is not possible to use that names easily to host/access http(s) services.

[skydhash]

The names are the kind of servers that listen on those ports (by default) like ssh, telnet, http, and smtp. They are not subdomains or for URI parsing.

[pratyahava]

URI contains ":port" tho, but practically it is only digital number.

the OP made a tool which helps them to avoid using port numbers. people commented in a way that looked like laughing at him, like he reinvented the wheel, and talking about /etc/services. well ok, i decided to try using /etc/services for the purpose of using names instead of port numbers.

would it be possible to add "myapp 60001/tcp" to /etc/services and then work with "http://localhost:myapp"? NO! browsers do not translate these names into port numbers. netcat does. curl does not.

so probably the OP's solution is not that questionable and really solved their need? and "good old friend /etc/services" is not useful for this? i dont know what it is useful for as running services on non-standard ports actually helps with hiding from security/vuln scanners and is practiced widely.

[skydhash]

Maybe the joke has gotten too far, but the point that most people have been trying to say is that the issue that the OP is trying to solve has been solved for years. It's called a reverse proxy. Doing the configuration automatically like OP does does not alter the fact that it is a reverse proxy. `/etc/services` serve a different purpose.

Also URL parsing is a completely different matter. Browsers are primarily an HTTP(s) client. If you do not mention the ":port", it will try to connect to 80 (HTTP) or HTTPS (443). Because that the default ports for a web server. Other services have different port. So if your URL has the ftp scheme, the default port would be 21.

[tharkun__]

I know you're trying to be funny but ... technically it's 100% clear: You should talk HTTP, because that's the URL scheme here. The port makes no difference. You just happened to use a port by name. For all we know I run my HTTP server on some NFS related port so all the script kiddies try all the wrong exploits on it or something ;)

[jasonlotito]

Well, the entire context of this is https so anything else is immaterial. The only reason it would be gopher is if you didn't read the post or don't understand the basics of https.

[laurencerowe]

This is not possible since it is ambiguous. It is impossible to parse “http://127.0.0.1:gopher/“ since that would be valid as either “scheme://user:host/“ or “scheme://host:portname/“.

“http://127.0.0.1:70/“ is unambiguous since 70 is not a valid host.

[mrhottakes]

Sounds like you need an AI agent that can determine whether http and gopher are the same protocol

[pratyahava]

if you configure sshd to listen on port 443, does it become an https server? i was just trying to demondtrate: pick any port from /etc/services and try to use the name instead of port number. no, it does not work well when trying to use for local-hosting http(s) services. so to address the irony and sarcasm of the messages i was replying to:

  zdw: It's like someone should make a file... maybe in /etc ... and put short names for services in it... maybe it could be called /etc/services...

  tolciho: And then they might code up some sort of service lookup tool thingy to use on the train wreck that is the modern web.
  $ getent services gopher
  gopher               70/tcp

[tolciho]

Many clients also do not support getservent(3) or portmap or DNS SRV records or NIS or LDAP or ActiveDirectory so one might wonder why there are so many half-baked, failed, or overy complicated attempts at solving whatever the problem is here even before "AI has entered the chat".

[Tepix]

As bandie pointed out, you‘re explicitly making a http request. Duh.

nc is for generic connections and handles it well.

[pratyahava]

i know, but the OP's goal was to host/access http(s) services with names and avoid port numbers, and gopher service name was chosen by me as an example. my point was that /etc/services cannot be used for the OP's need.

if you host an http(s) service on port 11111 you can reach it with url http://127.1:11111, but url http://127.1:vce/ would not work in most software.

  $ grep 11111 /etc/services
  vce  11111/udp   # Viral Computing Environment (VCE)
  vce  11111/tcp   # Viral Computing Environment (VCE)

[mrhottakes]

If I curl my phone number it doesn't connect, that's strange

[pratyahava]

can you please explain what you mean by this? because technically i do not see any similarity in this "analogy".

[Tepix]

But if you want to contact vce, why use „http“? It‘s not going to work

[SAI_Peregrinus]

Try http://127.0.0.1:hkp instead of http://127.0.0.1:11371 for an OpenPGP HTTP keyserver. HTTP will work, but using the service name won't. Does that make what they're trying to say clearer?

[pratyahava]

the question was "can we use port names from /etc/services instead of port numbers?"

how about "ssh://[e-mail]:https/golang/go.git" instead of "ssh://[e-mail]:443/golang/go.git"? does not work, hmm.