HTTP状态码详解

1xx - 信息提示

这些状态代码表示收到Web浏览器的请求，正在进一步处理中

• 100 - Continue 初始的请求已经接受，客户应当继续发送请求的其余部分。

  当客户端要POST较大数据给webserver时，可以在发送http头时带上Expect:100-continue，服务器如果接受这个请求，应答一个HTTP/1.1 100 Continue，那么客户端就继续传输正文，否则应答417 Expectation Failed，客户端就放弃传送剩余的数据了。这样就避免客户端吭哧吭哧传了一大堆数据上去，结果服务端发现不需要的情况。

• 101 - Switching Protocols 服务器将遵从客户的请求转换到另外一种协议。

2xx - 成功

这类状态代码表明用户请求被正确的接收

• 200 - OK 一切正常，对GET和POST请求的应答文档跟在后面。

• 201 - Created 服务器已经创建了文档，Location头给出了它的URL。

• 202 - Accepted 已经接受请求，但处理尚未完成。

• 203 - Non-Authoritative Information 文档已经正常地返回，但一些应答头可能不正确，因为使用的是文档的拷贝，非权威性信息（HTTP 1.1新）。

• 204 - No Content 没有新文档，浏览器应该继续显示原来的文档。如果用户定期地刷新页面，而Servlet可以确定用户文档足够新，这个状态代码是很有用的。

• 205 - Reset Content 没有新的内容，但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容（HTTP1.1新）。

  206 - Partial Content 客户发送了一个带有Range头的GET请求，服务器完成了它（HTTP 1.1新）。

3xx - 重定向

这类状态代码表明请求没有成功，客户必须采取进一步的动作。例如，浏览器可能不得不请求服务器上的不同的页面，或通过代理服务器重复该请求。

• 300 - Multiple Choices客户请求的文档可以在多个位置找到，这些位置已经在返回的文档内列出。如果服务器要提出优先选择，则应该在Location应答头指明。
• 301 - Moved Permanently 客户请求的文档在其他地方，新的URL在Location头中给出，浏览器应该自动地访问新的URL。
• 302 - Found 类似于301，但新的URL应该被视为临时性的替代，而不是永久性的。注意，在HTTP1.0中对应的状态信息是“Moved Temporatily”。出现该状态代码时，浏览器能够自动访问新的URL，因此它是一个很有用的状态代码。注意这个状态代码有时候可以和301替换使用。例如，如果浏览器错误地请求 http://host/~user （缺少了后面的斜杠），有的服务器返回301，有的则返回302。严格地说，我们只能假定只有当原来的请求是GET时浏览器才会自动重定向。请参见 307。
• 303 - See Other 类似于301/302，不同之处在于，如果原来的请求是POST，Location头指定的重定向目标文档应该通过GET提取（HTTP 1.1新）。
• 304 - Not Modified 客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓存的文档还可以继续使用。
• 305 - Use Proxy 客户请求的文档应该通过Location头所指明的代理服务器提取（HTTP 1.1新）。
• 307 - Temporary Redirect 和302（Found）相同。许多浏览器会错误地响应302应答进行重定向，即使原来的请求是POST，即使它实际上只能在POST请求的应答是303时才能重定向。由于这个原因，HTTP 1.1新增了307，以便更加清除地区分几个状态代码：当出现303应答时，浏览器可以跟随重定向的GET和POST请求；如果是307应答，则浏览器只能跟随对GET请求的重定向。（HTTP 1.1新）

4xx - 客户端错误

客户端错误，表示客户端提交的请求有错误。例如，客户端请求不存在的页面，客户端未提供有效的身份验证信息。

• 400 - Bad Request 请求出现语法错误。

• 401 - Unauthorized
  访问被拒绝，客户试图未经授权访问受密码保护的页面。应答中会包含一个WWW-Authenticate头，浏览器据此显示用户名字/密码对话框，然后在填写合适的Authorization头后再次发出请求。IIS
  定义了许多不同的 401 错误，它们指明更为具体的错误原因。这些具体的错误代码在浏览器中显示，但不在 IIS 日志中显示：

  · 401.1 - 登录失败。

  · 401.2 - 服务器配置导致登录失败。

  · 401.3 - 由于 ACL 对资源的限制而未获得授权。

  · 401.4 - 筛选器授权失败。

  · 401.5 - ISAPI/CGI 应用程序授权失败。

  · 401.7 – 访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。

• 403 - Forbidden 资源不可用。服务器理解客户的请求，但拒绝处理它。通常由于服务器上文件或目录的权限设置导致。禁止访问：IIS 定义了许多不同的 403 错误，它们指明更为具体的错误原因：

  · 403.1 - 执行访问被禁止。

  · 403.2 - 读访问被禁止。

  · 403.3 - 写访问被禁止。

  · 403.4 - 要求 SSL。

  · 403.5 - 要求 SSL 128。

  · 403.6 - IP 地址被拒绝。

  · 403.7 - 要求客户端证书。

  · 403.8 - 站点访问被拒绝。

  · 403.9 - 用户数过多。

  · 403.10 - 配置无效。

  · 403.11 - 密码更改。

  · 403.12 - 拒绝访问映射表。

  · 403.13 - 客户端证书被吊销。

  · 403.14 - 拒绝目录列表。

  · 403.15 - 超出客户端访问许可。

  · 403.16 - 客户端证书不受信任或无效。

  · 403.17 - 客户端证书已过期或尚未生效。

  · 403.18 - 在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所专用。

  · 403.19 - 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用。

  · 403.20 - Passport 登录失败。这个错误代码为 IIS 6.0 所专用。

• 404 - Not Found 无法找到指定位置的资源。这也是一个常用的应答。

  · 404.0 -（无） – 没有找到文件或目录。

  · 404.1 - 无法在所请求的端口上访问 Web 站点。

  · 404.2 - Web 服务扩展锁定策略阻止本请求。

  · 404.3 - MIME 映射策略阻止本请求。

• 405 - Method Not Allowed 请求方法（GET、POST、HEAD、Delete、PUT、TRACE等）对指定的资源不适用，用来访问本页面的 HTTP 谓词不被允许（方法不被允许）（HTTP 1.1新）

• 406 - Not Acceptable 指定的资源已经找到，但它的MIME类型和客户在Accpet头中所指定的不兼容，客户端浏览器不接受所请求页面的 MIME 类型（HTTP 1.1新）。
• 407 - Proxy Authentication Required 要求进行代理身份验证，类似于401，表示客户必须先经过代理服务器的授权。（HTTP 1.1新）
• 408 - Request Timeout 在服务器许可的等待时间内，客户一直没有发出任何请求。客户可以在以后重复同一请求。（HTTP 1.1新）
• 409 - Conflict 通常和PUT请求有关。由于请求和资源的当前状态相冲突，因此请求不能成功。（HTTP 1.1新）
• 410 - Gone 所请求的文档已经不再可用，而且服务器不知道应该重定向到哪一个地址。它和404的不同在于，返回407表示文档永久地离开了指定的位置，而404表示由于未知的原因文档不可用。（HTTP 1.1新）
• 411 - Length Required 服务器不能处理请求，除非客户发送一个Content-Length头。（HTTP 1.1新）
• 412 - Precondition Failed 请求头中指定的一些前提条件失败（HTTP 1.1新）。
• 413 – Request Entity Too Large 目标文档的大小超过服务器当前愿意处理的大小。如果服务器认为自己能够稍后再处理该请求，则应该提供一个Retry-After头（HTTP 1.1新）。
• 416 – Requested Range Not Satisfiable 服务器不能满足客户在请求中指定的Range头。（HTTP 1.1新）
• 417 – 执行失败。 423 – 锁定的错误。

5xx - 服务器错误

服务器错误，表示服务器不能完成对请求的处理。

• 500 - Internal Server Error 服务器遇到了意料不到的情况，不能完成客户的请求。

  · 500.12 - 应用程序正忙于在 Web 服务器上重新启动。

  · 500.13 - Web 服务器太忙。

  · 500.15 - 不允许直接请求 Global.asa。

  · 500.16 – UNC 授权凭据不正确。这个错误代码为 IIS 6.0 所专用。

  · 500.18 – URL 授权存储不能打开。这个错误代码为 IIS 6.0 所专用。

  · 500.100 - 内部 ASP 错误。

• 501 - Not Implemented 服务器不支持实现请求所需要的功能，页眉值指定了未实现的配置。例如，客户发出了一个服务器不支持的PUT请求。

• 502 - Bad Gateway 服务器作为网关或者代理时，为了完成请求访问下一个服务器，但该服务器返回了非法的应答。 亦说Web 服务器用作网关或代理服务器时收到了无效响应。

  · 502.1 - CGI 应用程序超时。

  · 502.2 - CGI 应用程序出错。

• 503 - Service Unavailable服务不可用，服务器由于维护或者负载过重未能应答。例如，Servlet可能在数据库连接池已满的情况下返回503。服务器返回503时可以提供一个 Retry-After头。这个错误代码为 IIS 6.0 所专用。

• 504 - Gateway Timeout 网关超时，由作为代理或网关的服务器使用，表示不能及时地从远程服务器获得应答。（HTTP 1.1新） 。

• 505 - HTTP Version Not Supported 服务器不支持请求中所指明的HTTP版本。（HTTP 1.1新）。

  其他

关于HTTP 204状态码：

没有响应体的HTTP/200和HTTP/204在大多数情况下完全等效。但有一种情况下,HTTP/204响应会让浏览器有不同的表现.这种情况就是当用户在浏览器窗口window或者frame/iframe框架中导航的时候.

如果导航到的URL返回了一个没有响应体的HTTP/200响应,则页面将会显示一个空白文档(就是一片白色).页面的URL地址也会变成新指定的URL.

如果服务器返回的是一个HTTP/204响应,当前页面不会有任何变化,就好像根本没有进行导航操作一样.页面的URL地址也保持不变.

关于302,303和307:

302: 如果客户端发出POST请求后，收到服务端的302状态码，那么不能自动的向新的URI发送重复请求，必须跟用户确认是否该重发。但现在很多浏览器默认直接将其重定向为GET

303：对于POST请求，它表示请求已经被处理，把POST重定向为GET。客户端可以接着使用GET方法去请求Location里的URI。

307：对于POST请求，表示请求还没有被处理，需要跟用户询问是否应该在新URI上发起POST方法，也就是说，307是不会把POST转为GET的。

状态码——302

RFC1945，也就是HTTP1.0在介绍302时说，如果客户端发出POST请求后，收到服务端的302状态码，那么不能自动的向新的URI发送重复请求，必须跟用户确认是否该重发，因为第二次POST时，环境可能已经发生变化（嗯，POST方法不是幂等的），POST操作会不符合用户预期。但是，很多浏览器（user agent我描述为浏览器以方便介绍）在这种情况下都会把POST请求变为GET请求。

RFC2616，也就是HTTP1.1在介绍302时说，如果客户端发出非GET、HEAD请求后，收到服务端的302状态码，那么就不能自动的向新URI发送重复请求，除非得到用户的确认。（又是-,-）但是，很多浏览器都把302当作303处理了（注意，303是HTTP1.1才加进来的，其实从HTTP1.0进化到HTTP1.1，浏览器什么都没动），它们获取到HTTP响应报文头部的Location字段信息，并发起一个GET请求。

状态码——303和307

从上面的介绍可以知道，HTTP1.1和HTTP1.0的302状态码意义是一样的，浏览器对它的处理也是一样的。POST方法的重定向在未询问用户的情况下就变成GET，这种不符合文档规范的问题依然存在。实践在前，而文档在后，HTTP1.1把这种POST变GET的行为纳入了RFC文档：HTTP1.1新加入303和307状态码。

文档中规定303状态码的响应，也就是上边提到的现在浏览器对302状态码的处理：POST重定向为GET。

HTTP1.1文档中307状态码则相当于HTTP1.0文档中的302状态码，当客户端的POST请求收到服务端307状态码响应时，需要跟用户询问是否应该在新URI上发起POST方法，也就是说，307是不会把POST转为GET的。

从网络上搜索到这个说法“303：对于POST请求，它表示请求已经被处理，客户端可以接着使用GET方法去请求Location里的URI。 307：对于POST请求，表示请求还没有被处理，客户端应该向Location里的URI重新发起POST请求。”，从上面的介绍可以明白，这个说法是臆想而已，文档并没有这么说，而业界是否统一如此处理，还不好说，我没有抓到过307和303的包。
文档也说到，为兼容很多HTTP1.1之前的浏览器，服务端在需要发出303状态码时，会选择用302状态码替代；而对于307的处理，则需要在响应实体中包含信息，以便不能处理307状态码的用户有能力在新URI中发起重复请求，也就是说，把重定向的页面展示给用户，让用户去点重定向URI链接（URI现在基本就是URL）。

总结

303和307是HTTP1.1新加的服务器响应文档的状态码，它们是对HTTP1.0中的302状态码的细化，主要用在对非GET、HEAD方法的响应上。文档规定：浏览器对303状态码的处理跟原来浏览器对HTTP1.0的302状态码的处理方法一样；浏览器对307状态码处理则跟原来HTTP1.0文档里对302的描述一样。

303和307的存在，归根结底是由于POST方法的非幂等属性引起的。

在HTTP1.1中，302理论上是要被放弃掉的，它被细化为303和307，但为了兼容，它目前还在业界中大量使用，而303和307状态码我还没遇到过（没有使用场景，也没抓到过这样的响应报文）。为什么业界少使用303和307呢？对于GET和HEAD方法来说，307是没必要存在的，用302或者303就可以满足需求了，307仅在POST方法的重定向上有用处。所以我猜测它们少见的原因有两方面：

1. POST方法重定向的使用场景太少，使得307状态码没有用武之地；
2. GET方法虽然常需要使用的重定向，但使用302状态码也能正确运转，再考虑到微乎其微的兼容问题（现在的浏览器怎么可能不支持HTTP1.1呢！），也就没有使用303的必要了。