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

10.1 Information 1xx

这类状态代码表示临时响应，仅由 Status-Line 和可选头字段组成，并以空行结束。这类状态代码没有必要的头字段。由于 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 Switch Protocols

服务器理解并愿意遵守客户通过升级消息头字段（第 14.42 节）提出的改变该连接上正在使用的应用协议的请求。服务器将在结束 101 响应的空行后立即将协议切换到响应的升级头域所定义的协议。

只有在有利的情况下，才应该切换协议。例如，切换到较新版本的 HTTP 比旧版本有优势，而切换到实时、同步的协议可能在交付使用此类功能的资源时有优势。

10.2 Successful 2xx

这类状态代码表明客户的请求被成功接收、理解和接受。

10.2.1 200 OK

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

10.2.2 201 Created

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

201 响应可能包含一个 ETag 响应头字段，表明刚刚创建的请求的变体的实体标签的当前值，见第 14.19 节。

10.2.3 202 Accepted

该请求已被接受并进行处理，但处理尚未完成。 该请求最终可能被处理，也可能不被处理，因为当处理实际发生时，它可能被拒绝。没有设施可以从这样的异步操作中重新发送状态代码。

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

10.2.4 203 Non-Authoritative Information

实体头中返回的元信息不是来自源服务器的确定集合，而是从本地或第三方的副本中收集的。提交的集合可能是原始版本的子集或超集。例如，包括关于资源的本地注释信息可能会导致源服务器所知道的元信息的超集。使用这个响应代码不是必须的，只有在响应为 200（OK）的情况下才合适。

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 头字段（第 14.16 节），表示这个响应所包括的范围，或者一个multipart/byteranges Content-Type，包括每个部分的 Content-Range 字段。如果响应中存在 Content-Length 头字段，其值必须与消息正文中传输的 OCTET 的实际数量相匹配。
• Date
• 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（Partial）响应。

10.3 重定向 3xx

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

注意：本规范的前几个版本建议最多有五个重定向。内容开发者应该意识到，可能会有客户端实现这样一个固定的限制。

10.3.1 300 Multiple Choices

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

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

如果服务器有优先选择的表示法，它应该在 Location 字段中包括该表示法的特定 URI；用户代理可以使用 Location 字段的值来自动重定向。除非另有说明，这个响应是可缓存的。

10.3.2 301 Moved Permanently

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

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

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

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

10.3.3 302 Found

被请求的资源暂时停留在一个不同的 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 See Other

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

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

注意：许多前 HTTP/1.1 用户代理不理解 303 状态。当与这些客户端的互操作性是一个问题时，可以使用 302 状态代码来代替，因为大多数用户代理对 302 响应的反应与这里描述的 303 一样。

10.3.5 304 Not Modified

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

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

• Date，除非如第 14.18.1 节要求省略它。

如果无时钟的源服务器遵守这些规则，并且代理和客户将自己的 Date 添加到任何收到的没有 Date 的响应中（正如 [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 响应必须仅由源服务器生成。

注意：RFC 2068 没有明确指出 305 的目的是重定向单个请求，并且只由源服务器产生。不遵守这些限制会产生重大的安全后果。

10.3.7 306（Unused）

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

10.3.8 307 Temporary Redirect

被请求的资源暂时停留在一个不同的 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 Bad Request

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

10.4.2 401 Unauthorized

该请求需要用户认证。响应必须包括一个 WWW-Authenticate 头字段（第 14.47 节），其中包含适用于请求资源的挑战。客户端可以用一个合适的 Authorization 头字段（第 14.8 节）重复请求。如果请求中已经包含了 Authorization 凭证，那么 401 响应表明这些凭证的授权已被拒绝。如果 401 响应包含与先前响应相同的问题，并且用户代理已经至少尝试过一次认证，那么就应该向用户展示响应中给出的实体，因为该实体可能包括相关的诊断信息。HTTP 访问认证在 “HTTP Authentication: Basic and Digest Access Authentication” [43]。

10.4.3 402 Payment Required

这个代码是为将来使用而保留的。

10.4.4 403 Forbidden

服务器理解该请求，但拒绝满足它。授权将无济于事，而且该请求不应该被重复。如果请求方法不是 HEAD，并且服务器希望公开请求没有被满足的原因，它应该在实体中描述拒绝的原因。如果服务器不希望将这些信息提供给客户端，可以使用状态代码 404（Not Found）来代替。

10.4.5 404 Not Found

服务器没有发现任何与 Request-URI 匹配的东西。没有说明这种情况是暂时的还是永久的。如果服务器通过一些内部可配置的机制知道一个旧的资源是永久不可用的，并且没有转发地址，那么 410（Gone）状态代码应该被使用。当服务器不希望透露请求被拒绝的确切原因，或者没有其他响应时，通常使用这个状态代码。

10.4.6 405 Method Not Allowed

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

10.4.7 406 Not Acceptable

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

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

注意：HTTP/1.1 服务器被允许返回根据请求中发送的接受头信息而不可接受的响应。在某些情况下，这甚至可能比发送 406 响应更可取。我们鼓励用户代理检查传入响应的头字段，以确定它是否可以接受。

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

10.4.8 407 Proxy Authentication Required

这个代码类似于 401（Unauthorized），但表示客户端必须首先向代理机构认证自己。代理必须返回一个 Proxy-Authenticate 头字段（第 14.33 节），其中包含适用于所请求资源的代理的挑战。客户端可以用一个合适的 Proxy-Authorization 头字段（第 14.34 节）来重复请求。HTTP 访问认证在 “HTTP Authentication: Basic and Digest Access Authentication” [43]。

10.4.9 408 Request Timeout

客户端没有在服务器准备等待的时间内产生一个请求。客户端可以在以后的任何时间重复该请求而不做任何修改。

10.4.10 409 Conflict

由于与资源的当前状态有冲突，请求无法完成。这段代码只允许在预计用户能够解决冲突并重新提交请求的情况下使用。响应实体应该包括足够的信息，使用户能够识别冲突的来源。理想情况下，响应实体将包括足够的信息让用户或用户代理来解决这个问题；然而，这可能是不可能的，也不是必须的。

冲突最可能发生在对 PUT 请求的响应中。例如，如果正在使用版本管理，并且被 PUT 的实体包括对资源的修改，而这些修改与先前（第三方）的请求相冲突，服务器可能会使用 409 响应来表明它不能完成请求。在这种情况下，响应实体可能会包含一个两个版本之间的差异列表，其格式由响应的内容类型定义。

10.4.11 410 Gone

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

410 响应主要是为了协助网络维护的任务，通知接收者该资源是故意不可用的，并且服务器所有者希望删除该资源的远程链接。这样的事件对于有限时间、促销服务和属于不再在服务器站点工作的个人的资源来说是很常见的。没有必要将所有永久不可用的资源标记为 “消失”，也没有必要将标记保留多长时间—这要由服务器所有者决定。

10.4.12 411 Length Required

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

10.4.13 412 Precondition Failed

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

10.4.14 413 Request Entity Too Large

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

如果该条件是暂时的，服务器应该包括一个 Retry-After 头域，以表明它是暂时的，以及在什么时间之后客户端可以再次尝试。

10.4.15 414 Request-URI Too Long

服务器拒绝为该请求提供服务，因为 Request-URI 的长度超过了服务器愿意解释的范围。这种罕见的情况只有在以下情况下才可能发生：客户不适当地将 POST 请求转换为带有长查询信息的 GET 请求；客户陷入重定向的 URI “黑洞”（例如，重定向的 URI 前缀指向自身的后缀）；或者服务器受到客户的攻击，试图利用某些服务器中存在的安全漏洞，使用固定长度的缓冲区读取或操纵 Request-URI。

10.4.16 415 Unsupported Media Type

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

10.4.17 416 Request Range Not Satisfiable

如果一个请求包括一个 Range 请求头字段（第 14.35 节），并且该字段中的范围规格值没有一个与所选资源的当前范围重叠，并且该请求不包括 If-Range 请求头字段，那么服务器应该返回这个状态代码的响应。(对于字节范围来说，这意味着所有字节范围规格值的第一个字节位置都大于所选资源的当前长度）。

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

10.4.18 417 Expectation Failed

Expect 请求头字段（见第 14.20 节）中给出的期望不能被该服务器满足，或者，如果该服务器是一个代理，该服务器有明确的证据表明该请求不能被下一跳服务器满足。

10.5 Server Error 5xx

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

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

由于服务器的临时超载或维护，服务器目前无法处理该请求。其含义是，这是一个暂时性的状况，经过一段时间的延迟后会得到缓解。如果知道的话，延迟的长度可以用 Retry-After 头来表示。如果没有给出 Retry-After，客户端应该像处理 500 响应那样处理该响应。

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

10.5.5 504 Gateway Timeout

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

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

10.5.6 505 HTTP Version Not Support

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