Hacker News Reader

Comment by acabal | Hacker News Reader

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 :)

View on HN

Serving multiple HTTPS sites is a piece of cake with nginx. What does your stack consist of?

You can get an extra IP for $1/month to solve the SSL problem (or alternatively look at something like Cloudflare).

Which, unfortunately would cost another $20 a month (+ $5 a month extra for each additional site with SSL).

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?

SNI: http://www.digicert.com/ssl-support/apache-multiple-ssl-cert...

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.

Heroku is able to provide as many free low use dynos as you want and that's a managed system with presumably more support cost.

>What would you have a webserver do differently?

How about not revert to a "default"? Just serve a redirect to the HTTP version if a HTTPS is not available for that vhost.

Sounds like the problem is with Apache then (I haven't used it in ages). As someone else suggested, have you thought about using nginx?

Reply on news.ycombinator.com