Rails中取消asset id

在Rails中使用helper链接应用中的JavaScript和CSS文件的时候,会在文件的路径后面添加一个问号和一个数字,如:

问号后面的数字被称为asset id,目的是为了一些容易被缓存的目标如JavaScript和CSS文件,在文件被更改后不会被浏览器或代理服务器强制使用缓存,这也用于某些Ajax请求中。

但是这种asset id的行为比较怪异,他是一个查询字符串,但是没有键值对。我的一个部署方式是在一个已经架设了Wordpress的域名下,使用反向代理向用户暴露某个控制器。因为给Wordpress配置了mod_rewrite,并启用了.htaccess,将所有不存在的文件重写到wordpress的脚本处理。而这时我使用了Alias来将Rails的public目录下的javascripts和stylesheets目录绑定到相应的URL路径下,Apache却在处理这个asset id上有些问题,直接访问/javascripts/prototype.js可以得到,但/javascripts/prototype.js?11223344却会跑到WordPress中,并且说这个文件不存在。这可能和Apache处理URL的次序有关。当然,将DocumentRoot配置到Rails的Public目录,则不会出现这个问题。

无论如何,我要去掉这个asset id,根据Rails 2.0的代码,大家可以在actionpack/lib/action_view/helpers/asset_tag_helper.rb中找到生成asset id的方法rails_asset_id,如下:

代码的注释也说的很清楚了,asset id默认为文件的修改时间的时间戳,也可以通过环境变量RAILS_ASSET_ID来自行设置。环境变量可以在系统中设定,也可以在environment.rb或相应的环境配置的代码中修改,比如我在config/environments/production.rb中添加了:

这样最终Rails生成的代码中就没有asset id了。

小结

我认为asset id在开发环境中的意义更大,因为这些文件可能会被频繁修改,这么作就可以防止被浏览器强制缓存。但在实际的生产环境中,这些文件并不会被频繁修改,而我们正是需要这样的缓存,带有“?”的URL常常是不被缓存的,我们完全可以通过链接带有版本号的文件来确保调用了正确的版本,如”prototype-1.6.0.js”,Flickr就是这么做的:

你还能在它页面中看到更为夸张的文件名。当然,Flickr也在某些地方使用了asset id——究竟什么样的情况下用asset id,还可以继续探讨。

对于Ajax请求,POST方式是不会被缓存的,可以放心使用。

Nginx的WordPress配置

WordPress是一个非常流行的Blog系统,它可以利用Apache的mod_rewrite来实现URL的静态化。安装好的WordPress在配置了持久链接之后,会在网站的根目录下(如果可写)生成一个.htaccess文件,这个文件可以指示Apache如何进行URL重写(如果服务器配置为允许使用htaccess的指令的话),它的内容如下:

这个文件的意思就是,如果当请求的文件不存在,那么把请求内部重定向到/index.php。WordPress会自己分析请求的URL,来判断显示哪个页面。

在上次配置了Nginx+PHP之后,由于Nginx不支持Apache的.htaccess文件,要实现持久连接静态化,我们必须手工配置Nginx的文件。首先找到Nginx的配置文件,默认编译后的配置文件在/usr/local/nginx/conf/nginx.conf;Ubuntu通过包安装的配置文件位于/etc/nginx/nginx.conf,也可以编辑vhost的配置文件,放在了/etc/nginx/sites-available下。

以下是基本的配置(Ubuntu下的范例):

还可以有很多种不同配置方式,例如不改写所有包含wp-的url等。此配置考虑了目录下的索引文件index.html和index.php。-f指令表示测试文件是否存在(不考虑文件和目录的区别),!-f则表示不存在。注意在重写url到index.html后面有个break,而重写到index.php后没有break。因为html文件不需要任何额外工作可以直接发送到客户端,所以重写规则在这里终止,下面就直接让nginx发送文件。而.php文件需要进一步发送到fastcgi进程来运行,Nginx会继续判断该文件符合第二个部分location ~ .*\.php$的规则,并进行FastCGI的转发。

大家可以将以上内容保存为wordpress.conf,然后在自己的vhost配置,即server节中应用该配置文件,例如(以下为Ubuntu进行的配置):

接下来让Nginx重新载入配置文件,便可使用WordPress的持久链接了。