常用HTTP状态码解释

超文本传输​​协议的 一部分 - HTTP / 1.1

RFC 2616 Fielding，et al。

10状态码定义

下面描述了每个状态代码，包括它可以遵循哪种方法以及响应中所需的任何元信息的描述。

10.1信息1xx

此类状态代码表示临时响应，仅包含Status-Line和可选标头，并以空行终止。此类状态代码没有必需的标头。由于HTTP / 1.0没有定义任何1xx状态代码，服务器不得向HTTP / 1.0客户端发送1xx响应，除非在实验条件下。

客户必须准备好在常规响应之前接受一个或多个1xx状态响应，即使客户端不期望100（继续）状态消息。用户代理可以忽略意外的1xx状态响应。

代理必须转发1xx响应，除非代理与其客户端之间的连接已关闭，或者除非代理本身请求生成1xx响应。（例如，如果是

代理在转发请求时添加“Expect：100-continue”字段，然后它不需要转发相应的100（继续）响应。）

10.1.1 100继续

客户端应该继续提出请求。该临时响应用于通知客户端已经接收到请求的初始部分并且尚未被服务器拒绝。客户端应该继续发送请求的剩余部分，或者如果请求已经完成，则忽略此响应。服务器必须在请求完成后发送最终响应。有关此状态代码的使用和处理的详细讨论，请参见第 8.2.3 节。

10.1.2 101交换协议

服务器通过升级消息头字段（第14.42节）了解并愿意遵守客户端的请求，以更改此连接上使用的应用程序协议。服务器将在终止101响应的空行之后立即将协议切换到响应的Upgrade头字段定义的协议。

协议应该只在有利的时候切换。例如，切换到较新版本的HTTP比旧版本更有利，并且当递送使用这些特征的资源时，切换到实时同步协议可能是有利的。

10.2成功2xx

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

10.2.1 200好的

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

在响应中发送GET对应于所请求资源的实体;

HEAD对应于所请求资源的实体头字段在响应中发送而没有任何消息体;

POST一个描述或包含行动结果的实体;

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

10.2.2 201创建

请求已完成，并导致创建新资源。新创建的资源可以由响应实体中返回的URI引用，其中由Location头字段给出的资源的最具体URI。响应应该包括一个实体，其中包含资源特征和位置的列表，用户或用户代理可以从中选择最合适的资源特征和位置。实体格式由Content-Type头字段中给出的媒体类型指定。原始服务器必须在返回201状态代码之前创建资源。如果无法立即执行操作，服务器应该响应202（已接受）响应。

201响应可以包含ETag响应头字段，该字段指示刚刚创建的请求变体的实体标签的当前值，参见 14.19 节。

10.2.3 202接受

该请求已被接受处理，但处理尚未完成。该请求最终可能会或可能不会被执行，因为在实际处理时可能不允许该请求。没有用于从诸如此类的异步操作重新发送状态代码的工具。

202回复是故意不承诺的。其目的是允许服务器接受对某些其他进程的请求（可能是每天只运行一次的面向批处理的进程），而不要求用户代理与服务器的连接持续到进程完成为止。返回此响应的实体应该包括请求的当前状态的指示，以及指向状态监视器的指针或用户可以期望满足请求的某些估计。

10.2.4 203非权威信息

实体标头中返回的元信息不是从源服务器可用的权威集，而是从本地或第三方副本收集的。所呈现的集合可以是原始版本的子集或超集。例如，包括关于资源的本地注释信息可能导致源服务器已知的元信息的超集。不需要使用此响应代码，仅当响应为200（OK）时才适用。

10.2.5 204没有内容

服务器已完成请求但不需要返回实体主体，并且可能希望返回更新的元信息。响应可以包括实体标题形式的新的或更新的元信息，如果存在，应该与所请求的变体相关联。

如果客户端是用户代理，它不应该从导致请求发送的文档视图中更改它的文档视图。此响应主要用于允许在不导致更改用户代理的活动文档视图的情况下进行操作的输入，尽管任何新的或更新的元信息应该应用于当前在用户代理的活动视图中的文档。

204响应绝不能包含消息体，因此总是在头字段之后的第一个空行终止。

10.2.6 205重置内容

服务器已完成请求，用户代理应该重置文档视图，导致请求被发送。该响应主要用于允许通过用户输入进行动作的输入，然后清除给出输入的表单，以便用户可以容易地发起另一个输入动作。响应绝不能包含实体。

10.2.7 206部分内容

服务器已完成对资源的部分GET请求。请求必须包含一个Range头字段（第14.35节），表示所需的范围，并且可以包含一个If-Range头字段（第 14.27 节）以使请求成为条件。

响应必须包括以下标头字段：

-  Content-Range标题字段（第14.16节）指示
        此响应中包含的范围，或多部分/字节范围
        Content-Type包括每个部分的Content-Range字段。如果一个
        Content-Length头字段存在于响应中
        值必须与在中传输的实际OCTET数相匹配
        邮件正文。

- 日期

-  ETag和/或Content-Location，如果标题已被发送
        在200响应同一请求

- 如果字段值可能，则Expires，Cache-Control和/或Vary
        与之前任何响应中发送的内容不同
        变种

如果206响应是使用强缓存验证器的If-Range请求的结果（参见第13.3.3节），则响应不应该包括其他实体头。如果响应是使用弱验证器的If-Range请求的结果，则响应不得包含其他实体头; 这可以防止缓存的实体主体和更新的标头之间的不一致。否则，响应必须包括所有返回的实体头，并对同一请求进行200（OK）响应。

如果ETag或Last-Modified标头不完全匹配，则缓存不得将206响应与其他先前缓存的内容组合，请参见 13.5.4 。

不支持Range和Content-Range标头的缓存不得缓存206（部分）响应。

10.3重定向3xx

此类状态代码指示用户代理需要采取进一步操作才能完成请求。当且仅当第二个请求中使用的方法是GET或HEAD时，所需的操作可以由用户代理执行而不与用户交互。客户端应该检测无限重定向循环，因为这样的循环会为每个重定向生成网络流量。

注意：此规范的先前版本建议使用
      最多五次重定向。内容开发者应该知道
      可能有客户实现这样一个固定的
      局限性。

10.3.1 300多种选择

所请求的资源对应于一组表示中的任何一个，每个表示具有其自己的特定位置，并且正在提供代理驱动的协商信息（部分12），以便用户（或用户代理）可以选择优选表示并重定向其请求到该位置。

除非是HEAD请求，否则响应应该包括一个实体，其中包含资源特征和位置列表，用户或用户代理可以从中选择最合适的资源特征和位置。实体格式由Content-Type头字段中给出的媒体类型指定。取决于格式和功能

用户代理，可以自动选择最合适的选择。但是，该规范没有为这种自动选择定义任何标准。

如果服务器具有首选的表示选择，则它应该在Location字段中包含该表示的特定URI; 用户代理可以使用Location字段值进行自动重定向。除非另有说明，否则该响应是可缓存的。

10.3.2 301永久移动

已为所请求的资源分配了一个新的永久URI，并且此资源的任何将来的引用应该使用返回的URI之一。具有链接编辑功能的客户端应尽可能自动将对Request-URI的引用重新链接到服务器返回的一个或多个新引用。除非另有说明，否则该响应是可缓存的。

新的永久URI应该由响应中的Location字段给出。除非请求方法是HEAD，否则响应的实体应该包含一个带有指向新URI的超链接的短超文本注释。

如果收到301状态代码以响应GET或HEAD以外的请求，则用户代理不得自动重定向请求，除非用户可以确认，因为这可能会改变发出请求的条件。

注意：在自动重定向POST请求之后
      接收301状态代码，一些现有的HTTP / 1.0用户代理
      将错误地将其更改为GET请求。

10.3.3 302找到

请求的资源暂时驻留在不同的URI下。由于重定向有时可能会被更改，因此客户端应该继续使用Request-URI来处理将来的请求。如果由Cache-Control或Expires头字段指示，则此响应仅可缓存。

临时URI应该由响应中的Location字段给出。除非请求方法是HEAD，否则响应的实体应该包含一个带有指向新URI的超链接的短超文本注释。

如果收到302状态代码以响应GET或HEAD以外的请求，则用户代理不得自动重定向请求，除非用户可以确认，因为这可能会改变发出请求的条件。

注意：RFC 1945和RFC 2068指定不允许客户端
      更改重定向请求的方法。但是，大多数
      现有的用户代理实现将302视为303
      响应，无论如何都对位置字段值执行GET
      原始请求方法。状态代码303和307具有
      已添加到希望明确清楚哪些服务器的服务器
      对客户的反应是预期的。

10.3.4 303见其他

可以在不同的URI下找到对请求的响应，并且应该使用该资源上的GET方法检索。此方法主要用于允许输出POST激活的脚本以将用户代理重定向到选定的资源。新URI不是最初请求的资源的替代引用。303响应绝不能被缓存，但对第二个（重定向）请求的响应可能是可缓存的。

不同的URI应该由响应中的Location字段给出。除非请求方法是HEAD，否则响应的实体应该包含一个带有指向新URI的超链接的短超文本注释。

注意：许多pre-HTTP / 1.1用户代理不理解303
      状态。当与这样的客户端的互操作性是一个问题时，
      因为大多数用户代理会做出反应，所以可以使用302状态代码
      如此处针对303描述的302响应。

10.3.5 304未修改

如果客户端已执行条件GET请求并允许访问，但文档尚未修改，则服务器应该响应此状态代码。304响应必须不包含消息体，因此总是在头字段之后的第一个空行终止。

响应必须包括以下标头字段：

- 日期，除非第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使用代理

必须通过Location字段给出的代理访问所请求的资源。Location字段提供代理的URI。预计收件人将通过代理重复此单个请求。305响应必须只由原始服务器生成。

注意：RFC 2068不清楚305是否打算重定向a
      单个请求，仅由原始服务器生成。不
      观察这些限制会产生重大的安全后果。

10.3.7 306（未使用）

306状态代码用于规范的先前版本，不再使用，代码保留。

10.3.8 307临时重定向

请求的资源暂时驻留在不同的URI下。由于重定向有时可能会被更改，因此客户端应该继续使用Request-URI来处理将来的请求。如果由Cache-Control或Expires头字段指示，则此响应仅可缓存。

临时URI应该由响应中的Location字段给出。除非请求方法是HEAD，否则响应的实体应该包含一个带有指向新URI的超链接的短超文本注释，因为许多HTTP / 1.1前用户代理不理解307状态。因此，注释应该包含用户在新URI上重复原始请求所需的信息。

如果收到307状态代码以响应GET或HEAD以外的请求，则用户代理不得自动重定向请求，除非用户可以确认，因为这可能会改变发出请求的条件。

10.4客户端错误4xx

4xx类状态代码适用于客户端似乎有错误的情况。除了在响应HEAD请求时，服务器应该包括一个实体，其中包含错误情况的解释，以及它是临时或永久条件。这些状态代码适用于任何请求方法。用户代理应该向用户显示任何包含的实体。

如果客户端正在发送数据，则在服务器关闭输入连接之前，使用TCP的服务器实现应该小心确保客户端确认收到包含响应的数据包。如果客户端在关闭后继续向服务器发送数据，则服务器的TCP堆栈将向客户端发送重置数据包，这可能会擦除客户端未确认的输入缓冲区，然后HTTP应用程序才能读取和解释它们。

10.4.1 400错误请求

由于语法格式错误，服务器无法理解请求。客户端不应该在没有修改的情况下重复请求。

10.4.2 401未经授权

该请求需要用户身份验证。响应必须包含WWW-Authenticate头字段（第14.47节），其中包含适用于所请求资源的质询。客户端可以使用合适的Authorization头字段重复请求（第 14.8 节））。如果请求已包含授权凭据，则401响应表示已拒绝授权这些凭据。如果401响应包含与先前响应相同的挑战，并且用户代理已经尝试过至少一次认证，则应该向用户呈现响应中给出的实体，因为该实体可能包括相关的诊断信息。HTTP访问身份验证在“HTTP身份验证：基本和摘要访问身份验证”  [43]中进行了说明 。

10.4.3 402付款要求

此代码保留供将来使用。

10.4.4 403禁止

服务器理解请求，但拒绝履行请求。授权无效，请求不应重复。如果请求方法不是HEAD并且服务器希望公开为什么请求没有得到满足，那么它应该描述实体中拒绝的原因。如果服务器不希望将此信息提供给客户端，则可以使用状态代码404（未找到）。

10.4.5 404未找到

服务器未找到与Request-URI匹配的任何内容。没有说明该病症是暂时的还是永久性的。如果服务器通过一些内部可配置的机制知道旧资源永久不可用且没有转发地址，则应该使用410（Gone）状态代码。当服务器不希望确切地说明请求被拒绝的原因，或者没有其他响应适用时，通常会使用此状态代码。

10.4.6 405不允许的方法

请求行中指定的方法不允许由Request-URI标识的资源。响应必须包含一个Allow标头，其中包含所请求资源的有效方法列表。

10.4.7 406不可接受

由请求标识的资源仅能够根据请求中发送的接受报头生成具有不可接受的内容特征的响应实体。

除非它是HEAD请求，否则响应应该包括一个实体，其中包含可用实体特征和位置的列表，用户或用户代理可以从中选择最合适的实体特征和位置。实体格式由Content-Type头字段中给出的媒体类型指定。根据用户代理的格式和功能，可以自动选择最合适的选择。但是，该规范没有为这种自动选择定义任何标准。

注意：允许HTTP / 1.1服务器返回响应
      根据发送的接受标头不可接受
      请求。在某些情况下，这甚至可能比发送一个更好
      406回应。鼓励用户代理检查标题
      传入的响应以确定它是否可接受。

如果响应可能是不可接受的，则用户代理应该暂时停止接收更多数据并查询用户以决定进一步的操作。

10.4.8 407需要代理身份验证

此代码类似于401（未授权），但表示客户端必须首先使用代理进行身份验证。代理必须返回一个Proxy-Authenticate头字段（第 14.33 节），其中包含适用于所请求资源的代理的质询。客户端可以使用合适的代理授权头字段重复该请求（第 14.34 节）。HTTP访问身份验证在“HTTP身份验证：基本和摘要访问身份验证”  [43]中进行了说明 。

10.4.9 408请求超时

客户端在服务器准备等待的时间内没有产生请求。客户端可以在以后不经修改的情况下重复请求。

10.4.10 409冲突

由于与资源的当前状态冲突，无法完成请求。此代码仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许。响应机构应该包括足够的内容

用户识别冲突根源的信息。理想情况下，响应实体将包含足够的信息供用户或用户代理解决问题; 但是，这可能是不可能的，也不是必需的。

冲突最有可能发生在响应PUT请求时。例如，如果正在使用版本控制并且包含PUT的实体更改为与早期（第三方）请求所产生的资源冲突的资源，则服务器可能会使用409响应来指示它无法完成请求。在这种情况下，响应实体可能包含由响应Content-Type定义的格式的两个版本之间的差异列表。

10.4.11 410已经过去了

请求的资源在服务器上不再可用，并且不知道转发地址。预计这种情况将被视为永久性的。具有链接编辑功能的客户端应该在用户批准后删除对Request-URI的引用。如果服务器不知道或无法确定条件是否是永久性的，则应该使用状态代码404（未找到）。除非另有说明，否则该响应是可缓存的。

410响应主要用于通过通知接收方资源是故意不可用的以及服务器所有者希望移除到该资源的远程链接来辅助web维护的任务。这种事件对于限时，促销服务以及属于不再在服务器站点工作的个人的资源是常见的。没有必要将所有永久不可用的资源标记为“已消失”或将标记保留任何时间长度 - 这由服务器所有者自行决定。

10.4.12 411所需长度

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

10.4.13 412前提条件失败

在服务器上测试时，一个或多个请求标头字段中给出的前提条件被评估为false。该响应代码允许客户端在当前资源元信息（头字段数据）上放置前提条件，从而防止所请求的方法应用于除预期的资源之外的资源。

10.4.14 413请求实体太大

服务器拒绝处理请求，因为请求实体大于服务器愿意或能够处理的请求实体。服务器可以关闭连接以防止客户端继续请求。

如果条件是临时的，服务器应该包括一个Retry-After头字段，以指示它是临时的，以及客户端可以再次尝试的时间。

10.4.15 414 Request-URI太长

服务器拒绝为请求提供服务，因为Request-URI比服务器愿意解释的长。当客户端已经不正确地将POST请求转换为具有长查询信息的GET请求时，当客户端进入重定向的URI“黑洞”时（例如，重定向的URI前缀指向重定向），这种情况很可能发生。它本身的后缀，或者当服务器受到试图利用固定长度缓冲区来读取或操作Request-URI的某些服务器中存在的安全漏洞的客户端的攻击时。

10.4.16 415不支持的媒体类型

服务器拒绝为请求提供服务，因为请求的实体采用所请求方法的请求资源不支持的格式。

10.4.17 416请求的范围不满足

如果请求包含Range请求标头字段（第14.35节），则服务器应该返回带有此状态代码的响应，并且此字段中的范围说明符值都不会与所选资源的当前范围重叠，并且请求不会包括If-Range请求标头字段。（对于字节范围，这意味着所有byte-range-spec值的first-byte-pos大于所选资源的当前长度。）

当为字节范围请求返回此状态代码时，响应应该包括一个Content-Range实体头字段，指定所选资源的当前长度（参见 14.16 节 ）。此响应绝不能使用multipart / byteranges内容类型。

10.4.18 417期望失败

此服务器无法满足Expect请求标头字段（请参阅第14.20节）中给出的期望，或者，如果服务器是代理，则服务器明确证明下一跃点服务器无法满足请求。

10.5服务器错误5xx

以数字“5”开头的响应状态代码表示服务器知道它已经出错或无法执行请求的情况。除了在响应HEAD请求时，服务器应该包括一个实体，其中包含错误情况的解释，以及它是临时或永久条件。用户代理应该向用户显示任何包含的实体。这些响应代码适用于任何请求方法。

10.5.1 500内部服务器错误

服务器遇到意外情况，导致无法完成请求。

10.5.2 501未实施

服务器不支持完成请求所需的功能。当服务器无法识别请求方法并且无法为任何资源支持时，这是适当的响应。

10.5.3 502 Bad Gateway

服务器在充当网关或代理时，在尝试完成请求时从其访问的上游服务器收到无效响应。

10.5.4 503服务不可用

由于服务器的临时过载或维护，服务器当前无法处理请求。这意味着这是一个暂时的条件，经过一段时间的延迟后会得到缓解。如果已知，则可以在Retry-After报头中指示延迟的长度。如果没有给出Retry-After，客户端应该像处理500响应一样处理响应。

注意：503状态代码的存在并不意味着a
      服务器必须在变得过载时使用它。有些服务器可能希望
      简单地拒绝连接。

10.5.5 504网关超时

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

注意：实现者注意：已知某些已部署的代理
      DNS查找超时时返回400或500。

10.5.6 505不支持HTTP版本

服务器不支持或拒绝支持请求消息中使用的HTTP协议版本。服务器指示它不能或不愿意使用与客户端相同的主要版本来完成请求，如 3.1 节所述 ，除了此错误消息。响应应该包含一个实体，该实体描述了不支持该版本的原因以及该服务器支持的其他协议。

来自：https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html