jcm
jcm

Reputation: 5659

Cloudfront and CSS/JS assets

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?

Upvotes: 2

Views: 4769

Answers (5)

Guillermo Siliceo Trueba
Guillermo Siliceo Trueba

Reputation: 4619

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//

Upvotes: 2

joshmckin
joshmckin

Reputation: 201

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

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

Upvotes: 0

Jef Weg
Jef Weg

Reputation: 11

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.

Upvotes: 1

Kevin Dewalt
Kevin Dewalt

Reputation: 777

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

Upvotes: 2

John Beynon
John Beynon

Reputation: 37507

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.

Upvotes: 2

Related Questions