Forum: Ruby on Rails rails_asset_id, query strings, and browser caching

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
7077206baf3a50094dcdbf81c46a0e08?d=identicon&s=25 Chris Boone (Guest)
on 2006-05-23 13:37
(Received via mailing list)
Hi all.

Now that compute_public_path calls _rails_asset_id to append a query
string containing the asset file's modification date, all asset URLs
contain query strings. [1] Which, in theory, is a fantastic thing for
caching, since it forces browsers to download and not cache changed
assets, allows them to cache unchanged assets forever, and has no
effect on the actual file or what is served.

However. In reading Cal Henderson's recent article on Think Vitamin
[2], I noticed that he claims that Safari and Opera do not cache any
resources with URLs that contain query strings, and that this
behaviour is correct according to the HTTP spec.

So I checked, and, as to the latter, he's correct: Section 13.9 of
HTTP/1.1 [3] says:

> We note one exception to this rule: since some applications have traditionally used GETs 
and HEADs with query URLs (those containing a "?" in the rel_path part) to perform 
operations with significant side effects, caches MUST NOT treat responses to such URIs as 
fresh unless the server provides an explicit expiration time. This specifically means that 
responses from HTTP/1.0 servers for such URIs SHOULD NOT be taken from a cache.

So. I certainly appreciate the intent behind rails_asset_id, its
implementation seems flawed.

Perhaps it should be implemented using a scheme more along the lines
suggested by Henderson? That is, with whatever versioning number used
appended to the file during path generation. and that number stripped
off again when the file is requested.

Other ideas?



Chris Boone, Hypsometry
Web Application Design & Development
This topic is locked and can not be replied to.