2

I have a cloudfront distribution set up to go to myapp.herokuapp.com

Maybe I've misunderstood Cloudfront and CDNs in general, but I thought that somehow the CDN hosted the static files instead of me just including references to the CDN URL in my HTML files stored on Heroku. What I'm seeing in my Chrome Network tab is:

Request URL:http://blah123.cloudfront.net/css/style-123.css

Request Method:GET Status Code:301 Moved Permanently

then:

Request URL:http://myapp.herokuapp.com/css/style-123.css

Request Method:GET Status Code:304 Not Modified

Is there another way to set up Cloudfront so that the requests for these static files don't hit my Heroku node at all?

3
  • Same problem here. I was able to get it working with the asset_sync gem but since Heroku no longer recommends it I'm trying to use this approach. I get 301 redirects as well. Any fixes? Commented Feb 17, 2014 at 22:50
  • No, haven't figured anything out yet, maybe I'll start a bounty. Commented Feb 18, 2014 at 0:02
  • Great. I also contacted Heroku support, they're usually pretty responsive. Just really weird. Commented Feb 18, 2014 at 1:52

5 Answers 5

2

Have you seen this article https://devcenter.heroku.com/articles/using-amazon-cloudfront-cdn - it covers the subject in quite a lot of detail.

But it doesn't sound like you've misunderstood.

You shouldn't see requests going to your herokuapp certainly if you're looking at the inspector. Assuming you've configured all your assets to be loaded from your cloudfront URL then when an asset is requested from that URL if it's not already cached by cloudfront, cloudfront will grab the asset from your herokuapp and then serve that back but you wouldn't see this in your browser inspector. The next time a request comes in for the same asset it will be served from cloudfront.

Sign up to request clarification or add additional context in comments.

Comments

2

I'm having the same problem as cookiemonster. I was able to get Cloudfront working with the asset_sync gem, https://github.com/rumblelabs/asset_sync, but not per Heroku's article, https://devcenter.heroku.com/articles/using-amazon-cloudfront-cdn

I'm trying to switch away from asset_sync because (1) it adds complexity, and (2) Heroku no longer recommends it.

From my response below you can see that Amazon issues a 301 redirect for each call.

Here are some details for the staging server:

My entire site is https

My staging.rb

config.action_controller.asset_host = "https://d2gfgnx4lxlciz.cloudfront.net" 

Cloudfront

I used a generic configuration, only changing the origin:

Domain Name: d2gfgnx4lxlciz.cloudfront.net Origin: sohelpfulme-staging.herokuapp.com Delivery Method: Web CNAMEs: none 

HTTP Headers

Request URL:https://d2gfgnx4lxlciz.cloudfront.net/assets/jquery-20129d378db54e4ede9edeafab4be2ff.js Request Method:GET Status Code:301 Moved Permanently Request Headersview source Accept:*/* Accept-Encoding:gzip,deflate,sdch Accept-Language:en-US,en;q=0.8,zh-CN;q=0.6,zh-TW;q=0.4 Cache-Control:no-cache Connection:keep-alive Cookie:optimizelyEndUserId=oeu1387769272844r0.715743659529835; optimizelySegments=%7B%7D; optimizelyBuckets=%7B%7D Host:d2gfgnx4lxlciz.cloudfront.net Pragma:no-cache Referer:https://sohelpfulme-staging.herokuapp.com/testuser User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36 Response Headersview source Age:32 Connection:keep-alive Content-Type:text/html Date:Mon, 17 Feb 2014 22:43:36 GMT Location:https://sohelpfulme-staging.herokuapp.com/assets/jquery-20129d378db54e4ede9edeafab4be2ff.js Status:301 Moved Permanently Strict-Transport-Security:max-age=31536000 Transfer-Encoding:chunked Via:1.1 16fab6bd7655623b4e7dcaf090973fc8.cloudfront.net (CloudFront) X-Amz-Cf-Id:oiKeV-b3OrhbtkjXrMtyNI9EMvydfdnZ8Drp2fxojNHiveqBNsttJA== X-Cache:Hit from cloudfront X-Rack-Cache:miss 

1 Comment

config.action_controller.asset_host shouldn't include the http || https prefixes, it will be appended automatically. I'd also recommend setting it in your environment variables for easy alterations.
2

For me it was a matter of the distribution configuration. A quick checklist for future googlers of this problem:

  1. HTTPS sites: If your website is https only make sure your include the protocol on the rails config

config.action_controller.asset_host = 'https://d1fnn4c7qqjz6e.cloudfront.net/'

And in the distribution the setting Origin Protocol Policy should be set to

Match Viewer

I also have the Viewer Protocol Policy set to

Redirect HTTP to HTTPS

  1. If you serve fonts, you'll also want to choose to forward a whitelist of headers and include these headers

Access-Control-Allow-Origin

Access-Control-Allow-Methods

Access-Control-Allow-Headers

Access-Control-Max-Age

  1. For firefox make sure you set the Allowed HTTP Methods to

GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE

You can check a file with

curl -I https://d1fnn4c7qqjz6e.cloudfront.net/assets/rails_admin/logo-5cf7f2f8b1177213b00e5ec63a032856.png//

Comments

1

This happened to me when I setup SSL. To fix it I deleted the distribution group on cloudfront and created a new distribution group and rolled the app again with the new cloudfront subdomain. Once I did that it no longer did a 301 back to my app.

Comments

0

This is weird but appending a '/' to the cloudfront url fixed this for me:

config.action_controller.asset_host = "https://d2gfgnx4lxlciz.cloudfront.net/"

2 Comments

Your url will look something like: d2gfgnx4lxlciz.cloudfront.net//assets/images/cool.png don't ask me why but it works. Forgot to mention I'm not using an S3 bucket I'm letting my Heroku App serve the first instance and CloudFront caches it from there like Heroku suggests
Turns out our 301 was do to the fact CloudFront will cache a 301. Our site is SSL only and initially we had 'Origin Protocol Policy' set to 'HTTP' instead of 'Match view'. When CloudFront first hit the heroku site the app redirected to HTTPS which create the cached 301. Setting 'Origin Protocol Policy' to 'Match view' in the CloudFront console and updating the asset version in the application.rb file was the real fix.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.