One of my biggest frustration while running a multi-tenant system running NixOS (Which is great btw, every user can install stuff in their home without sudo) is that HTTP is bound to port 80. And beyond the whole privileged port jazz, there's another trouble here : only one program can listen on myip:80.
Ideally, HTTP would use SRV DNS records. For the uninitiated, those are records that contain both an IP and a port, so instead of having a "default port" of 80 (which is completely arbitrary), you get to define on what port that service is running. Then I could just assign each user of my multi-tenant system a range of ports (With 1000 port each, we could get 65 users. Maybe less due to ephemeral ports, but it's already more than what I need anyway).
There are other solutions, such as machines connected to IPv6 could get millions of IP address essentially for free. But IPv6 coverage is still spotty. And in my case, the system was running on a kimsufi box, which gives exactly one IPv6 address per machine. (And let me rant for a moment and say that this is really stupid, for multiple reasons such as ipv6 blacklist using blocks anyway).
I wonder if it's too late to get SRV records in, say, HTTP2. Or even in HTTP1 for that matter, as an amendment RFC. Because it would trully be awesome.
I'd say the original mistake was making the port number distinct from the address in TCP/IP. In that model the remote party implicitly cares whether two services are on the same physical machine or not. We have ways to work around that, but not without friction.
The advent of DNS created a new opportunity to come up with a unified address, but sadly the SRV record seems to have been invented too late (RFC 2782 is dated February 2000).
Of course there are good reasons for address/port split, not least that ports come from TCP and addresses from IP. But still, it shows how many pragmatic real world decisions have pragmatic real world consequences.
Oh yes. If we go back further and make IP 64-bit and specify that all endpoints should get a /40 to be assigned to up to 2^24 network endpoints per system and then left out the concept of ports entirely, we could have saved probably ten thousand human lifetimes of coding.
Ipv4 addresses are 32 bits and ports are 16, so the above would only have cost 16 bits.
It's hard to have that much foresight, but I would not be surprised if it was suggested and shot down.
A reverse proxy can kind of act as a nice hack around this by multiplexing off of the the Host header (which is unencrypted even with HTTPS due to the way that the SSL handshake is done).
The HTTPS Host header is not unencrypted. You are talking about SNI which is an extension to TLS that adds the hostname as part of the handshake. The Host header is still encrypted when using SNI.
Having the host OS run what's essentially a virtualhost proxy seems like the most elegant, viable-path forward. You'd need a protocol for the guest to announce what site(s) it's planning on hosting, and then bridge those out the the host.
Keeping multiple guests from claiming the same name would be useful.
Better: shift the whole public layer out to a distributed caching service.
Tools such as IPFS offer another possible answer, where the RaPi boxen could be considered simple origin servers.
Yeah, but that's not the point. If I have my friend who wants to host blog1.com, and I want to host blog2.com on the same machine, we can't do it without some coordination. We'd probably need to have an Nginx server using VHost to redirect to my or his server. We can't use SO_REUSEPORT because if the request goes to the wrong server, it won't know how to react.
With SRV, we wouldn't have this problem. With each of us having IPv6, we wouldn't have it either.
Ideally, HTTP would use SRV DNS records. For the uninitiated, those are records that contain both an IP and a port, so instead of having a "default port" of 80 (which is completely arbitrary), you get to define on what port that service is running. Then I could just assign each user of my multi-tenant system a range of ports (With 1000 port each, we could get 65 users. Maybe less due to ephemeral ports, but it's already more than what I need anyway).
There are other solutions, such as machines connected to IPv6 could get millions of IP address essentially for free. But IPv6 coverage is still spotty. And in my case, the system was running on a kimsufi box, which gives exactly one IPv6 address per machine. (And let me rant for a moment and say that this is really stupid, for multiple reasons such as ipv6 blacklist using blocks anyway).
I wonder if it's too late to get SRV records in, say, HTTP2. Or even in HTTP1 for that matter, as an amendment RFC. Because it would trully be awesome.