RFC2616-HTTP1.1-Status Code(状态码规定部分—译文)

part of Hypertext Transfer Protocol -- HTTP/1.1

RFC 2616 Fielding, et al.

10 状态码规定（Status Code Definitions）

　　本文描述了每个状态码的相关规定，包括了对应状态码须要遵循的方法和在响应中须要的任何元信息。

10.1 Informational 1xx

　　该类状态码表示临时性的响应，仅由状态行和可选的头部组成，并由一个空行结束。该类状态码没有必须的头部字段。因为HTTP／1.0没有定义任何1xx状态码，除非在实验条件下，服务器不能向HTTP／1.0客户端发送1xx响应。

　　在一个有规律的响应返回以前，客户端必须准备好接受可能的一个或多个1xx响应，即便客户端并不须要100(Continue)状态消息。不须要的1xx响应状态可能会被客户端所忽略。

　　代理必须转发1xx响应，即便代理和它的客户端的连接已经关闭了，或者，除非代理自己要求生成1xx响应。（举个栗子，代理在转发请求时添加了“Expect：100-continue”字段，那么它不须要转发相应的100（Continue）字段）。

10.1.1 100 Continue

　　客户端应继续发送其请求。该临时响应用于通知客户端请求的初始部分已经被接受而且还没有被服务器拒绝。在请求结束后，服务器必须返回一个最终的响应。查看 8.2.3 小节得到有关该状态码更详细的内容。

10.1.2 101 切换协议（Switching Protocols）

　　服务器理解并愿意遵循客户端的请求，经过升级消息头字段（14.42小节），来修改在该连接上使用的应用协议。服务器在空行终止101响应以后会当即对那些包含UpGrade头字段的响应切换协议。

　　只有在有利的状况下，才应该切换协议。举个栗子，切换到较新版本的HTTP比旧版本更有利，而且在传递使用这些特征的资源时切换到实时、同步协议多是更有利的。

10.2 Successful 2xx

　　该类状态码表示客户端的请求已经被成功接收，理解和接受。

10.2.1 200 OK

　　请求已经成功。在响应中返回的信息取决于在请求中使用的方法，例如：

　　GET  与请求的资源相一致的实体会在响应中返回；

　　HEAD 与请求的资源相一致的实体头字段会在响应中返回，响应返回的内容没有任何的消息体（message-body）；

　　POST 一个描述或包含执行结果的实体；

　　TRACE 包含终端服务器接收到的请求消息的实体。

10.2.2 201 Created（已建立）

　　请求已经完成，并致使一个新的资源被建立。新建立的资源能够被响应实体中返回的URI所引用，该资源所引用的指定URI在Location头字段中给出。响应应该包括一个实体，该实体包含一个资源特性和位置的列表，用户或用户代理能够从中选择最合适的一个。实体的格式是由Content-Type头字段中的媒体类型所指定的。元服务器必须在返回201状态码以前生成相应的资源。若是执行结果没法被当即解析，那么服务器须要用202(Accepted)响应来替代。

　　一个201响应可能会包含一个ETag响应头字段，该字段表示刚刚建立的请求变量的实体标签的当前值，详情请见14.19小节。

10.2.3 202 Accepted（已接收）

　　请求已经被接受并在处理，可是处理尚未完成。请求最终可能会、也可能不会被处理，由于在处理实际发生的问题时它多是被禁止的。在像这样的异步操做中没法从新发送一个状态码。

　　202响应是有意不表态的。它的目的是容许服务器接收其它进程的请求(也许一个批处理(batch-oriented)进程一天只执行一次)，无需用户代理与服务器的链接一直持续到进程完成。使用此响应返回的实体应该包括请求的当前状态的说明和指向状态监视器的指针或用户什么时候才能预期该请求已经完成的估计。

10.2.4 203 Non-Authoritative Information（非受权信息）

　　实体头中返回的元信息不是元服务器可用的最终集合，可是是从本地或者第三方拷贝的。所呈现的集合能够是原始版本的子集或父集。例如，包含有关资源的本地注释信息有可能成为元服务器已知的源信息的父集。只有在响应为200的状况下才适用此响应码。

10.2.5 204 No Content（无内容）

　　服务器已经完成了相关请求，可是不须要返回实体主体，而且可能须要返回更新后的元信息。响应可能包括实体头形式的最新或更新后的源信息，该信息若是存在的话，须要与请求的变量相关联。

　　若是客户端是一个用户代理，则不该该从它在请求发送的文档中改变它的文档视图。此响应主要用于容许输入的动做而不引发对用户代理的活动文档视图的更改，尽管任何新的或更新的元信息都应应用于当前在用户代理的活动视图中的文档。

　　204响应无需包括消息主体，所以老是由头字段以后的第一个空行终止。

10.2.6 205 Reset Content（重置内容）

　　服务器已经完成了相应的请求，用户代理须要重置那些致使请求被发送的文档视图。此响应主要是为了容许经过用户输入进行操做的输入，而后清除输入的表单，以便用户能够轻松启动另外一个输入操做。该响应不能包含实体。

10.2.7 206 Partial Content（部份内容）

　　服务器已经完成了部分GET请求的资源的获取。该请求必须包含一个Range头字段(14.35小节)指按期望获取内容的范围，而且可能包含一个If-Range头字段（14.27小节）以使请求视条件而定。

　　该请求的响应必须包含下列头字段：

　　　 -  该响应须要包含一个描述范围的Content-Range头字段，要么就每个部分都须要一个包含Content-Range字段的多部分/字节范围(multipart/byteranges)的
Content-Type字段。若是该响应中存在Content-Length头字段，它的值必须与信息体中传输的八位字节数值相匹配。

      - Date

　　　 - ETag和（或）Content-Location，若是消息头将以200的形式响应给相同的请求。

　　　 - Expires,Cache-Control,和（或）Vary，若是字段值不一样于以前为相同变体所发送的任何响应的值。

　　若是206响应是一个使用强缓存验证的If-Range请求的结果(详情请看13.3.3), 该响应则不该该包含其它实体头。若是该相应是一个使用弱缓存验证的If-Rang请求的结果，那么响应中则必定不能包含其它实体头。这是为了防止缓存后的实体与更新后的头字段不一致的问题。不然，对于那些已经返回200响应的同一个请求，那么该响应必须包含全部的实体头。

　　若是ETag或Last-Modified头字段不匹配，那么缓存则必定不能将206响应与其它以前已经缓存的内容组合在一块儿。（详情请看13.5.4小节）

　　一个未提供Range和Content-Range的头字段必定不能缓存206响应。

10.3 重定向（Redirection） 3xx

　　这类状态代码指示为了完成请求，须要由用户代理采起进一步的动做。当且仅当第二次请求是GET或HEAD请求时，所需的动做能够仅由用户代理来执行而不与用户交互。客户端应该检测无限重定向循环，由于这样的循环会使每一个重定向都生成网络流量。

      Note:本规范的之前版本建议最多重定向五次。开发人员应该意识到可能有客户端存在这样一个固定的限制。

10.3.1 300 多种选择（Multiple Choices）

　　所请求的资源与代理资源集合中的任何一个都匹配，每个都有其指定的地址，而且提供了代理驱动（agent-driven）的相关协商信息（第12小节）可让用户或者用户代理能够选择一个更优的代理并重定向该请求到此地址。

　　即便是一个HEAD请求，响应也须要包含一个实体，该实体还有一个相关资源类目的列表和地址，这样可让用户或者用户代理选择一个最匹配的资源做为结果。实体格式由Content-Type头字段指定的媒体类型决定。根据用户代理的格式和能力，能够自动执行最合适的选择。然而，该规范没有定义任何有关于这种自动选择的标准。

　　若是服务器有一个优先的选择，他应该在Location字段中包含该指定资源的URI。用户代理可能会用Location字段值来自动重定向。除非另有说明，不然此响应是能够缓存的。

10.3.2 301 永久移除（Moved Permanently）

　　请求的资源已经分配了一个新的永久URI，而且任何对该资源的将来引用都应该使用返回的URI之一。具备连接功能的客户端应该在可能的状况下，自动将引用到的“请求URI(Request-URI)”的引用从新连接到服务器返回的一个或多个新的引用上。

　　新的永久URI须要在响应中的Location字段注明。

　　若是响应一个请求而接收到的是301状态的请求方法不是HEAD或者GET，那么用户代理就不能自动重定向该请求，除非用户能够确认该请求，由于这样可能会改变请求所发出的条件。

　　Note：当收到301状态码后自动重定向POST请求时，一些现有的HTTP/1.0用户代理将错误地将其更改成GET请求。
　

10.3.3 302 已发现(Found)

　　请求的资源暂时存储在不一样的URI下。因为重定向有时可能会被更改，因此客户端应该继续使用该“请求URI(Request-URI)”用于将来的请求。该响应仅在被Cache-Control或Expires头字段描述的时候会被缓存。

　　临时的URI应该由响应中的Location字段提供。除非请求方法是HEAD，不然响应的实体应该包含一个短超文本注释，其中带有指向新URI的超连接。

　　若是响应一个请求而接收到的是302状态的请求方法不是HEAD或者GET，那么用户代理就不能自动重定向该请求，除非用户能够确认该请求，由于这样可能会改变请求所发出的条件。　　

　　Note:RFC 1945和RFC 2068指定不容许客户端对重定向请求更改方法。然而，大多数现有的用户代理实现都将302视为303响应，在位置字段值上执行GET，而无论原始请求方法是什么。对于那些但愿明确代表客户指望的反应类型
的服务器，已经添加了状态代码303和307。

10.3.4 303 参见其余(See Other)

　　对请求的响应能够在不一样的URI下找到，应该使用该资源上的GET方法来检索。该方法主要用于容许POST激活（POST-activated）的脚本的输出将用户代理重定向到所选择的资源。新的URI不是最初请求的资源的替代引用。303响应不能被缓存，可是该响应的第二次（或重定向）请求可能会被缓存。

　　不一样的URI须要在响应的Location字段中给出。除非请求方法是HEAD，不然响应的实体应该包含一个短超文本注释，其中带有指向新URI的超连接。

      Note:不少HTTP/1.1以前版本的协议不理解303状态。当须要与此类客户端进行交互性操做时，可使用302状态码，由于大多数的用户代理对302状态的响应就像这里所描述的303同样。

10.3.5 304 未修改(Not Modified)

　　若是客户端执行了有条件的GET请求并容许访问，可是文件没有修改，此状态码应该用该状态码来响应。304响应不能包含一个消息体，所以，老是以头字段后的第一个空行结束。

该响应必须包含如下的头部字段：

      - Date, 除非他是按照14.18.1章节所描述的被要求遗漏的

　　若是无时钟的服务器遵循这些规则，而且代理和客户端将本身的日期添加到没有收到服务器日期的任何响应中(如[RFC 2068]第14.19节中已经指定的)，缓存将正确运行。

      - ETag 和（或） Content-Location, 若是消息头将以200响应的形式发送给相同的请求。

      - Expires, Cache-Control, 和(或) Vary, 若是字段值可能与以前的响应中所发送的相同的变量是不同的。

　　若是有条件的GET请求使用了一个强缓存验证（详情请看13.3.3小节），响应不能包括其余实体头字段。不然（即有条件的GET请求使用弱验证），响应必定不能包含其余实体头。这能够防止缓存的实体和已更新的头字段之间的不一致。

　　若是304响应表示当前未缓存的实体，则缓存必须忽略响应并从新发起一个无条件的请求。

　　若是一个缓存使用了接收到的304响应来更新一个缓存条目，那么该缓存必须更新该条目以反映在响应中给定的任何新的字段值。

10.3.6 305 使用代理（Use Proxy）

　　所请求的资源必须经过Location字段所提供的代理进行访问。Location字段提供了代理的URI地址。接收方但愿经过代理重复此单个请求。305响应必须仅由源服务器生成。

      Note: RFC 2068协议并不清楚305是否打算重定向单个请求，而且仅由原始服务器生成。不遵照这些限制会产生重大的安全后果。

10.3.7 306 (已废弃)

　　306状态码在本规范的前一个版本中使用，目前再也不使用，而且代码被保留。

10.3.8 307  临时重定向（Temporary Redirect）

　　请求的资源临时存储在另外一个URI下。因为该重定向有时可能会被修改，因此将来的客户端请求仍旧使用原请求URI。该响应仅在使用了Cache-Control或者Expires头字段描述的时候才会被缓存。

　　临时URI的地址须要在响应中的Location中给出。除非请求方法是HEAD，不然响应的实体应该包含一个简短的超文本注释，并带有到新URI的超连接，由于许多http /1.1以前版本的用户代理不理解307状态。所以，注释应该包含用户在新URI上从新开始原始请求所需的信息。

　　若是在响应中收到了307状态码，可是该响应的请求方法不是HEAD或者GET，用户代理必定不能自动重定向该请求，除非它已经被用户所确认，由于这可能会改变发出请求时的条件。

10.4  客户端错误（Client Error） 4xx

　　4xx类的状态码是为了描述客户端的错误。除了响应HEAD请求之外，服务器应该包含一个有着错误状况解释的实体，以及它是临时的仍是永久的。该类状态码适用于任何请求方法。客户代理须要为用户显示任何在响应中包含的实体内容。

　　若是客户端正在发送数据，那么使用TCP的服务器实现应该在服务器关闭输入链接以前确保客户端确认收到包含响应的数据包。若是客户端在关闭后继续向服务器发送数据，那么服务器的TCP堆栈将向客户机发送一个重置包，这可能会在HTTP应用程序读取和解释以前清除客户端未确认的输入缓冲区。

10.4.1 400 非法请求（Bad Request）

　　因为语法错误，服务器没法理解请求。客户端不该该在没有修改的状况下重复请求。

10.4.2 401 未经受权的（Unauthorized）

　　在发出请求时须要验证用户的身份信息。响应必须包含一个适用于所请求资源的用于询问的WWW-Authenticate头字段（14.47小节）。客户端可使用合适的Authorization头字段重复该请求（14.8小节）。若是请求已经包含了受权验证相关信息，而后401响应代表这些证书已经被拒绝受权。若是3-1响应包含了与以前响应相同的询问信息，而且用户代理至少已经尝试过一次认证，而后向用户显示响应中给出的实体，由于该实体可能包括相关的诊断信息。HTTP询问相关的身份验证的详细说明在“HTTP身份验证:简单扼要地访问身份验证[43]”中。

10.4.3 402 支付要求（Payment Required）

　　该状态码会在将来提供使用方法。

10.4.4 403 被拒绝的（Forbidden）

　　服务器理解相应的请求，可是拒绝该请求。受权不会有帮助，请求也不该该被重复。若是请求方法不是HEAD而且服务器但愿公开请求为何没有完成，它应该在实体中说明拒绝的缘由。若是服务器不但愿将此信息提供给客户端，那么可使用404状态码来代替。

10.4.5 404 未找到（Not Found）

　　服务器在匹配的请求URI上没有找到任何东西。没有迹象代表这种状况是暂时的仍是永久的。若是服务器经过一些内部可配置的机制知道旧资源永久不可用，而且没有转发地址，则应该使用410（Gone）状态代码。当服务器不但愿确切地显示请求被拒绝的缘由，或者当没有其余响应适用时，一般使用此状态代码。

10.4.6 405 方法不被容许（Method Not Allowed）

　　请求行中指定的方法不容许用于请求URI中标识的资源。响应必须包含一个Allow头字段，其中包含对请求资源有效的方法列表。

10.4.7 406 没法接受（Not Acceptable）

　　请求所标识的资源仅可以根据请求中发送的接收头字段生成具备不可接受的内容特征的响应实体。

　　除非是一个HEAD请求，响应应该包含一个有着可用实体特征和位置列表的实体，用户或用户代理能够从中选择最合适的实体内容。实体格式由Content-Type头字段中给出的媒体类型指定。根据用户代理的格式和能力，能够自动执行最合适的选择。然而，该规范没有定义任何用于这种自动选择的标准。

      Note: 服务器容许根据请求中发送的请求头返回不可接受的响应。在某些状况下，这甚至可能比发送406响应更好。咱们鼓励用户代理检查传入响应的报头，以肯定是否能够接受。

　　若是响应是不可接受的，则用户代理应该暂时中止接收更多的数据，并询问用户以决定进一步的行动。

10.4.8 407 须要代理验证身份（Proxy Authentication Required）

　　该状态码和401(Unauthorized)有些相似，但指示客户端必须首先用代理进行身份验证。代理必须返回一个Proxy-Authenticate头字段（14.33小节），该字段包含适用于所请求资源的代理的相关询问。客户端须要在重复该请求时包含一个合适的Proxy-Authorization头字段。http相关的访问验证说明在“HTTP Authentication: Basic and Digest Access Authentication” [43]中有详细的介绍。

10.4.9 408 请求超时（Request Timeout）

　　客户端没有在服务器准备等待的时间内生成请求。客户端能够在之后的任什么时候候重复该请求而不作任何修改。

10.4.10 409 冲突（Conflict）

　　因为与资源的当前状态发生冲突，请求没法完成。只有在预期用户可以解决冲突并从新提交请求的状况下才容许使用此代码。相迎体须要包含足够的信息让用户意识到该资源的冲突。理想状况下，响应实体将包含足够的信息给用户或用户代理来解决问题；然而，这多是不可能的，而且不是必需的。

　　冲突最有可能发生在响应PUT请求时。例如，若是当前的资源正在使用版本控制，即将被PUT的资源包含了一些修改，这些修改还会引发以前（或第三方）请求的冲突，服务器须要使用409响应来讲明它没法完成该请求。在这种状况下，响应实体可能包含两个版本之间的差别列表，格式由响应中的Content-Type定义。

10.4.11 410 已删除（Gone）

　　请求的资源已经不被服务器所提供，而且没有已知的地址可指向该资源。这种状况有望被认为是永久的。具备连接编辑功能的客户端应该在用户批准后删除对该请求uri的引用。若是服务器不知道，或者没有肯定的条件知道它的状态是不是永久的，那么则应该使用404状态码。除非另有说明，该响应是能够缓存的。

　　410响应主要是经过通知接收方资源是不可用的，而且服务器全部者但愿移除该资源的远程连接来协助Web维护的任务。这样的状况对于有时间限制的资源、促销服务和属于再也不在服务器站点工做的我的的资源来讲是常见的。不须要将全部永久不可用的资源标记为“已用（GONE）”，也不须要将标记保留任什么时候间——这由服务器全部者自行决定。

10.4.12 411 须要长度（Length Required）

　　服务器拒绝接受没有Content-Length头字段的请求。若是客户端在请求消息中添加包含消息正文长度的有效的Content-Length头字段，则能够重复该请求。

10.4.13 412 未知足前提条件（Precondition Failed）

　　在服务器上测试请求头字段时，在一个或多个请求头字段中给出的先决条件被评估为false。此响应码容许客户端在当前资源的元信息(header字段数据)上放置先决条件，从而防止请求的方法被应用到预期资源以外的资源。

10.4.14 413 请求实体过大（Request Entity Too Large）

　　服务器拒绝处理请求，由于请求实体大于服务器想要或可以处理的范围。服务器可能关闭链接，以防止客户端继续请求。

　　若是条件是临时的，服务器应该包含Retry-After头字段，以代表它是临时的，而且在什么时候能够再次尝试该请求。

10.4.15 414 请求URI过长（Request-URI Too Long）

　　因为请求URI过长，超过了服务器所能解析的极限，因此服务器拒绝为该请求提供服务。这种罕见的状况只可能发生在客户端将一个POST请求不当的转换成为一个具备过长的查询(query)信息的GET请求的时候，当客户端进入URI重定向的“黑洞”（好比，一个重定向URI的前缀指向了它自身的后缀），或者当服务器遭到客户端攻击时，试图利用固定长度缓冲器来读取某些服务器中存在的安全漏洞，以读取或操纵请求URI。

10.4.16 415 不支持的媒体类型（Unsupported Media Type）

　　服务器拒绝为该请求提供服务，由于请求的实体是使用该请求方法来请求的资源所不支持的格式。

10.4.17 416 没法知足的请求范围（Requested Range Not Satisfiable）

　　若是一个请求中包含看Range请求头字段，而且此字段中的范围说明符值均不与所选资源的当前范围重叠，而且请求中并无If-Range请求头字段，那么服务器应该在响应中返回该状态码。（对于byte-ranges字段，它说明在全部字节范围中的第一字节值都大于所选资源的当前长度。）

　　当该状态码为响应一个byte-range请求而返回，该响应须要包含一个Content-Range实体头字段，用来讲明当前所选择资源的长度（详情请看 14.16小节）。该响应不能使用multipart/byteranges类型。

10.4.18 417 未知足Expect头字段所标识的信息（Expectation Failed）

　　该服务器没法知足Expect 头部字段（见第14.20节）中的指望，或者，若是服务器是代理服务器，则服务器有明确的证据代表该请求不能被下一跳（next-hop）服务器所知足。

10.5 服务器错误（Server Error） 5xx

　　以数字“5”开头的响应状态码表示服务器意识到它已经出错或没法执行请求的状况。除了响应头部请求以外，服务器还应该返回一个包含解释错误状况的实体，以及它是不是临时的或永久性的状态。代理应该向用户展现全部的实体内容。这些响应码适合任何请求方法。

10.5.1 500 内部服务器错误（Internal Server Error）

　　服务器遇到了一个意外状况，阻止了它完成相应的请求。

10.5.2 501 未实现（Not Implemented）

　　服务器不支持完成请求所需的功能。当服务器没法识别请求的方法或者没法提供任何资源的时候，应该返回该响应。

10.5.3 502 坏网关（Bad Gateway）

　　服务器做为网关或代理，在尝试执行请求时从上游服务器接收到无效响应。

10.5.4 503 服务不可用（Service Unavailable）

　　因为服务器的临时过载或维护，服务器目前没法处理该请求。这意味着，这是一个暂时的状态，将在一些延迟后获得缓解。若是已知延迟的时间，那么延迟的长度可能会在Retey-After头字段中表示。若是没有提供Retry-After字段，客户端应该像处理500响应那样处理该响应。

Note: 503状态代码的存在并不意味着服务器在重载时必须使用它。有些服务器可能简单地但愿拒绝链接。

10.5.5 504 网关超时（Gateway Timeout）

　　服务器做为网关或代理，没有收到来自URI（例如HTTP、FTP、LDAP）或在试图完成请求时须要访问的其余辅助服务器（例如DNS）所指定的上游服务器的及时响应。

      Note: 开发者注意:当DNS查找超时时，已知一些已部署的代理返回400或500。

10.5.6 505 不支持的HTTP版本（HTTP Version Not Supported）

　　服务器不支持或拒绝支持请求消息中使用的HTTP协议版本。该服务器指示它不能或不肯意使用与客户端相同的主版本完成请求，如在第3.1节中所描述的，而不是使用此错误消息。响应应该包含一个实体，说明为何不支持该版本以及该服务器支持哪些其余协议。