-
到底是谁的错?
2009-03-19
版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://phper.blogbus.com/logs/36735281.html
在 AJAX Mistakes 中提到了关于 Google Web Accelerator 的问题,此问题的原出处为 Google Web Accelerator: Hey, not so fast - an alert for web app designers,没想到这个问题现在讨论得热火朝天了,在 Chris Shiflett 的 BLOG 中也开始了这方面的讨论,观点有很多种。
一种是认为造成这种结果是开发者的责任,不要去抱怨 Google,因为在 HTTP 规格说明书 RFC 2612 的 9.1.1 章节 中已经谈到了这一点:In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
也就是说 GET 方法用于完全安全的请求,即是说不需要任何其他多余的动作,表现在链接方式上,就是不要在链接上加上 JavaScript 操作,比如在删除的链接中,点击之后会提示用户“是否确实想要删除?”,使用了这种 JavaScript 动作说明这个点击操作不是完全安全的,那么就不能使用链接方式,而是要使用表单的 POST 等方式。
另一种认为这是 Google 的责任,因为现实中已经存在了很多在链接中使用 JavaScript 的操作,而且 HTTP 规格说明书中并没有使用 MUST NOT,而是使用了 SHOULD NOT,所以 GET 是被允许这样使用的。
当然,除了上边两种之外,还有比较折中的,就是认为双方都有责任,一方是没有太好地去遵循标准,另一方是太过于苛刻地去遵循标准,并且忽略了目前存在的很多现实应用。
目前,对于这方面的问题解决,可以通过服务器端代码判断实现,当然也可以通过修改客户端的所有存在 JavaScript 操作的链接,但这样修改量可能会比较大。对于使用 Ruby on Rails 的,可以在这里看到解决的代码示例,此代码通过判断,如果是 GWA 发来的请求,则返回 403 错误。对于使用 PHP 的,可以参考 Ruby 代码进行相应的改动:
<?php
if ($_SERVER['HTTP_X_MOZ'] == 'prefetch') {
header('HTTP/1.0 403 Forbidden');
exit;
}
?>
对于这个问题,我比较支持第三种观点,确实双方都有责任,很多标准其实也是在大家相互之间的妥协中形成的。随机文章:
一段废弃的代码 2007-07-05, 2007-05-07协议大全..WEB开发手册大全!! 2007-03-17Simple BBTag Parser 2007-03-05我和耿先生的合影! 2006-11-04
收藏到:Del.icio.us







