4 ms·

Add SRV lookups to the HTTP standard. There's a tremendous amount of complexity and cost attached to the fact that browsers look up the IP address of the hostn

by cwp 9y ago

Add SRV lookups to the HTTP standard. There's a tremendous amount of complexity and cost attached to the fact that browsers look up the IP address of the hostname and then connect to port 80. First, it's true that you can specify another port in the URL, but nobody does that because it's ugly and hard to remember. If you want to be able to send people to your website, you need to be able to tell people what the url is - "Just go to example.com". The minute you start saying "example.com colon, eight zero eight zero" you're screwed. With a SRV record in DNS, example.com could map to an arbitrary IP address and port, which would give us much more flexibility in deploying web sites. If you want a bare http://example.com http://example.com to work, you need to create an apex record for the domain. That can't be a CNAME that maps to another hostname, it has to be an A record that maps to an IP address. This means you can't put multiple websites on a single server with a single IP address, you have to have an IP address for each site. IPv4 addresses are already scarce, this just makes it worse. Also, port 80 is a privileged port in unix (which does the lion's share of web hosting). That means you have to run web servers as root. That, in turn, defeats the unix security model, and requires hosting providers to either lock down their servers and give limited access to users (cPanel anyone?) or give customers root access to virtualized operating systems, which imposes a tremendous amount of overhead. Virtual operating systems also impose a bunch of complexity at the networking level, with a pool of IP addresses get dynamically assigned to VMs as they come and go, DNS changes (with all the TTL issues that go along with that), switch configuration etc. These problems are all solvable and indeed solved, by really clever modern technology. The point is that it's all unnecessary. If browsers did SRV lookups, we could still be hosting like it's 1999, and putting all the tremendous progress we've made in the last 20 years into making it cheaper, faster, easier and more secure to build and run a web site. People that support the "open web" as opposed to "just make a Facebook page" should advocate for SRV support in HTTP. This doesn't actually have to be "forced" on users of the web - it'd have to be forced on browser implementors, hosting providers and web site operators. If the transition was handled well, users wouldn't even notice.

harryh 9y ago
This means you can't put multiple websites on a single server with a single IP address Huh? This isn't true. A webserver can just look at the host header in a HTTP request and return a response for the appropriate domain.
tptacek 9y ago
There's two issues with this: first, it's not necessary, and second, it won't really work. The first: it's true that only one (privileged) process can bind port 80 on a host. But that process can simply do what most front-end webservers do now, and reverse proxy to any number of other local hosts. IP addresses can be demultiplexed through the Host header, the way they have been for decades. That makes this a systems design problem, and not something that needs to be exposed in the standards. Second, even if you could transparently run websites on port 9999, that wouldn't change the fact that a good number of networks filter everything but ports 80 and 443. Universal network accessibility would still put ports 80/443 at a premium.
MichaelGG 9y ago
You can run many sites on the same IP and port. TLS and HTTP both indicate the host name. (And for most installs, non port 80/443 might be nonstarter due to firewalls.) Apex CNAMEs can be worked around in the server software - just dynamically resolve it into an IP. Cloudflare does this, for instance.
tadeegan 9y ago
nginx makes it very easy to sever multiple websites on a single ip.
tinus_hn 9y ago
This doesn't make any sense at all. CNAMEs don't help with running multiple sites on a single IP address, it's just a convenience in the DNS. More like a symlink really, it means 'when you're looking for X try Y instead'. If you want to run a web server on port 80 without the server having root access there's many ways to do that, the firewall can rewrite the packets so they go to a different port, you can give the web server the right to open port 80 without root privileges, you can proxy the requests etc.
cwp 9y ago
Lots of people are pointing out that with the Host header one web server can handle multiple domains. Yes, that's true. It's be useful in cases where you have one organization that hosts multiple domains. Then you just configure your server to handle this domain this way, and that domain that way, etc. But it doesn't help the cases where you want to host multiple, unrelated websites on one server. Let's say Acme Widgets has a static site that just serves files off the filesystem, but they've got a bunch of rewrite rules to handle legacy urls. Umbrella corp wants to run a node backend. To get that to work, you need to agree on a server that will handle the requests. Everybody needs to be able to configure it to their liking, which leads quickly to the cPanel scenario I mentioned above. Or, hey, we can automatically configure the shared server as a proxy and let everybody run their own servers on non-privileged ports! That works, but it introduces unnecessary overhead in terms of memory, CPU, SPOF, latency, configuration etc. It would be better to just have the browser connect directly to those unprivileged ports! tptacek brings up the good point that lots of networks block connections on ports other than 80 and 443. That's true, but it's because of the fact that HTTP essentially has to use those ports. If the web started working on other ports, that would change. Slowly, yes. Port 80 would have a special status for a long time. But if the standards did support other ports, network administrators would have a hard time answering "Why can't I connect to acme.com?" with anything other than "oops, let me fix that". This would be a way easier transition than say, switching to IPv6. Finally, I'll reiterate that none of these problems are insurmountable. The web exists because we've found ways to work around them. A lot of use make a living doing just that. But that doesn't mean this is the best way of doing things, or that the work-arounds have no cost.

by cwp 9y ago

harryh 9y ago

This means you can't put multiple websites on a single server with a single IP address Huh? This isn't true. A webserver can just look at the host header in a HTTP request and return a response for the appropriate domain.

tptacek 9y ago

There's two issues with this: first, it's not necessary, and second, it won't really work. The first: it's true that only one (privileged) process can bind port 80 on a host. But that process can simply do what most front-end webservers do now, and reverse proxy to any number of other local hosts. IP addresses can be demultiplexed through the Host header, the way they have been for decades. That makes this a systems design problem, and not something that needs to be exposed in the standards. Second, even if you could transparently run websites on port 9999, that wouldn't change the fact that a good number of networks filter everything but ports 80 and 443. Universal network accessibility would still put ports 80/443 at a premium.

MichaelGG 9y ago

You can run many sites on the same IP and port. TLS and HTTP both indicate the host name. (And for most installs, non port 80/443 might be nonstarter due to firewalls.) Apex CNAMEs can be worked around in the server software - just dynamically resolve it into an IP. Cloudflare does this, for instance.

tadeegan 9y ago

nginx makes it very easy to sever multiple websites on a single ip.

tinus_hn 9y ago

This doesn't make any sense at all. CNAMEs don't help with running multiple sites on a single IP address, it's just a convenience in the DNS. More like a symlink really, it means 'when you're looking for X try Y instead'. If you want to run a web server on port 80 without the server having root access there's many ways to do that, the firewall can rewrite the packets so they go to a different port, you can give the web server the right to open port 80 without root privileges, you can proxy the requests etc.

cwp 9y ago

Lots of people are pointing out that with the Host header one web server can handle multiple domains. Yes, that's true. It's be useful in cases where you have one organization that hosts multiple domains. Then you just configure your server to handle this domain this way, and that domain that way, etc. But it doesn't help the cases where you want to host multiple, unrelated websites on one server. Let's say Acme Widgets has a static site that just serves files off the filesystem, but they've got a bunch of rewrite rules to handle legacy urls. Umbrella corp wants to run a node backend. To get that to work, you need to agree on a server that will handle the requests. Everybody needs to be able to configure it to their liking, which leads quickly to the cPanel scenario I mentioned above. Or, hey, we can automatically configure the shared server as a proxy and let everybody run their own servers on non-privileged ports! That works, but it introduces unnecessary overhead in terms of memory, CPU, SPOF, latency, configuration etc. It would be better to just have the browser connect directly to those unprivileged ports! tptacek brings up the good point that lots of networks block connections on ports other than 80 and 443. That's true, but it's because of the fact that HTTP essentially has to use those ports. If the web started working on other ports, that would change. Slowly, yes. Port 80 would have a special status for a long time. But if the standards did support other ports, network administrators would have a hard time answering "Why can't I connect to acme.com?" with anything other than "oops, let me fix that". This would be a way easier transition than say, switching to IPv6. Finally, I'll reiterate that none of these problems are insurmountable. The web exists because we've found ways to work around them. A lot of use make a living doing just that. But that doesn't mean this is the best way of doing things, or that the work-arounds have no cost.