2

We're looking to move our website/app assets to a CDN. The problem is, our CDN doesn't offer custom domain names with SSL. In other words, for SSL they offer https://1234.cdn.hostingcompany.com but not https://assets.mysite.com.

So this seems like a huge problem since I don't want to re-publish my app with their domain hard coded.

So I read somewhere about a method where you send people to https://assets.mysite.com then redirect to https://1234.cdn.hostingcompany.com.

Is there merit to that solution or would that completely defeat the purpose of the CDN.

5
  • 1
    Why don't you make their domain a configuration setting, so it can be quickly changed?
    – ceejayoz
    Oct 12, 2012 at 14:43
  • It is a configuration setting on both the website & app, but I have no control over the app once it's deployed in the app store.
    – bendytree
    Oct 12, 2012 at 15:15
  • 1
    If this is a phone app, perhaps it should check for a new configuration file from your server each time it opens... So if you need to change the configuration data you still can.
    – Chris S
    Oct 12, 2012 at 15:26
  • Thanks Chris - this is great advice. I'm really just trying to compare all the options. Dynamic configuration is a great workaround, but I'm trying to focus the discussion of the actual performance penalty of using a redirect. If there were no performance loss, then a redirect is the ultimate dynamic configuration since sources don't have to poll for changes.
    – bendytree
    Oct 12, 2012 at 15:49
  • The redirect is an ugly hack honestly... polling for a configuration change is going to take less bandwidth on your server than the redirect would, and would allow you to change other configuration aspects after the fact as well. This is tangential to your actual question, which is why it's a comment rather than an Answer.
    – Chris S
    Oct 12, 2012 at 16:47

2 Answers 2

2

You can setup your own server at https://assets.mysite.com (with a valid SSL certificate for that SN), which returns a 301 Redirect to https://whatever.cdn.com. This will work for anything the browser itself loads. If your webapp has JavaScript or something else (Flash, Silverlight, etc) it should still work, but you should test extensively.

The big disadvantage to this is that all requests for CDN content will hit your server first. The data transfer will be minimal, but the delay will be hundreds of milliseconds at the least. After they've been redirected once, their browser should remember the redirect and go to the CDN's actual URL without bugging your server in the future (browser caching will limit this effect).

If you're offloading content because it's a data-hog, this is still a decent way to accomplish what you want. If you're offloading content to get better response times, this will not accomplish that goal.

As Ceejayoz pointed out, you aught to make the CDN's URL a configuration variable for your application. Hard coding URLs is a quick way to unmaintainable spaghetti code that everyone hates.

2
  • Thanks Chris - I know that I can setup the redirect from my server, my question is really about performance. Would it defeat the purpose of the CDN if everything is going through a redirect first?
    – bendytree
    Oct 12, 2012 at 15:16
  • It would partially, but not entirely, defeat the purpose.
    – ceejayoz
    Oct 12, 2012 at 15:30
0

I believe it will have a non-trivial performance hit, for the following reasons:

  • SSL handshake: first connection to https://assets.mysite.com will be expensive, requiring lots of TCP roundtrips. After that first connection, assuming other assets are requested relatively quickly, the client could either reuse the connection, or at least reuse the SSL session rather than doing a completely new handshake.
  • every new, different asset at will require a hit to assets.mysite.com first, before getting a redirect to go to the CDN. If you have a small and fixed set of assets, that may be acceptable.
  • depending on client implementation, even a 301 may not be cached very well. [needs verification]
  • did you mention mobile app?

Usual disclaimer of "measure, measure, measure" applies.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .