Hacker News Reader

Comment by extheat | Hacker News Reader

At first this seemed surprising. Until you think about it more in-depth, port 80 is very much a privileged port that most applications don’t have permission to host on. Additionally, servers typically can have multiple HTTP services running in parallel and since you obviously can’t run two separate servers on the same port, it makes sense to avoid this conflict by running services on specialized ports. I don’t believe the intention for most hosts is to keep the service secret by running it on a non standard port.

View on HN

>Additionally, servers typically can have multiple HTTP services running in parallel and since you obviously can’t run two separate servers on the same port,

Actually you can bind to the same port on different addresses. For loopback you have the entirety of 127.x.x.x

Or it's just that the let's encrypt topic and https per Default and getting down ranked on Google when using http makes 80 just a really really bad option.

My company blocks port 80 globally and I only learned about it through an internal service I configures. Which shows how little normal day to day traffic is http and port 80.

Also when the https topic came up, quite a lot of big hosters (shops, crms, website hosting) started to give you https which was NOT normal before.

> port 80 is very much a privileged port that most applications don’t have permission to host on

setcap 'cap_net_bind_service=+ep' /path/to/program

But yes, until like the last 10 years or so. Also while it's possible nobody knows this information.

More interestingly, port 7475 (which is the most popular port besides 80 and 443) is set top boxes watching TV.

Windows has long had the capability to share TCP ports between applications: https://learn.microsoft.com/en-us/dotnet/framework/wcf/featu...

You can use reverse-proxying and have several servers behind a single front one.

Reverse proxies usually require configuration changes to work. Plus they are single points of failure. Server Name Indication (SNI) is a fairly recent development as well - any apps written before that was widespread, or designed in that way, will have a unique web server for every HTTP based service that has its own separately managed certificate.

Reverse proxying is less common in wild IoT devices, network appliances, and certain kinds of enterprise/line-of-business apps... Surprisingly Microsoft IIS seems to be an exception in that area

The initial RFC for SNI is 20 years old this year. It's been in OpenSSL for 19 years.

Plus - Unless the client is outside of a browser context, you can drop an nginx instance in front of the service without the service having any clue.

Throw a load balancer in front and it's probably much more robust than a single service.

Honestly - reverse proxy support is one of the more magical parts of http.

You're assuming that people are going to use the smartest "best practice" way to do things from your perspective. This is not often what actually happens. It takes forever for people to realize that they should re-architect things to work like this, and that there are benefits to doing so. If you're able to have this happen in a production environment, with no conflicts with other things or other people around you, count yourself lucky...

Reply on news.ycombinator.com