浅谈HTTP状态码的使用

作者：老王

HTTP状态码很重要，可是现在的Web开发者很少注意它，结果出现了很多误用也就是意料之中的事情了，即便是在很多成熟的Web框架中，也随手就能找到很多错误使用的例子，看如下取自CakePHP的代码：

function view($id = null) {
    if (!$id) {
        $this->Session->setFlash(__('Invalid Article.', true));
        $this->redirect(array('action'=>'index'));
    }
    $this->set('post', $this->Article->read(null, $id));
}

这段代码逻辑很简单：查看文章时，有的话则显示，没有的话就跳转到列表页，并显示一条解释信息。当用户请求一篇并不存在的文章时，系统就会自动重定向，作为结果，用户会看到重定向后的解释信息，从而意识到这篇文章并不存在。

这里一直假设了一个前提，那就是客户端是浏览器，坐在浏览器前面的是智能的人类，他能看懂解释信息，可惜实际上客户端也可能会是搜索引擎，搜索引擎背后是机械的电脑，设想当搜索引擎检索一篇已经被删除的文章时，系统自动把请求重定向，并显示一条解释信息，但问题是搜索引擎是看不懂这条信息的，它唯一识别请求结果的依据是响应的状态码，而重定向缺省的状态码是“302 Found”，会使搜索引擎误解文章只是转移了位置而已，可这不是事实。

再看一个例子，使用POST方法添加文章成功后的HTTP响应状态码到底应该是什么？

先看看200状态码，在RFC里是这样描述它的：The request has succeeded.
再看看201状态码，在RFC里是这样描述它的：The request has been fulfilled and resulted in a new resource being created.

从RFC的描述上来看似乎200/201均可，但无疑201更明确一些。可惜201并不是万无一失的选择，当请求是用Ajax发出的话，把201作为响应状态码没有问题，但是如果请求是用Form提交的话，那把201作为响应状态码就存在“表单重复加载”的问题：设想当一篇文章已经被成功添加后，用户如果刷新页面，就会再次添加一篇内容相同的文章。

解决这个问题的办法就是303状态码，在RFC里是这样描述它的：The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource.

所以使用POST方法添加文章成功后，201或303作为响应的状态码都是可能的，关键是分辨请求发起者，然后为它选择最贴切的响应状态码。

总结，本文通过两个例子来说明如何准确使用HTTP状态码，具体的还得读者自己慢慢体会。

参考链接：http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html