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?
Thanks,
Chris
[1]
http://hypsometry.com/blog/on-browser-caching-asset-timestamping-and-rails
[2] http://www.thinkvitamin.com/features/webapps/serving-javascript-fast
[3] HTTP/1.1: Caching in HTTP
–
Chris B., Hypsometry
http://hypsometry.com/
Web Application Design & Development