May not be a bug, really, but opened here for discussion, because it would 
seem that a file not changing its digest when it changes is a problem: 
https://github.com/sstephenson/sprockets/issues/399

On Wednesday, December 19, 2012 11:13:11 AM UTC-5, Gary Weaver wrote:
>
> I also tried using digest in development and learned something: you can 
> change an asset by moving one section of the file to another section and 
> even though the file is thumbprinted/digested, sometimes the browser won't 
> reload it.
>
> Basically, I changed config/environments/development.rb to use:
>
>   config.assets.debug = false
>   config.assets.digest = true
>
> and much of the time if I move one section of the file to another part of 
> the same file (and I tried in a few different ways), the browser (FF 17 in 
> OS X) won't reload the asset because it is still cached, even when I am 
> forcing Sprockets to cache-bust via this patch in 
> config/initializers/.../name_of_my_patch.rb
>
> # Sprockets 2.x patch to cache-bust non-fingerprinted angular template 
> html in development
> if Rails.env.development?
>   module Sprockets
>     module Server
>     
>     private
>       # want to attempt to be compatible as much as possible so we'll call 
> their headers method 'sprockets_headers' and then
>       # override just the headers we want. this may or may not work in 
> future versions as this is a private method.
>       alias_method :sprockets_headers, :headers
>
>       def headers(env, asset, length)
>         sprockets_headers(env, asset, length).tap do |headers|
>           # both digested/thumbprinted and non-digested files seem to not 
> refresh cache (at least with FF 17)
>           # so, use cache-busters for .../app/assets/**/*
>           if asset.pathname.to_s['/app/assets/']
>             puts "cache-busting #{asset.pathname.to_s} 
> etag_header=#{headers["ETag"]} 
> path_fingerprint(env[\"PATH_INFO\"])=#{path_fingerprint(env["PATH_INFO"])}"
>             headers["Cache-Control"] = "max-age=0, private, 
> must-revalidate"
>           end
>         end
>       end
>     end
>   end
> end
>
> However, with that patch, if I comment out the following:
>
>   #config.assets.debug = false
>   #config.assets.digest = true
>
> It seems to work as intended.
>
> On Tuesday, December 18, 2012 3:57:46 PM UTC-5, Gary Weaver wrote:
>>
>> Just monkey patched Sprockets in our Rails 3.2.9 app to override the 
>> Cache-Control header for html assets that we need to tweak more often in 
>> development, but that we don't want to use digests/fingerprinting with:
>>
>> # Sprockets 2.x patch
>> if Rails.env.development?
>>   module Sprockets
>>     module Server
>>     
>>     private
>>       alias_method :sprockets_headers, :headers
>>
>>       def headers(env, asset, length)
>>         sprockets_headers(env, asset, length).tap do |headers|
>>           # cache-bust .html assets because in our case they are 
>> frequently AngularJS templates we need to tweak
>>           if !path_fingerprint(env["PATH_INFO"]) && 
>> asset.pathname.basename.to_s['.html']
>>             headers["Cache-Control"] = "max-age=0, private, 
>> must-revalidate"
>>           end
>>         end
>>       end
>>     end
>>   end
>> end
>>
>> Would the ability to configure "Cache-Control" and other headers (or add 
>> headers) in responses for assets in Sprockets be helpful to have available 
>> in Rails, or is it just assumed that if you need that level of control, 
>> you'll fix it elsewhere with nginx, apache, etc.?
>>
>> Why I'm asking is that Heroku shows here how to change expiry of actions:
>> https://devcenter.heroku.com/articles/http-caching-ruby-rails
>>
>> but, I couldn't find anywhere that talked about how to expire assets 
>> other than using digests/fingerprinting, until I came across server.rb in 
>> sprockets and realized that it didn't look like it was possible without 
>> monkey patching or using another gem that would override the headers.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/rubyonrails-core/-/HcNRNnZoz8gJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Reply via email to