| 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? |