Image_tag adding request parameter

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

Now (1.1/1.12.1) I get

Rss

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 A.

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”) # => ‘Rails

?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”) # => ‘Rails

This can be used by deployment managers to set the asset id by
application revision

Edward F. <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”) # => ‘Rails

“/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…).

Browser cache is a Good Thing ™. 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/

Roberto S. <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 ™. 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

Rimantas L. <rimantas@…> writes:

Timestamp is not some random value, but time of the
file modification

I knew I was missing something :wink: 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