
SNI and HTTP to HTTPS Redirection for CloudFront - jeffbarr
http://aws.typepad.com/aws/2014/03/server-name-indication-sni-and-http-redirection-for-amazon-cloudfront.html
======
kolev
Nice $600/month saving for me! I can't wait for ELB and CloudFront to
implement SPDY and WebSockets!

~~~
toomuchtodo
Might want to throw your +1 in this AWS thread:
[https://forums.aws.amazon.com/thread.jspa?messageID=353099](https://forums.aws.amazon.com/thread.jspa?messageID=353099)
[Add SPDY protocol support to ELBs]

~~~
kolev
I just did! Thanks!

~~~
toomuchtodo
Just got an update about activity in the thread :)

------
ryantownsend
This is excellent news - SNI very widely supported in browsers now, so there
is little excuse to avoid it.

Would be great to see SPDY/HTTP2 support so the overhead of serving many small
assets (i.e. typical website use) would be reduced.

~~~
mrweasel
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.

~~~
josteink
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.

~~~
mrweasel
>If their internets starts breaking, they might actually be motivated to
upgrade.

More likely: My customers take their business elsewhere.

------
toomuchtodo
Thanks Jeff, its appreciated.

Can we work on SPDY support for ELBs? That forum thread is getting pretty
heavy with +1s.

~~~
jeffbarr
I know that the team is aware of the need for SPDY and that it is on their
roadmap, but I'll ask them to reevaluate the priority.

~~~
toomuchtodo
Thank you! Its greatly appreciated. If there was a web app to send a beer your
way, I'd do so :) You guys have saved me countless ops hours.

------
aalbertson
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!

------
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](https://sni.domain.com) via SNI.

The main server would be at [https://ssl.domain.com](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](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](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?

