jacquescrocker / jammit-s3

Extensions so you can use jammit with s3/cloudfront for your Rails app
http://documentcloud.github.com/jammit/
MIT License
124 stars 31 forks source link

Implemented asset path versioning to work with Amazon CloudFront #12

Closed kmamykin closed 13 years ago

kmamykin commented 13 years ago

The complication of using jammit-s3 with CloudFront, is that CloudFront caching does not respect Rails cache busting technique of appending a query string to each asset url. So when you roll out a new build with that new amazing logo, CloudFront will treat the url path /logo.png?123456 and /logo.png?56789 as the same file and serve it from the cache without re-fetching it from the origin server.

This work implements asset path versioning, where Jammit-s3 inserts a cache busting token right in the asset path, causing browsers and cacheing proxies to refetch it from the origin server. The value if the cache busting token is read from RAILS_ASSET_ID environment variable, and inserted right at the root of the paths, e.g. =image_tag "logo.png" will generate an image tag with href to http://xxxxx.cloudfront.net/a4f2c23/logo.png, where a4f2c23 is the value of ENV['RAILS_ASSET_ID'] on your application server.

mrrooijen commented 13 years ago

+1

tritonrc commented 13 years ago

+1

kmamykin commented 13 years ago

Ok, committing next weekend to work on this. Pull into jailsjedi branch, and possibly implement asset invalidation strategy

mrrooijen commented 13 years ago

I believe this fork already implemented an invalidation strategy: https://github.com/dedene/jammit-s3

jacquescrocker commented 13 years ago

meskyanichi confirmed that dedene's approach worked in his app so I pulled in https://github.com/railsjedi/jammit-s3/commit/3dead946da96d94f33d05ed4e63e40785f8ab4a4

seems pretty simple and straightforward. Please test and let me know if theres any errors. Sorry it took so long to get this merged in. I can release a new gem as soon as people confirm that its stable enough to release.

Thanks!