4 ms·
It's true that this is a problem if you insist on serving your CDN assets a custom domain CNAME mapped to CloudFront (i.e. https://assets.mydomain.com/ https://
by friism 13y ago
It's true that this is a problem if you insist on serving your CDN assets a custom domain CNAME mapped to CloudFront (i.e. https://assets.mydomain.com/ https://assets.mydomain.com/). It doesn't cost extra if you just use the default CloudFront distribution URL, i.e. https://d3vam04na8c92l.cloudfront.net/stylesheets/application-6502e5a88f02b90aeb32c2dd21ea37ab.css https://d3vam04na8c92l.cloudfront.net/stylesheets/applicatio...
This is not entirely clear from the Heroku docs, I'll ping the maintainer for an update.
- nthj 13y agoOne cool trick for serving mixed http/https that I somehow went 10 years without finding out: you can just point your Rails asset_host to "//d3vam04na8c92l.cloudfront.net". Browsers understand this to mean "Look up this address via whatever protocol I am currently on, http if http, https if over SSL." This is a huge cache boost in Rails because you don't have to cache your pages twice (once for HTTP once for HTTPs.)
- girvo 13y agoOh god.. While your post is cool, I reacted violently to the "One cool trick..." part at the beginning. Upworthy, you've broken me.
- sanderjd 13y agoIs there any real downside to this approach, or is it just that it looks "less professional"?
- neilmiddleton 13y agoNo, you're still serving the same assets. It's only really an issue if your users like seeing where network requests are going and spot the cloudfront URL.