状态码定义

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 描述或包含操作结果的实体；

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

10.2.2 201 创建

请求已完成并导致创建新资源。新创建的资源可以被响应实体中返回的 URI 引用，资源的最具体的 URI 由 Location 头字段给出。响应应该包括一个实体，其中包含资源特征和位置列表，用户或用户代理可以从中选择最合适的一个。实体格式由 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 节）指示
    此响应中包含的范围，或 multipart/byteranges
    Content-Type 包括每个部分的 Content-Range 字段。如果一个
    Content-Length 头域存在于响应中，它的
    值必须与实际发送的 OCTET 数量相匹配
    邮件正文。
  - 日期
  - ETag 和/或 Content-Location，如果标头已发送
    在对同一请求的 200 响应中
  - 过期、缓存控制和/或变化，如果字段值可能
    与之前任何相同的响应中发送的不同
    变体

如果 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 请求，否则响应应该包含一个包含资源特征和位置列表的实体，用户或用户代理可以从中选择最合适的一个。实体格式由 ContentType 标头字段中给出的媒体类型指定。取决于格式和能力

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

如果服务器有首选的表示形式，它应该在 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
  响应，对 Location 字段值执行 GET
  的原始请求方法。状态码 303 和 307 有
  为希望明确明确哪个服务器添加了
  期望客户的反应。

10.3.4 303 见其他

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

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

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

10.3.5 304 未修改

如果客户端已经执行了一个条件 GET 请求并且允许访问，但是文档没有被修改，服务器应该用这个状态码来响应。304 响应不能包含消息体，因此总是以标题字段之后的第一个空行终止。

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

  - 日期，除非第 14.18.1 节要求省略

如果无时钟源服务器遵守这些规则，并且代理和客户端将自己的 Date 添加到没有收到的任何响应中（如 [RFC 2068] 第14.19节已指定），则缓存将正确运行。

  - ETag 和/或 Content-Location，如果标头已发送
    在对同一请求的 200 响应中
  - 过期、缓存控制和/或变化，如果字段值可能
    与之前任何相同的响应中发送的不同
    变体

如果条件 GET 使用了强缓存验证器（参见第 13.3.3 节），则响应不应包含其他实体标头。否则（即条件 GET 使用弱验证器），响应不得包含其他实体标头；这可以防止缓存的实体主体和更新的标头之间的不一致。

如果 304 响应指示当前未缓存的实体，则缓存必须忽略响应并在没有条件的情况下重复请求。

如果缓存使用接收到的 304 响应来更新缓存条目，则缓存必须更新条目以反映响应中给出的任何新字段值。

10.3.6 305 使用代理

请求的资源必须通过 Location 字段给出的代理访问。Location 字段给出了代理的 URI。接收者应该通过代理重复这个单一的请求。305 响应必须只能由源服务器生成。

  注意：RFC 2068 并不清楚 305 旨在重定向
  单个请求，并且仅由源服务器生成。不是
  遵守这些限制会产生重大的安全后果。

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 未找到

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

10.4.6 405 方法不允许

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

10.4.7 406 不可接受

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

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

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

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

10.4.8 407 需要代理验证

此代码类似于 401（未授权），但表示客户端必须首先通过代理验证自己。代理必须返回一个 Proxy-Authenticate 头字段（第14.33节），其中包含适用于所请求资源的代理的质询。客户端可以使用合适的 Proxy-Authorization 头域（第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前置条件失败

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

10.4.14 413 请求实体太大

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

如果条件是临时的，服务器应该包含一个 Retry-After 头域来指示它是临时的，并且在什么时间之后客户端可以重试。

10.4.15 414 请求 URI 太长

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

10.4.16 415 不支持的媒体类型

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

10.4.17 416 请求的范围不满足

如果请求包含 Range 请求标头字段（第 14.35 节），并且此字段中的范围说明符值没有与所选资源的当前范围重叠，并且请求没有包括一个 If-Range 请求头字段。（对于字节范围，这意味着所有字节范围规范值的第一个字节位置都大于所选资源的当前长度。）

当为字节范围请求返回此状态代码时，响应应该包含一个 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 错误网关

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

10.5.4 503 服务不可用

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

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

10.5.5 504 网关超时

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

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

10.5.6 505 HTTP 版本不支持

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