10. Status Code Definitions (状态码定义)

以下描述了每个状态码，包括它可以跟随哪些方法的描述以及响应中所需的任何元信息。

10.1 Informational 1xx (信息性)

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

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

代理必须 (MUST) 转发 1xx 响应，除非代理与其客户端之间的连接已关闭，或除非代理本身请求生成 1xx 响应。（例如，如果代理在转发请求时添加"Expect: 100-continue"字段，则它不需要转发相应的 100 (Continue) 响应。）

10.1.1 100 Continue

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

10.1.2 101 Switching Protocols (切换协议)

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

仅当有利时才应该 (SHOULD) 切换协议。例如，切换到较新版本的 HTTP 比旧版本有利，当传送使用此类功能的资源时，切换到实时、同步协议可能是有利的。

10.2 Successful 2xx (成功)

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

10.2.1 200 OK

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

• GET - 响应中发送与请求的资源相对应的实体；
• HEAD - 响应中发送与请求的资源相对应的实体头字段，不包含任何消息主体；
• POST - 描述或包含操作结果的实体；
• TRACE - 包含由终端服务器接收的请求消息的实体。

10.2.2 201 Created (已创建)

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

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

10.2.3 202 Accepted (已接受)

请求已被接受处理，但处理尚未完成。请求最终可能会或可能不会被执行，因为在实际进行处理时可能不允许。没有从这样的异步操作重新发送状态码的功能。

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

10.2.4 203 Non-Authoritative Information (非权威信息)

实体头中返回的元信息不是来自源服务器的最终集，而是从本地或第三方副本收集的。呈现的集合可以 (MAY) 是原始版本的子集或超集。例如，包括关于资源的本地注释信息可能会导致源服务器已知的元信息的超集。仅当响应本来是 200 (OK) 时，才需要使用此响应码，并且仅在适当时使用。

10.2.5 204 No Content (无内容)

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

如果客户端是用户代理，它不应该 (SHOULD NOT) 更改其文档视图（导致发送请求的视图）。此响应主要旨在允许操作的输入发生而不导致用户代理的活动文档视图发生更改，尽管任何新的或更新的元信息都应该 (SHOULD) 应用于当前在用户代理的活动视图中的文档。

204 响应禁止 (MUST NOT) 包括消息主体，因此始终由头字段后的第一个空行终止。

10.2.6 205 Reset Content (重置内容)

服务器已完成请求，用户代理应该 (SHOULD) 重置导致发送请求的文档视图。此响应主要旨在允许通过用户输入进行操作的输入，然后清除给出输入的表单，以便用户可以轻松启动另一个输入操作。响应禁止 (MUST NOT) 包括实体。

10.2.7 206 Partial Content (部分内容)

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

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

• Content-Range 头字段（第 14.16 节）指示此响应中包含的范围，或包括每个部分的 Content-Range 字段的 multipart/byteranges Content-Type。如果响应中存在 Content-Length 头字段，其值必须 (MUST) 与消息主体中传输的八位字节的实际数量匹配。

• Date

• ETag 和/或 Content-Location，如果头会在对同一请求的 200 响应中发送

• Expires、Cache-Control 和/或 Vary，如果字段值可能与先前在该变体的任何响应中发送的字段值不同

如果 206 响应是使用强缓存验证器的条件请求的结果（参见第 13.3.3 节），则响应不应该 (SHOULD NOT) 包括其他实体头；这可以防止缓存的实体主体与更新的头之间的不一致。否则，响应必须 (MUST) 包括所有本来会在对同一请求的 200 (OK) 响应中返回的实体头。

如果 ETag 或 Last-Modified 头与先前从源服务器接收到的值不匹配，则缓存禁止 (MUST NOT) 将 206 响应与其他先前缓存的内容组合，必须 (MUST) 将部分响应视为完整的。

不支持 Range 和 Content-Range 头的缓存禁止 (MUST NOT) 缓存 206 (Partial) 响应。

10.3 Redirection 3xx (重定向)

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

注意：本规范的先前版本建议最多五次重定向。内容开发者应该意识到可能存在不遵守此建议的客户端。

10.3.1 300 Multiple Choices (多个选择)

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

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

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

10.3.2 301 Moved Permanently (永久移动)

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

新的永久 URI 应该 (SHOULD) 由响应中的 Location 字段给出。除非请求方法是 HEAD，否则响应的实体应该 (SHOULD) 包含指向新 URI 的超链接以及简短的注释。

如果 301 状态码在对 GET 或 HEAD 以外的请求的响应中接收到，则用户代理禁止 (MUST NOT) 自动重定向请求，除非用户可以确认，因为这可能会改变发出请求的条件。

注意：当在响应 POST 请求时自动重定向时，某些现有的 HTTP/1.0 用户代理会错误地将其更改为 GET 请求。

10.3.3 302 Found

请求的资源暂时驻留在不同的 URI 下。由于重定向有时可能会改变，客户端应该 (SHOULD) 继续使用 Request-URI 进行未来的请求。仅当由 Cache-Control 或 Expires 头字段指示时，此响应才可缓存。

临时 URI 应该 (SHOULD) 由响应中的 Location 字段给出。除非请求方法是 HEAD，否则响应的实体应该 (SHOULD) 包含指向新 URI 的超链接以及简短的注释。

如果 302 状态码在对 GET 或 HEAD 以外的请求的响应中接收到，则用户代理禁止 (MUST NOT) 自动重定向请求，除非用户可以确认，因为这可能会改变发出请求的条件。

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

10.3.4 303 See Other (查看其他)

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

应该通过响应中的 Location 字段给出不同的 URI。除非请求方法是 HEAD，否则响应的实体应该 (SHOULD) 包含指向新 URI 的超链接以及简短的注释。

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

10.3.5 304 Not Modified (未修改)

如果客户端已执行条件 GET 请求并且允许访问，但文档尚未修改，则服务器应该 (SHOULD) 以此状态码响应。304 响应禁止 (MUST NOT) 包含消息主体，因此始终由头字段后的第一个空行终止。

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

• Date，除非根据第 14.18.1 节中的规则，其省略是必需的

如果无时钟源服务器遵守这些规则，并且代理和客户端向其发送的任何 Date 头添加自己的 Date，则缓存将正确运行。

• ETag 和/或 Content-Location，如果对同一请求的 200 响应会包含它们
• Expires、Cache-Control 和/或 Vary，如果字段值可能与先前在该变体的任何响应中发送的值不同

如果条件 GET 使用强缓存验证器（参见第 13.3.3 节），则响应不应该 (SHOULD NOT) 包括其他实体头。否则（即，条件 GET 使用弱验证器），响应禁止 (MUST NOT) 包括其他实体头；这可以防止缓存的实体主体与更新的头之间的不一致。

如果 304 响应指示当前未缓存的实体，则缓存必须 (MUST) 忽略响应并重复请求而不使用条件。

如果缓存接收到 304 响应，该响应更新它当前缓存的缓存条目，则缓存必须 (MUST) 更新条目以反映响应中给出的任何新字段值。

10.3.6 305 Use Proxy (使用代理)

请求的资源必须 (MUST) 通过 Location 字段给出的代理访问。Location 字段给出代理的 URI。接收方期望重复此单个请求通过代理。305 响应必须 (MUST) 仅由源服务器生成。

注意：RFC 2068 未明确指定 305 旨在将单个请求重定向到代理。不适当地缓存 305 响应导致后续请求定向到该代理导致重大安全问题。

10.3.7 306 (Unused) (未使用)

306 状态码在规范的先前版本中使用，不再使用，并且代码是保留的。

10.3.8 307 Temporary Redirect (临时重定向)

请求的资源暂时驻留在不同的 URI 下。由于重定向可能会不时更改，客户端应该 (SHOULD) 继续使用 Request-URI 进行未来的请求。仅当由 Cache-Control 或 Expires 头字段指示时，此响应才可缓存。

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

如果 307 状态码在对 GET 或 HEAD 以外的请求的响应中接收到，则用户代理禁止 (MUST NOT) 自动重定向请求，除非用户可以确认，因为这可能会改变发出请求的条件。

10.4 Client Error 4xx (客户端错误)

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

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

10.4.1 400 Bad Request (错误请求)

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

10.4.2 401 Unauthorized (未授权)

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

10.4.3 402 Payment Required (需要付款)

此代码保留供将来使用。

10.4.4 403 Forbidden (禁止)

服务器理解请求，但拒绝完成它。授权将无济于事，并且不应该 (SHOULD NOT) 重复请求。如果请求方法不是 HEAD 并且服务器希望公开为什么请求未被完成，则它应该 (SHOULD) 在实体中描述拒绝的原因。如果服务器不希望将此信息提供给客户端，则可以改用状态码 404 (Not Found)。

10.4.5 404 Not Found (未找到)

服务器未找到与 Request-URI 匹配的任何内容。没有指示条件是临时的还是永久的。如果服务器通过某种内部可配置的机制知道旧资源永久不可用且没有转发地址，则应该 (SHOULD) 使用 410 (Gone) 状态码。此状态码通常用于服务器不希望准确透露请求被拒绝的原因，或当没有其他响应适用时。

10.4.6 405 Method Not Allowed (不允许的方法)

Request-Line 中指定的方法不允许用于 Request-URI 标识的资源。响应必须 (MUST) 包括 Allow 头，其中包含请求资源的有效方法列表。

10.4.7 406 Not Acceptable (不可接受)

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

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

注意：HTTP/1.1 服务器允许在无法提供可接受的响应时返回不可接受的响应。在这种情况下，用户代理应该 (SHOULD) 检查实体以确定对用户是否有用。

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

10.4.8 407 Proxy Authentication Required (需要代理身份验证)

此代码类似于 401 (Unauthorized)，但指示客户端必须首先使用代理进行身份验证。代理必须 (MUST) 返回 Proxy-Authenticate 头字段（第 14.33 节），其中包含适用于所请求资源的代理的质询。客户端可以 (MAY) 使用 Proxy-Authorization 头字段（第 14.34 节）重复请求。HTTP 访问身份验证在"HTTP 身份验证：基本和摘要访问身份验证"[43] 中解释。

10.4.9 408 Request Timeout (请求超时)

客户端没有在服务器准备等待的时间内生成请求。客户端可以 (MAY) 在以后的任何时间重复请求而不进行修改。

10.4.10 409 Conflict (冲突)

由于与资源的当前状态冲突，无法完成请求。此代码仅在预期用户可能能够解决冲突并重新提交请求的情况下允许。响应主体应该 (SHOULD) 包含足够的信息供用户识别冲突的来源。理想情况下，响应实体将包括足够的信息供用户或用户代理解决问题；但是，这可能是不可能的，并且不是必需的。

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

10.4.11 410 Gone (已失效)

请求的资源在服务器上不再可用，并且不知道转发地址。此条件预期是永久性的。具有链接编辑功能的客户端应该 (SHOULD) 删除对 Request-URI 的引用（如果可能）在用户批准后。如果服务器不知道或没有设施来确定条件是否永久，则应该 (SHOULD) 改用状态码 404 (Not Found)。除非另有说明，否则此响应是可缓存的。

410 响应主要旨在通过通知接收方资源故意不可用并且服务器所有者希望删除指向该资源的远程链接来协助网络维护的任务。这种事件在限时的促销服务和属于不再在源服务器的站点工作的个人的资源中很常见。没有必要将所有永久不可用的资源标记为"gone"或保留标记任何时间长度——这留给服务器所有者的判断。

10.4.12 411 Length Required (需要长度)

服务器拒绝在没有定义 Content-Length 的情况下接受请求。如果客户端将向请求消息添加包含消息主体长度的有效 Content-Length 头字段，则客户端可以 (MAY) 重复请求。

10.4.13 412 Precondition Failed (前提条件失败)

在服务器上测试时，请求头字段中给出的前提条件评估为 false。此状态码允许客户端对当前资源元信息（头字段数据）设置前提条件，从而防止请求的方法应用于除预期资源之外的资源。

10.4.14 413 Request Entity Too Large (请求实体太大)

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

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

10.4.15 414 Request-URI Too Long (请求URI太长)

服务器拒绝服务请求，因为 Request-URI 长于服务器愿意解释的长度。此罕见条件仅可能在以下情况下发生：当客户端错误地将 POST 请求转换为具有长查询信息的 GET 请求时，当客户端已陷入重定向的"黑洞"（例如，指向其自身后缀的重定向前缀）时，或当服务器受到试图利用某些服务器中存在的安全漏洞的客户端的攻击时，这些服务器使用固定长度缓冲区读取或操作 Request-URI。

10.4.16 415 Unsupported Media Type (不支持的媒体类型)

服务器拒绝服务请求，因为请求的实体的格式不受请求的方法的请求资源支持。

10.4.17 416 Requested Range Not Satisfiable (请求的范围无法满足)

应该 (SHOULD) 在请求包括 Range 请求头字段（第 14.35 节）时返回此状态码，并且范围指定符值中的任何范围值都不与所选资源的当前范围重叠，并且请求没有包括 If-Range 请求头字段。（对于字节范围，这意味着所有字节范围规范值的第一个字节位置大于所选资源的当前长度。）

当对字节范围返回此状态码时，响应应该 (SHOULD) 包括 Content-Range 实体头字段，指定所选资源的当前长度（参见第 14.16 节）。此响应禁止 (MUST NOT) 使用 multipart/byteranges content-type。

10.4.18 417 Expectation Failed (期望失败)

由 Expect 请求头字段（参见第 14.20 节）给出的期望无法由此服务器满足，或者，如果服务器是代理，服务器有明确的证据表明请求无法由下一跳服务器满足。

10.5 Server Error 5xx (服务器错误)

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

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 (服务不可用)

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

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

10.5.5 504 Gateway Timeout (网关超时)

服务器在充当网关或代理时，没有从它为了完成请求而需要访问的上游服务器及时接收响应。

注意：注意区分此状态码和 408 (Request Timeout)。

10.5.6 505 HTTP Version Not Supported (不支持的HTTP版本)

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