[Chupachupski]

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.

[harshreality]

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.

[Chupachupski]

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.

CloudFront would serve static content from https://sni.domain.com via SNI.

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

Any suggestions?

[ceejayoz]

IE7/8 on XP is basically the entirety of the remaining user base without SNI support.

[mappu]

Android 2.x is what holds me back.

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.

[speleding]

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.

[imperalix]

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.