I'm currently using Amazon Route53 to manage our DNS and have run into a snag.

Our static content is served from AWS S3, however, S3 doesn't support HTTPS with CNAME's. To get around Cross Domain issues, our static content is served via CNAME.

So, I'd like to continue to serve HTTP content via S3, and serve our HTTPS content through our own webserver.

However I'm not sure how I can route HTTP traffic to one domain (s3), and route HTTPS to another domain (a webserver).

  • It isn't clear to me what this is? If you want to server HTTPS, setup a server that supports HTTPS. – Zoredache Apr 22 '13 at 21:03
  • I'd like http://mydomain.com to point to S3. I'd like https://mydomain.com to point to a machine that serves https. Cna I do this via DNS? If not, what is the best way (perf and cost wise) to do this. – Alan Apr 22 '13 at 21:25
  • Redirect https? – Matt Apr 22 '13 at 21:28
  • Which cross domain issues are you facing? If you're just serving content embedded into a HTML file, you can easily serve content from multiple domains (nothing required, just embed them). If you're loading them via AJAX, then there are alternate methods you can use besides a regular $.post() to get them. Most technologies have a method of enforcing cross-domain exceptions as well. – Mark Henderson Apr 22 '13 at 21:38
  • Thanks @MarkHenderson We're sending messages back to our server by way of iFrame's and postMessage(), and while we can look at other ways do crossdomain, it would be a fairly significant rewrite (especially when attempting to address our browser support matrix). If I could route the traffic upfront, that should (in theory) be a cheaper alternative. – Alan Apr 22 '13 at 21:44

DNS is only concerned with resolving hostnames to IP, and is not concerned with protocol or port numbers -- this means to directly answer your question; No: you cannot use it to route https://example.com to one IP and http://example.com to another.

There are a couple common ways around this:

  • Use a reverse proxy listening on both http:// and https://example.com, such as nginx. This proxy can look at the protocol and even request path, and route to other server(s) appropriately.
    • In addition to making your scenario possible, you also get other benefits: SSL offloading to reduce load on your app server, and the ability to run multiple app servers transparently for either redundancy or scale.
    • Downside: If all your servers are not on the same local network, this is pretty inefficient (and slow) as you're going across the internet twice.
  • Use separate subdomains, and have your servers send CORS headers. There are a ton of resources on how to do this so I won't get into it here.
    • Essentially, you'd have http://static.example.com and https://example.com. DNS would resolve static.example.com to S3, and example.com to your other app server.

If your app servers are separated by slow network connections (sounds like they are) then IMHO the only way to go is a DNS-based solution.

  • Thanks gregmac. The problem with the DNS based solution is that I'd prefer to have the customer install the script once, and not have to worry about knowing if they'll need SSL support or not. I think what I'll end up doing is going the first route, using nginx and varnish to serve both http and https content, and no longer use S3. – Alan Apr 22 '13 at 22:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.