If I write :
<%= image_tag “rails.png” %>
I get in HTML :
What is the number at the end of the src tag ? What is it for ?
Thanks :).
Nicolas.
A timestamp of when the file was last saved. It allows browsers to
cache the file and not re-request it with every page load, while still
knowing that they have the latest available version.
Nicolas B. wrote:
What is the number at the end of the src tag ? What is it for ?
http://hypsometry.com/blog/on-browser-caching-asset-timestamping-and-rails
Check out the part about “on asset timestamping and Rails”
Interesting :)…
Thank you all for your answers :).
Nicolas.
On 2006-09-20, at 18:03 , Nicolas B. wrote:
What is the number at the end of the src tag ? What is it for ?
That generates a unique url, forcing a refresh on every request.
Especially useful for stylesheets.
Caio C. wrote:
That generates a unique url, forcing a refresh on every request.
Especially useful for stylesheets.
almost…
“rails_asset_id checks the fileâ??s modification timestamp and returns it
to compute_public_path, which appends it as a query string.”
compute_public_path is called by tag(), which is called by image_tag().
So it only refreshes if the timestamp has changed.
Ah! I was wondering the same thing myself.
David C. wrote:
Nicolas B. wrote:
What is the number at the end of the src tag ? What is it for ?
http://hypsometry.com/blog/on-browser-caching-asset-timestamping-and-rails
Check out the part about “on asset timestamping and Rails”
After reading that, it’s my understanding that the timestamp was
introduced to force browsers to download updated assets instead of
getting them from the cache. Seems like this behavior should be disabled
in production mode.
Joe
Jon is right
from asset_tag_helper.rb:
def rails_asset_id(source)
ENV[“RAILS_ASSET_ID”] ||
File.mtime("#{RAILS_ROOT}/public/#{source}").to_i.to_s rescue “”
end
File.mtime returns the modification time of the file which is
appended to the asset. When the asset is modified the file name
changes forcing browsers to pull the updated version.
Aaron
Caio and Jon’s answers seem to clash…
who is right???
On 9/21/06, Jason N. [email protected] wrote:
What is the number at the end of the src tag ? What is it for ?
That generates a unique url, forcing a refresh on every request.
Especially useful for stylesheets.
–
www.blogsaic.com
search, post, blog
Why would you want to disable this? Assets change, even in production
mode. A
designer wants to push a margin a bit to the left or right, a new image
replaces an existing one… The point is that this tagging forces the
browser to pull down the new asset iff the modtime of the asset is
different
from the one currently in the browser cache.
Cayce B.-2 wrote:
After reading that, it’s my understanding that the timestamp was
–
View this message in context:
http://www.nabble.com/Newbie-%3A-What-is-the-number-Rails-adds-in-images-URL%2C-etc--tf2308121.html#a6422152
Sent from the RubyOnRails Users mailing list archive at Nabble.com.
Steve R. wrote:
Why would you want to disable this? Assets change, even in production
mode. A
designer wants to push a margin a bit to the left or right, a new image
replaces an existing one… The point is that this tagging forces the
browser to pull down the new asset iff the modtime of the asset is
different
from the one currently in the browser cache.
Cuz the URLs are yucky. My assets hardly change in production – so
infrequently that they’re probably already gone from any repeat
visitor’s browser cache.
Joe
On Sep 20, 2006, at 11:59 PM, Joe R. MUDCRAP-CE wrote:
http://hypsometry.com/blog/on-browser-caching-asset-timestamping-
and-rails
Check out the part about “on asset timestamping and Rails”After reading that, it’s my understanding that the timestamp was
introduced to force browsers to download updated assets instead of
getting them from the cache. Seems like this behavior should be
disabled
in production mode.
I don’t agree. If a file has not been updated then the only cost is
the time it takes to check the modification date of the file. When
you do update files in production the attached timestamp forces
browsers to pull the most recent version, which is a good thing.
I’ve seen plenty of cases where a browser continues to use a cached
CSS file after its been updated on the server.
Aaron
On 2006-09-21, at 02:17 , Dion H. wrote:
Caio and Jon’s answers seem to clash…
who is right???
Jon. but my justification is correct, the purpose is to force a reload.
Rails is clever enough to use a timestamp so as to only force reloads
when it really matters.
Aaron B. wrote:
On Sep 20, 2006, at 11:59 PM, Joe R. MUDCRAP-CE wrote:
http://hypsometry.com/blog/on-browser-caching-asset-timestamping-
and-rails
Check out the part about “on asset timestamping and Rails”After reading that, it’s my understanding that the timestamp was
introduced to force browsers to download updated assets instead of
getting them from the cache. Seems like this behavior should be
disabled
in production mode.I don’t agree. If a file has not been updated then the only cost is
the time it takes to check the modification date of the file. When
you do update files in production the attached timestamp forces
browsers to pull the most recent version, which is a good thing.I’ve seen plenty of cases where a browser continues to use a cached
CSS file after its been updated on the server.Aaron
I don’t understand why people are doing all this updating in production
– that’s just bad practice. Also, web servers ALSO check file
modification times so they can send if/modified-since headers (not that
I expect that cost to be of any significance).
Joe
Joe R. MUDCRAP-CE wrote the following on 21.09.2006 08:33 :
[…]
I don’t understand why people are doing all this updating in production
– that’s just bad practice.
Ok, but…
This helps when you upgrade the production with a new release. The
problem is not the update frequency but only the fact that updates
happen.
Lionel.
Lionel B. wrote:
Joe R. MUDCRAP-CE wrote the following on 21.09.2006 08:33 :
[…]
I don’t understand why people are doing all this updating in production
– that’s just bad practice.Ok, but…
This helps when you upgrade the production with a new release. The
problem is not the update frequency but only the fact that updates
happen.
Sure, but how bad is the browser caching problem? It seems like it
usually takes (me) not more than a couple of reloads to grab the latest
version from the server.
Joe
Joe R. MUDCRAP-CE wrote:
problem is not the update frequency but only the fact that updates
happen.Sure, but how bad is the browser caching problem? It seems like it
usually takes (me) not more than a couple of reloads to grab the latest
version from the server.Joe
On the other hand, how bad is the ‘bad URL’ problem? It should be fine
if the URL is a bit dirty since Rails creates it itself… and the
problem is not a user like YOU who does the refresh. It is users who
don’t know that they could/ should. Rails ensures that loading updated
resources is the responsibility of the browser. But, it seems we may
end up disagreeing on this issue 
Cheers
Mohit.