404错误处理：重定向还是直接404？（摘录)

小型网站开发通常会使用某种Web应用框架，比如类似Spring、Express、Django等框架。 这些框架会给出自定义错误页面的方式。当404发生时Web框架会渲染并返回对应的错误页面。 这是最自然和直接的错误处理方式，但有时我们希望错误页面可以单独Serve，比如放到CDN上。 本文档依据RFC 2616（HTTP 1.1）比较几种常见的404错误处理方法：

• 返回具有404信息的页面，同时给出404状态码。

  Google、Github、Facebook、Amazon、Linkedin。

• 重定向（302/303）至错误URL，该URL给出具有404信息的页面。

  百度、淘宝、腾讯

状态码及其语义

使用最广的HTTP标准当属1999年发布的HTTP/1.1， R. T. Fielding 在2000年的博士论文 “Architectural Styles and the Design of Network-based Software Architectures” 中重申如何正确使用HTTP语义以及REST架构风格。 符合标准的HTTP消息拥有透明的、自描述的语义，通信方遵循一致的标准才使得整个互联网得以高效地运行。

HTTP状态码对用户不可见，因为Web页面返回给用户之后页面代码并非直接显示给用户， 而是经由用户代理（User Agent，比如浏览器、爬虫等）处理。 状态码的重要性在于它告诉用户代理当前页面的状态，借此用户代理才能做出正确的操作： 比如刷新当前页面，或者访问另一个URL，重置或重新提交表单等等。

HTTP状态码有很多，本文档只关心其中的404，200，以及302/303状态码。

200

请求成功。对于GET，应当返回被请求资源的实体；对于POST，应当返回操作的结果。

RFC 2616: 10.2.1

The request has succeeded. The information returned with the response
is dependent on the method used in the request, for example:

GET   an entity corresponding to the requested resource is sent in
          the response;
POST  an entity describing or containing the result of the action;

302

被请求的资源暂时位于另一个URI处，并且对于非HEAD/GET请求， 用户代理在重定向前必须询问用户确认。

RFC 2616: 10.3.3

The requested resource resides temporarily under a different URI.
Since the redirection might be altered on occasion, the client SHOULD
continue to use the Request-URI for future requests. This response
is only cacheable if indicated by a Cache-Control or Expires header
field.

RFC 1945 和 RFC 2068 规定客户端不允许更改请求的方法。但很多浏览器会将302当做303来处理。

303

被请求的资源暂时位于另一个URI处，并且应当以GET方法去请求那个资源。

RFC 2616: 10.3.4

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. The new URI is not a
substitute reference for the originally requested resource. The 303
response MUST NOT be cached, but the response to the second
(redirected) request might be cacheable.

404

服务器未能找到URI所标识的资源。也常被用于服务器希望隐藏请求被拒绝的具体原因。 例如403、401可能会被统一处理为404。

RFC 2616: 10.4.5

The server has not found anything matching the Request-URI. No
indication is given of whether the condition is temporary or
permanent. 

This status code is commonly used when the server does not wish to
reveal exactly why the request has been refused, or when no other
response is applicable.

直接404

直接404是常见Web框架的通用做法：对于每一个用户请求遍历所有可能的路由， 如果任何一个控制器都不处理该请求，则Web服务器返回一个具有404状态码的HTTP响应。

404状态码告诉用户代理（User Agent）请求中的URI所标识的资源不存在， 用户代理将该HTTP响应的主体（往往是HTML）显示给用户， 该HTML页面是终端用户可读的，通常也会包含Not Found信息，以及一些有用的链接。

爬虫是一种特殊的用户代理，通常用于搜索引擎。当搜索引擎的爬虫发现某URI返回404状态码时， 会认为该URI已经失效而不对它进行索引，或者将该URI标识的已索引资源移除。 所以是网站迁移时，如果一个旧的URI会位于一个新的URI处，应当使用301重定向来告知搜索引擎： 该资源并未失效只是位置发生变化。

当我们无法控制服务器返回301时，也可在返回的HTML中使用特殊标记 来告知用户代理这是一个301，这在迁移静态站点时非常有用。

404的一个问题在于不支持CDN。如果为了提升性能使用CDN服务， 将404.html文件托管到CDN提供商，访问该文件显然会返回200状态码。 因为CDN服务器认为你所访问的文件存在。

重定向至错误页面

在国内网站中更常见的方式是将所有错误重定向至错误页面，比如error.html。 当用户代理访问error.html时服务器返回状态码为200，这便是神奇的200 Not Found。 200 Not Found显然不符合HTTP语义标准，下面从搜索引擎和CDN两个方面评价该方法的优劣：

搜索引擎非常不友好。当一个页面Not Found时爬虫并不知情，因为它收到的状态码是303。 于是跟随重定向并索引了错误页面error.html。这意味着该网站会有大量的URL都拥有同样的内容（404页面）， 网站会因此受到搜索引擎的惩罚而排名下降。

优点

国内不少公司选择重定向的错误处理方式，笔者总结该方式的优点：

• 固定的错误页面可以直接托管于CDN，通过CDN统计和脚本的方式来统计错误。
• 固定的URL可以支持更加松耦合的架构，只需约定重定向URL即可构建前后端通用的错误处理。
• 最重要的是简单稳定，不会对外暴露错误详情。

缺点

200 Not Found 的缺点是愤青所不能接受的，总结如下：

报警级别降低

404 是失败而 302/200 是成功，这会让开发者忽略错误甚至引发意外后果。

• 资源文件发生 MIME Type 报警而非 404 错误。
• 当 AJAX 请求被重定向时，可能会引发意外后果。

发生意外错误

意外的错误显然会浪费大量的调试时间。 这一件事 Harttle 认为熟并不能能生巧： 当一个开发者已经熟悉并接受 200 Not Found 环境下的调试时，他的价值观已经被扭曲。

• 脚本、样式 Not Found 会发生解析错误（比如unexpected token <）而不是 404 错误。
• 如果重定向至不同域（开发中很常见），CSS 中的字体等资源引起Access-Control-Allow-Origin错误。

调试困难

报警级别降低和意外错误的发生已经让调试变得更加困难，还有更困难的：

• Network 控制台不再能显示哪个请求404，需要从错误页面请求的 Initiator 反推。
• 从浏览器地址栏访问一个页面被302后，无法回退继续访问原页面。（因为 302 的语义让浏览器认为你就是要这个页面！）

参考

• RFC 2616: https://www.ietf.org/rfc/rfc2616.txt

转载请注明来源： http://harttle.land/2016/08/03/error-page-404-or-200.html 欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论（可能需要在能访问 disqus 服务的网络），也可以邮件至 harttle@harttle.com。