HTTP状态码详解

HTTP状态码详解

1xx - 信息提示

这些状态代码表示临时的响应。客户端在收到常规响应之前,应准备接收一个或多个 1xx 响应。

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

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

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 没有新的内容,但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容(HTTP 1.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新)。
  • 414 - Request URI Too Long URI太长(HTTP 1.1新)。
  • 415 – 不支持的媒体类型。
  • 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的必要了。
坚持原创技术分享,您的支持将鼓励我继续创作!