Closed kmamykin closed 13 years ago
+1
+1
Ok, committing next weekend to work on this. Pull into jailsjedi branch, and possibly implement asset invalidation strategy
I believe this fork already implemented an invalidation strategy: https://github.com/dedene/jammit-s3
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!
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.