状态代码定义

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

信息 1xx

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

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

代理必须转发 1xx 响应，除非代理与其客户端之间的连接已关闭，或者除非代理本身请求生成 1xx 响应。（例如，如果一个
代理在转发请求时添加了“Expect: 100-continue”字段，则不需要转发相应的100（继续）响应。）

1.1 100 继续
客户端应该继续它的请求。此临时响应用于通知客户端请求的初始部分已收到，但尚未被服务器拒绝。客户端应该继续发送请求的剩余部分，或者，如果请求已经完成，忽略这个响应。服务器必须在请求完成后发送最终响应。

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

协议应该仅在这样做有利时才进行切换。例如，切换到新版本的 HTTP 比旧版本更有优势，切换到实时同步协议在交付使用此类功能的资源时可能更有利。

成功的 2xx

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

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

GET 响应中发送与请求资源对应的实体；

HEAD 请求资源对应的实体头域在响应中发送，不带任何消息体；

POST 描述或包含操作结果的实体；

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

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

一个 201 响应可能包含一个 ETag 响应头字段，指示刚刚创建的请求变体的实体标签的当前值.

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

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

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

204 无内容
服务器已完成请求但不需要返回实体主体，并且可能想要返回更新的元信息。响应可以包含实体头形式的新的或更新的元信息，如果存在，应该与请求的变体相关联。

如果客户端是一个用户代理，它不应该改变导致请求被发送的文档视图。此响应主要是为了允许输入操作，而不会导致用户代理的活动文档视图发生变化，尽管任何新的或更新的元信息都应该应用于当前在用户代理的活动视图中的文档。

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

10.2.6 205 重置内容
服务器已经完成了请求，用户代理应该重置导致请求被发送的文档视图。此响应主要旨在允许通过用户输入进行操作的输入，然后清除给出输入的表单，以便用户可以轻松启动另一个输入操作。响应不得包含实体。

206 部分内容
服务器已完成对资源的部分 GET 请求。请求必须包含一个 Range 头域指示所需的范围，并且可以包含一个 If-Range 头域以使请求有条件。

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

  - Content-Range 标头字段指示
    此响应中包含的范围，或多部分/字节范围
    Content-Type 包括每个部分的 Content-Range 字段。如果一个
    Content-Length 头域存在于响应中，它的
    值必须与实际传输的 OCTET 数量相匹配
    邮件正文。
  - 日期
  - ETag 和/或 Content-Location，如果标头已经发送
    在对同一请求的 200 响应中
  - 过期、缓存控制和/或变化，如果字段值可能
    与之前针对相同的任何响应中发送的不同
    变体

如果 206 响应是使用强缓存验证器的 If-Range 请求的结果，则响应不应包含其他实体头。如果响应是使用弱验证器的 If-Range 请求的结果，则响应不得包含其他实体头；这可以防止缓存的实体主体和更新的标头之间出现不一致。否则，响应必须包括所有实体头，这些实体头将与对同一请求的 200（OK）响应一起返回。

如果 ETag 或 Last-Modified 标头不完全匹配，则缓存不得将 206 响应与其他先前缓存的内容组合在一起.

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

重定向 3xx

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

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

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

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

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

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

301 永久移动
被请求的资源已经被分配了一个新的永久 URI，以后对该资源的任何引用都应该使用返回的 URI 之一。在可能的情况下，具有链接编辑功能的客户端应该自动将请求 URI 的引用重新链接到服务器返回的一个或多个新引用。除非另有说明，否则此响应是可缓存的。

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

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

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

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

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

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

  注意：RFC 1945 和 RFC 2068 指定不允许客户端
  更改重定向请求的方法。然而，大多数
  现有的用户代理实现将 302 视为 303
  响应，对 Location 字段值执行 GET，不管
  原始请求方法。状态码 303 和 307 有
  为希望明确说明哪些服务器添加了
  期待客户的反应。

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

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

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

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

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

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

如果无时钟源服务器遵守这些规则，并且代理和客户端将他们自己的日期添加到任何没有收到的响应中，缓存将正确运行。

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

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

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

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

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

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

306（未使用）
306 状态码在之前版本的规范中使用过，不再使用，保留该码。

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

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

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

客户端错误 4xx

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

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

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

401 未授权
该请求需要用户身份验证。响应必须包含一个 WWW-Authenticate 头域，其中包含适用于所请求资源的质询。客户端可以使用合适的 Authorization 头字段重复请求。如果请求已包含授权凭据，则 401 响应指示对这些凭据的授权已被拒绝。如果 401 响应包含与先前响应相同的质询，并且用户代理已经至少尝试过一次身份验证，那么应该向用户呈现响应中给出的实体，因为该实体可能包含相关的诊断信息。HTTP 访问身份验证在“HTTP 身份验证：基本和摘要式访问身份验证” 中进行了解释。

402 需要付款
此代码保留供将来使用。

403 禁止
服务器理解请求，但拒绝满足它。授权无济于事，不应重复该请求。如果请求方法不是 HEAD 并且服务器希望公开请求未完成的原因，它应该在实体中描述拒绝的原因。如果服务器不想让客户端可以使用此信息，则可以使用状态代码 404（未找到）来代替。

404 未找到
服务器未找到任何与请求 URI 匹配的内容。没有说明这种情况是暂时的还是永久性的。如果服务器通过某些内部可配置机制知道旧资源永久不可用且没有转发地址，则应使用 410（消失）状态代码。当服务器不想透露请求被拒绝的确切原因时，或者当没有其他响应适用时，通常使用此状态代码。

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

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

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

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

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

10.4.8 407 需要代理认证
此代码类似于 401（未授权），但表示客户端必须首先向代理进行身份验证。代理必须返回一个 Proxy-Authenticate 头字段，其中包含适用于所请求资源的代理的质询。客户端可以使用合适的 Proxy-Authorization 头域重复请求。HTTP 访问身份验证在“HTTP 身份验证：基本和摘要式访问身份验证” 。

408 请求超时
客户端没有在服务器准备等待的时间内产生请求。客户端可以在以后的任何时间不加修改地重复请求。

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

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

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

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

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

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

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

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

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

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

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

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

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

417 期望失败
该服务器无法满足在 Expect 请求标头字段中给出的期望，或者，如果服务器是代理，则该服务器有明确的证据表明该请求无法被下一跳服务器满足.

服务器错误 5xx

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

500 内部服务器错误
服务器遇到意外情况，无法完成请求。

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

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

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

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

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

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

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

本文链接:https://www.xxhzm.cn/index.php/archives/94/