I have noticed that the image_tag helper method now appends a request parameter to the generated src attribute. With Rails 1.0/actionpack-1.11.2 I had <img src="/images/rss.gif" /> Now (1.1/1.12.1) I get <img alt="Rss" border="0" src="/images/rss.gif?1142366545" /> Is there any use for that number? Where does it come from? This is very far from critical and is in no way a breaking change (at least for me), but I am curious to know why things changed. Cheers, Thiago Arrais
Changelog:
Added automated timestamping to AssetTagHelper methods for
stylesheets, javascripts, and images when Action Controller is run
under Rails [DHH]. Example:
image_tag("rails.png") # => ''<img
alt="Rails"
src="/images/rails.png?1143664135" />''
?to avoid frequent stats (not a problem for most people), you can set
RAILS_ASSET_ID in the ENV to avoid stats:
ENV["RAILS_ASSET_ID"] = "2345"
image_tag("rails.png") # => ''<img
alt="Rails" src="/images/rails.png?2345" />''
This can be used by deployment managers to set the asset id by
application revision
On 4/10/06, Thiago Arrais <thiago.arrais@gmail.com>
wrote:> I have noticed that the image_tag helper method now appends a request
> parameter to the generated src attribute. With Rails
> 1.0/actionpack-1.11.2 I had
>
> <img src="/images/rss.gif" />
>
> Now (1.1/1.12.1) I get
>
> <img alt="Rss" border="0"
src="/images/rss.gif?1142366545" />
>
> Is there any use for that number? Where does it come from?
>
> This is very far from critical and is in no way a breaking change (at
> least for me), but I am curious to know why things changed.
>
> Cheers,
>
> Thiago Arrais
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
Edward Frederick <epfrederick@...> writes:> Added automated timestamping to AssetTagHelper methods for > stylesheets, javascripts, and images when Action Controller is run > under Rails [DHH]. Example:That''s quit extreme, screwing up caches *by default* to please a few corner cases that can''t handle dynamic content properly. The example below is specially bad:> image_tag("rails.png") # => ''<img alt="Rails" > src="/images/rails.png?1143664135" />''"/images" will usually live under public, so it is *static*. Why add timestamping to a static resource? At worse, these tags should add timestamping only in the rare case where the image path is actually mapped *to* an action controller (not *from* a controller). That, or I''m really missing something... -- Pazu
I thought the purpose of this is the browser cache. If a ressource file gets changed, it''s changed at the browser with the next request. Especially important for IE (in case there are pople still using it...). On 4/10/06, Pazu <pazu@pazu.com.br> wrote:> > Edward Frederick <epfrederick@...> writes: > > > Added automated timestamping to AssetTagHelper methods for > > stylesheets, javascripts, and images when Action Controller is run > > under Rails [DHH]. Example: > > That''s quit extreme, screwing up caches *by default* to please a few > corner > cases that can''t handle dynamic content properly. The example below is > specially > bad: > > > image_tag("rails.png") # => ''<img alt="Rails" > > src="/images/rails.png?1143664135" />'' > > "/images" will usually live under public, so it is *static*. Why add > timestamping to a static resource? At worse, these tags should add > timestamping > only in the rare case where the image path is actually mapped *to* an > action > controller (not *from* a controller). > > That, or I''m really missing something... > > -- Pazu > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Roberto Saccon - http://rsaccon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060410/c0e57792/attachment.html
Roberto Saccon <rsaccon@...> writes:> I thought the purpose of this is the browser cache. If a ressource file gets > changed, it''s changed at the browser with the next request. Especially > important for IE (in case there are pople still using it...).Browser cache is a Good Thing (TM). It avoids repeated requests for resources that don''t change (hence the name ''static resources''), saving network traffic, reducing the load in your application, loading pages faster and generally making the user happier. Of course, you need to understand how the browser cache (and http caches in general) works, and play well with it. The rules are actually quite simple, and it doesn''t take much to make sure browsers will cache what they can, and refetch what they should. -- Pazu
> Browser cache is a Good Thing (TM). It avoids repeated requests for resources > that don''t change (hence the name ''static resources''), saving network traffic, > reducing the load in your application, loading pages faster and generally making > the user happier. > > Of course, you need to understand how the browser cache (and http caches in > general) works, and play well with it. The rules are actually quite simple, and > it doesn''t take much to make sure browsers will cache what they can, and refetch > what they should.Do you think timestamping that was added breaks caching in any way? From what I see it helps, not breaks. Timestamp is not some random value, but time of the file modification, so it in fact helps in cases when "If-modified-since" and "If-none-match" don''t play nice. Regards, Rimantas -- http://rimantas.com/
Rimantas Liubertas <rimantas@...> writes:> Timestamp is not some random value, but time of the > file modificationI knew I was missing something ;-) From the messages above, I had the impression that ''timestamp'' was referring to some value generated at request time, and not the actual file timestamp. You''re right, done this way, timestamping will only help caching instead of hurting it. -- Pazu