That's what I do now, but it's a pain to serve multiple HTTPS sites and an extra pain (practically impossible with default HTTPS in browsers nowadays) to serve mixed HTTP/HTTPS. I'd much prefer sandboxed Linodes for all my little projects, but if I bought a Linode at $20/month for each of them I'd be poor pretty fast :)
Not sure why you say that, why not just support SNI-based browsers (i.e., NOT IE) to allow multiple TLS connections? And what does the difficulty of mixed HTTP/HTTPS have to do with the server?
You don't even need SNI if all you want is some SSL goodness for a side project. Just make your web server listen to a different port for each HTTPS site. Most of your users won't care about the port as long as there's a padlock somewhere, and the ones who know better will probably know that any port is as good as port 443.
1st site: https://www.firstsite.com:12345/
2nd site: https://www.secondsite.com:24328/
3nd site: https://www.thirdsite.com:37712/
etc.
You can have thousands of HTTPS websites on a single IP address while fully supporting every browser.
In Apache, one server can serve both HTTP and HTTPS (and multiple HTTPS with SNI). The problem occurs when you have both on the server with name-based virtual hosts and you request the HTTPS version of the HTTP site. If Apache can't find an HTTPS virtual host for the requested domain (because it doesn't exist, the site we're asking for only has an HTTP version), it will default to serving the first HTTPS site it finds instead. This means your domain will serve the wrong site and probably show an SSL warning to boot because the domains don't match.
Normally this isn't a problem, except that some browsers nowadays default to requesting the HTTPS version first. That means if you're serving an HTTP site and an unrelated HTTPS site, and a user accesses the HTTP site via an HTTPS connection, there's a good chance you'll end up serving the unrelated HTTPS site plus an SSL warning instead, because that's how Apache does things.
The problem is that you have not enabled a ssl version of that vhost.
How is that Apache HTTPD's problem? Nginx would do the same thing. When you don't define a ssl version of site.com for ip:443, you get whatever the default cert/vhost is for that ip:443. What would you have a webserver do differently?
I didn't say it was Apache's problem. For various reasons one project does not have HTTPS at all, and I understand how the web server handles things and the reasons why. My point was that a cheaper option from Linode would let me spin up a new VPS to host that small side project, instead of cramming it on a server that also hosts HTTPS; but $20/month for a not-for-profit side project just to edge around new browser defaults is steep for some of us.
Sure there are other options but I'd rather not have accounts all over the place, and I like Linode.
Sure there are other options but I'd rather not have accounts all over the place, and I like Linode.
Linode's problem with $10 accounts is not with customers like you who are paying them decent money otherwise - it's with customers who would sign up for $10, break things and expect $50 a month worth of support on an ongoing basis.
Most customers looking for a cheap VPS (to learn on, to experiment etc) are not going to be profitable unless you provide virtually no support, so by slicing off that part of the market they can offer a uniform level of service without compromising their profitability.
