Forum: Ruby on Rails image_tag adding request parameter

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
B1d59a804bd67487c964bc505a8eb892?d=identicon&s=25 Thiago Arrais (Guest)
on 2006-04-10 18:12
(Received via mailing list)
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
41e1579600683eed6c00af9a425268e6?d=identicon&s=25 Edward Frederick (Guest)
on 2006-04-10 18:24
(Received via mailing list)
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
6e09635022712a6dd26b9510a2c96820?d=identicon&s=25 Pazu (Guest)
on 2006-04-10 18:52
(Received via mailing list)
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
30269682335f1fb247d71969fa715b5e?d=identicon&s=25 Roberto Saccon (rsaccon)
on 2006-04-10 19:01
(Received via mailing list)
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...).
6e09635022712a6dd26b9510a2c96820?d=identicon&s=25 Pazu (Guest)
on 2006-04-11 14:52
(Received via mailing list)
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
Ec5a599777854c540fd102ef4691fe10?d=identicon&s=25 Rimantas Liubertas (Guest)
on 2006-04-11 15:20
(Received via mailing list)
> 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/
6e09635022712a6dd26b9510a2c96820?d=identicon&s=25 Pazu (Guest)
on 2006-04-11 22:44
(Received via mailing list)
Rimantas Liubertas <rimantas@...> writes:

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

I 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
This topic is locked and can not be replied to.