How would you imagine WebSockets working as part of a CDN? We are in the process of developing something like this for Fanout.io and could use some input. :)
Sadly support for SNI isn't supported widely enough that you can actually use it, unless you control the clients.
You really need Internet Explorer to support SNI on Windows XP before you can use it. We would lose maybe $50- 100.000 in turnover per month by relying on SNI support, rather than just having multiple IP for each domain.
If a browser doesn't support SNI, it doesn't prevent them from accessing the site. It just means the wrong cert is returned, so they get a cert warning. Depending on the type of your site and type of users, this may or may not be a problem.
Windows XP is completely and utterly deprecated as of next month. For any future deployment and new development it should not even be on your consideration-matrix.
It's dead, Jim.
Let's just let it die already, instead of sowing cushions under XP-users arms. If their internets starts breaking, they might actually be motivated to upgrade.
This is EPIC news! We were just beginning to plan our rolling our own SNI infrastructure to replace Cloudfront due to the previous limitation and cost prohibitiveness of the dedicated IP model. Excited to test this out and see what happens!
Does anyone know an elegant way to sniff browser support for SNI?
Using JS to load an element from the SNI domain and then rewriting URLs if the response is too slow would probably work but surely there are better methods.
What do you do for clients that don't support SNI? What would graceful degradation be in your scenario?
Would you not use SSL (rewriting https to http)? If ssl is so unimportant for your purposes that IE8 and Android 2.3 clients don't need it, it would be much easier to not run SSL at all since you don't really need it if you're willing to have a non-trivial percentage of clients accessing the site insecurely.
Would you rewrite urls to a separate domain with its own IP? That would negate the reason for using SNI to begin with; if you'd use that host/ip for all ssl, you don't have to detect SNI support.
The third option, of course, is to refuse to support IE8 and Android 2.3. No detection needed.
TL;DR; SSL would be used for all traffic but non-SNI browsers would be served from the origin server or a caching server. URLs would be rewritten in JS in the browser on first hit.
Thanks for replying. Below are the details:
I work on an e-commerce project where 50% of bandwidth, a few hundred GB per month, is thumbnails and CSS. We currently serve this over HTTP on CloudFront - primarily for faster page rendering.
CloudFront and on-server caching are also helpful in handling traffic spikes from Reddit etc.
Total hosting cost is under $500/month so $600/month for CloudFront custom SSL hosting is steep in comparison.
My question was considering a scenario where we might switch to SSL all the time.
The main server would be at https://ssl.domain.com. This serve dynamic content to all visitors, static content to non-SNI browsers and is the CloudFront origin.
If non-SNI traffic was too much for the origin server we would set up a caching server (e.g. Nginx/Varnish on https://sslcache.domain.com) and rewrite non-SNI traffic there instead of the origin.
In the browser a javascript snippet would try to connect to https://sni.domain.com by loading a 1 pixel image then write the URLs in the DOM if a short timeout delay was exceeded and set a cookie for further requests by this browser. The cookie would then determine if the server delivered pages (usually from the cache) with SNI or non-SNI URLs for static content.
I think this would work and would see at least 90% of static resources served over SNI.
It would be nice if there was a more elegant way detect non-SNI browsers - such as a JS test for the existence of a particular browser property - rather than trying to load from CloudFront (seems a bit web 1.0ish).
Not specifically because i get a lot of web traffic from that, but i'm in trouble if someone clicks a link from their email client to a report on my SNI host.
Also, last weekend Linode removed the requirement to reboot when adding additional IPv4 addresses, which solves a hassle for me. So I might keep using many IPv4 addresses for a bit longer until Android 2.x dies off.
If I read the documentation correctly there is an important limitation that would prevent sending non-SNI browsers to another https URL: As soon as you associate a custom SSL certificate with a distribution then that distribution will no longer be available under the old SSL name (https://d111111abcdef8.cloudfront.net/...)
I'm not 100% sure about this but I conclude this from the description where they explain how to undo setting up custom SSL certificates and they warn that you need to create a new distribution.
You are correct. Once you set your distribution to SNI only and the distribution is in deployed status, clients that do not support SNI will not be able to access your distribution over https.
