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

Posted 2020-12-24 zaking

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节中所描述的，而不是使用此错误消息。响应应该包含一个实体，说明为什么不支持该版本以及该服务器支持哪些其他协议。