15. Status Codes (状态码)

响应的状态码 (Status Code) 是一个三位数的整数代码, 用于描述请求的结果和响应的语义, 包括请求是否成功以及包含了什么内容 (如果有的话)。所有有效的状态码都在 100 到 599 的范围内 (包括边界值)。

状态码的第一位数字定义了响应的类别 (class)。后两位数字没有任何分类作用。第一位数字有五个可能的值:

1xx (Informational, 信息性): 已接收请求, 正在继续处理
2xx (Successful, 成功): 请求已成功接收、理解并接受
3xx (Redirection, 重定向): 需要采取进一步的操作才能完成请求
4xx (Client Error, 客户端错误): 请求包含错误的语法或无法被满足
5xx (Server Error, 服务器错误): 服务器未能满足一个明显有效的请求

HTTP 状态码是可扩展的。客户端不需要理解所有已注册状态码的含义, 尽管这样的理解显然是理想的。然而, 客户端必须 (MUST) 理解任何状态码的类别 (如第一位数字所示), 并将无法识别的状态码视为等同于该类别的 x00 状态码。

例如, 如果客户端收到一个无法识别的状态码 471, 它可以从第一位数字看出其请求出了问题, 并将响应视为收到了 400 (Bad Request, 错误请求) 状态码。响应消息通常会包含一个表示 (representation) 来解释该状态。

100..599 范围之外的值是无效的。实现通常会使用该范围之外的三位数整数值 (即 600..999) 用于非 HTTP 状态的内部通信 (例如, 库错误)。收到具有无效状态码的响应的客户端应该 (SHOULD) 将该响应处理为具有 5xx (Server Error, 服务器错误) 状态码。

单个请求可以具有多个关联的响应: 零个或多个状态码在 "informational" (信息性, 1xx) 范围内的 "interim" (中间, 非最终) 响应, 然后是恰好一个状态码在其他范围之一中的 "final" (最终) 响应。

15.1. Overview of Status Codes (状态码概述)

下面列出的状态码在本规范中定义。此处列出的原因短语 (reason phrases) 仅是建议 -- 它们可以被本地等价物替换或完全省略, 而不影响协议。

具有被定义为启发式可缓存 (heuristically cacheable) 的状态码的响应 (例如, 本规范中的 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414 和 501) 可以被缓存使用启发式过期重用, 除非方法定义或显式缓存控制另有说明 [CACHING]; 所有其他状态码不是启发式可缓存的。

本规范范围之外的其他状态码已被指定用于 HTTP。所有此类状态码都应该 (ought to) 在 "Hypertext Transfer Protocol (HTTP) Status Code Registry" (超文本传输协议 (HTTP) 状态码注册表) 中注册, 如 Section 16.2 中所述。

15.2. Informational 1xx (信息性 1xx)

1xx (Informational, 信息性) 类别的状态码表示一个中间响应 (interim response), 用于在完成请求的操作并发送最终响应之前传达连接状态或请求进度。由于 HTTP/1.0 没有定义任何 1xx 状态码, 服务器绝对不能 (MUST NOT) 向 HTTP/1.0 客户端发送 1xx 响应。

1xx 响应由标头部分 (header section) 的结束终止; 它不能包含内容 (content) 或尾部 (trailers)。

客户端必须 (MUST) 能够解析在最终响应之前收到的一个或多个 1xx 响应, 即使客户端不期望收到。用户代理可以 (MAY) 忽略意外的 1xx 响应。

代理必须 (MUST) 转发 1xx 响应, 除非代理本身请求了 1xx 响应的生成。例如, 如果代理在转发请求时添加了 "Expect: 100-continue" 标头字段, 则它不需要转发相应的 100 (Continue) 响应。

15.2.1. 100 Continue (100 继续)

100 (Continue, 继续) 状态码表示请求的初始部分已被接收且尚未被服务器拒绝。服务器打算在请求被完全接收并处理后发送最终响应。

当请求包含一个 Expect 标头字段且该字段包含 100-continue 期望时, 100 响应表示服务器希望接收请求内容, 如 Section 10.1.1 中所述。客户端应该 (ought to) 继续发送请求并丢弃 100 响应。

如果请求不包含包含 100-continue 期望的 Expect 标头字段, 则客户端可以简单地丢弃此中间响应。

15.2.2. 101 Switching Protocols (101 切换协议)

101 (Switching Protocols, 切换协议) 状态码表示服务器理解并愿意通过 Upgrade 标头字段 (Section 7.8) 遵守客户端的请求, 以更改此连接上正在使用的应用协议。服务器必须 (MUST) 在响应中生成一个 Upgrade 标头字段, 指示在此响应之后将生效的协议。

假定服务器仅在有利时才会同意切换协议。例如, 切换到较新版本的 HTTP 可能比旧版本更有利, 并且在传递使用此类功能的资源时, 切换到实时同步协议可能更有利。

15.3. Successful 2xx (成功 2xx)

2xx (Successful, 成功) 类别的状态码表示客户端的请求已成功接收、理解并接受。

15.3.1. 200 OK (200 成功)

200 (OK, 成功) 状态码表示请求已成功。在 200 响应中发送的内容取决于请求方法。对于本规范定义的方法, 内容的预期含义可以总结为:

Request Method	Response content is a representation of: (响应内容是以下内容的表示)
GET	the target resource (目标资源)
HEAD	the target resource, like GET, but without transferring the representation data (目标资源, 类似 GET, 但不传输表示数据)
POST	the status of, or results obtained from, the action (操作的状态或从操作获得的结果)
PUT, DELETE	the status of the action (操作的状态)
OPTIONS	communication options for the target resource (目标资源的通信选项)
TRACE	the request message as received by the server returning the trace (服务器返回跟踪时接收到的请求消息)

Table 6

除了对 CONNECT 的响应之外, 200 响应预期包含消息内容, 除非消息帧明确指示内容的长度为零。如果请求的某些方面表示成功时不需要内容, 则源服务器应该 (ought to) 改为发送 204 (No Content, 无内容) 响应。对于 CONNECT, 没有内容, 因为成功的结果是一个隧道, 该隧道在 200 响应标头部分之后立即开始。

200 响应是启发式可缓存的; 即, 除非方法定义或显式缓存控制另有说明 (参见 [CACHING] 的 Section 4.2.2)。

在对 GET 或 HEAD 的 200 响应中, 源服务器应该 (SHOULD) 发送所选表示的任何可用验证器字段 (Section 8.8), 优先同时使用强实体标签和 Last-Modified 日期。

在对状态改变方法的 200 响应中, 响应中发送的任何验证器字段 (Section 8.8) 传达由于成功应用请求语义而形成的新表示的当前验证器。请注意, PUT 方法 (Section 9.3.4) 具有可能排除发送此类验证器的额外要求。

15.3.2. 201 Created (201 已创建)

201 (Created, 已创建) 状态码表示请求已被满足, 并导致创建了一个或多个新资源。请求创建的主要资源由响应中的 Location 标头字段标识, 或者如果未收到 Location 标头字段, 则由目标 URI 标识。

201 响应内容通常描述并链接到创建的资源。响应中发送的任何验证器字段 (Section 8.8) 传达请求创建的新表示的当前验证器。请注意, PUT 方法 (Section 9.3.4) 具有可能排除发送此类验证器的额外要求。

15.3.3. 202 Accepted (202 已接受)

202 (Accepted, 已接受) 状态码表示请求已被接受处理, 但处理尚未完成。请求最终可能会或可能不会被执行, 因为在实际处理发生时可能会被禁止。HTTP 中没有从异步操作重新发送状态码的机制。

202 响应是有意不承诺的 (intentionally noncommittal)。其目的是允许服务器接受对某个其他进程的请求 (可能是每天仅运行一次的面向批处理的进程), 而不要求用户代理与服务器的连接持续到进程完成。与此响应一起返回的表示应该 (SHOULD) 描述请求的当前状态, 并指向 (或嵌入) 状态监视器, 该监视器可以向用户提供关于何时完成请求的一些估计。

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

203 (Non-Authoritative Information, 非权威信息) 状态码表示请求成功, 但附带的表示是由转换代理从源服务器的 200 (OK) 响应传送的, 而不是由源服务器发送或验证的。

除了代码和原因短语之外, 203 响应与 200 响应相同。

此状态码的目的是允许转换代理 (例如, 在 Section 7.7 中定义的 "Web 加速器") 将 200 (OK) 响应更改为 203 (Non-Authoritative Information) 响应来通知接收者表示已被修改。响应的表示已经以某种方式修改 (如图像转码) 以满足代理的需求或限制, 同时仍保留足够的语义信息让用户代理仍然理解和使用。

203 响应是启发式可缓存的; 即, 除非方法定义或显式缓存控制另有说明 (参见 [CACHING] 的 Section 4.2.2)。

15.3.5. 204 No Content (204 无内容)

204 (No Content, 无内容) 状态码表示服务器已成功满足请求, 并且响应内容中没有要发送的额外内容。响应中的元数据是指在请求处理之前应用时目标资源及其所选表示的元数据。

例如, 如果在 PUT 请求中接收到 204 状态码, 并且响应包含 ETag 字段, 则该实体标签是放置在目标资源上的新表示的实体标签。

204 响应允许服务器指示该操作已成功应用于目标资源, 而无需暗示用户代理应该离开其当前的 "文档视图" (如果有的话)。服务器假定用户代理将为其用户提供对自己操作成功的某种指示, 根据其自己的界面, 并应用任何新的或更新的元数据值, 这些值是根据响应提供的。

例如, 204 状态码通常与文档编辑界面一起使用, 这些界面与 "保存" 操作相对应, 使得保存的文档仍保留为用户代理的当前文档视图。它也经常与诸如 HTML 表单提交之类的界面一起使用, 用于仅导致目标资源的值更新的操作, 而无需相应的更改用户代理的当前文档视图。

204 响应由标头部分后的第一个空行终止; 它不能包含内容。

204 响应是启发式可缓存的; 即, 除非方法定义或显式缓存控制另有说明 (参见 [CACHING] 的 Section 4.2.2)。

15.3.6. 205 Reset Content (205 重置内容)

205 (Reset Content, 重置内容) 状态码表示服务器已成功满足请求, 并希望用户代理重置导致发送请求的 "文档视图"。

此响应旨在支持常见的数据输入用例, 用户接收支持数据输入的内容 (表单, 记事本, 画布等), 输入或操作该数据, 导致提交请求, 然后数据输入机制被重置以供下一个输入, 以便用户可以轻松启动另一个输入操作。

由于 205 状态码暗示不应提供任何额外内容, 因此服务器绝对不能 (MUST NOT) 在 205 响应中生成内容。

15.3.7. 206 Partial Content (206 部分内容)

206 (Partial Content, 部分内容) 状态码表示服务器正在成功满足对目标资源的范围请求, 通过在响应内容中传输与请求的 Range 标头字段 (Section 14.2) 指定的一个或多个范围相对应的所选表示的一个或多个部分。

如果正在传输单个部分, 生成 206 响应的服务器必须 (MUST) 生成一个 Content-Range 标头字段, 描述包含在此响应正文中的范围以及完整所选表示长度 (参见 Section 14.4)。

例如:

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

... 26012 bytes of partial image data ...

如果正在传输多个部分, 生成 206 响应的服务器必须 (MUST) 生成一个 "multipart/byteranges" 内容 (如 Appendix B.2 中定义的), 并且必须 (MUST) 在每个正文部分中发送相应部分的字段。如果所选表示在生成 206 响应时具有 Content-Type 标头字段, 则该字段值必须 (MUST) 包含在正文的每个部分中。

例如:

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000

...the first range...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000

...the second range
--THIS_STRING_SEPARATES--

当正在传输多个范围时, 服务器应该 (SHOULD) 按照它们出现在请求的 Range 标头字段中的相同顺序发送这些范围。

客户端不能依赖于接收与其请求中指定的范围相同的范围, 因为并非所有服务器都支持多部分/字节范围 (multipart/byteranges) 响应。客户端必须 (MUST) 检查每个部分的 Content-Range 标头字段以确定该部分包含的范围。

206 响应是启发式可缓存的; 即, 除非方法定义或显式缓存控制另有说明 (参见 [CACHING] 的 Section 4.2.2)。

15.3.7.1. Single Part (单部分)

如果单个部分被选择用于传输, 服务器必须 (MUST) 生成一个 Content-Range 标头字段 (Section 14.4), 描述包含的范围, 并且内容是一个内容流 (payload stream), 其长度等于该范围的长度。

例如:

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

... 26012 bytes of partial image data ...

15.3.7.2. Multiple Parts (多部分)

如果多个部分被选择用于传输, 服务器必须 (MUST) 生成一个 "multipart/byteranges" 内容 (如 Appendix B.2 中定义的)。

为了避免与单部分 206 响应混淆, 服务器绝对不能 (MUST NOT) 为单个范围生成 multipart/byteranges 响应。客户端在接收到 multipart/byteranges 响应时, 必须 (MUST) 检查该响应是否由于仅包含一个正文部分而实际上是单个部分。

当正在传输多个范围时, 服务器应该 (SHOULD) 按照它们出现在请求的 Range 标头字段中的相同顺序发送这些范围, 排除那些被认为不可满足或与另一个范围合并的范围。多部分/字节范围响应中的每个正文部分必须 (MUST) 包含一个 Content-Range 标头字段, 指示该正文部分封装的范围。如果所选表示将具有 Content-Type 标头字段 (如果它作为 200 (OK) 响应发送), 则服务器应该 (SHOULD) 在 multipart/byteranges 响应的每个正文部分中包含该 Content-Type 字段。

例如:

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000

...the first range...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000

...the second range
--THIS_STRING_SEPARATES--

当客户端请求多个范围时, 服务器可以 (MAY) 合并任何重叠的或由小于或等于合并表示的重叠开销的间隙分隔的范围。由于典型的开销在大约 80 字节之间 (对于内联单部分范围) 和 400 字节 (对于多部分/字节范围边界和每个部分的字段), 取决于所选表示的元数据, 最好发送相同的数据作为一个范围, 而不是发送多个带有很少数据的小范围。

15.3.7.3. Combining Parts (组合部分)

不支持 multipart/byteranges 内容的响应生成器可以 (MAY) 通过发送与多部分范围集重叠或相邻的单个部分来满足范围请求。通过在 206 (Partial Content) 响应中发送仅涵盖部分请求范围的 Content-Range 来完成此操作。

接收到请求未满足其原始范围请求的 206 (Partial Content) 响应的客户端可以 (MAY) 检查 Content-Range 以确定已接收的内容。客户端可以 (MAY) 发出额外的范围请求以获取剩余内容。

15.4. Redirection 3xx (重定向 3xx)

3xx (Redirection, 重定向) 类别的状态码表示用户代理需要采取进一步的操作才能满足请求。重定向可能有多种类型。

在响应头中有几个具有特殊含义的字段, 可用于改变重定向处理:

Location 标头字段 (Section 10.2.2) 用于重定向收件人到一个不同于请求目标 URI 的位置以完成请求或标识新资源。
重定向可能是暂时的 (由 302 (Found) 和 307 (Temporary Redirect) 状态码表示) 或永久的 (由 301 (Moved Permanently) 和 308 (Permanent Redirect) 状态码表示)。在某些情况下, 状态码的选择会影响客户端对后续请求的方法选择。

用户代理可以 (MAY) 自动跟随 Location 字段值中的重定向引用, 即使特定的重定向状态码不被理解, 前提是它可以理解 (至少) 一般的重定向类别 (3xx)。自动重定向需要小心, 因为它可能存在安全后果。

注意: 如果未提供位置, 则用户代理可能会提供其自己的诊断信息。

15.4.1. 300 Multiple Choices (300 多种选择)

300 (Multiple Choices, 多种选择) 状态码表示目标资源具有多个表示, 每个表示都有其自己的更特定的标识符, 并且正在提供关于备选方案的信息, 以便用户 (或用户代理) 可以选择首选表示, 通过将其请求重定向到一个或多个这些标识符。换句话说, 服务器希望用户代理从列表中进行反应性内容协商 (Section 12.1)。

如果服务器有首选的表示选择, 则服务器应该 (SHOULD) 生成包含首选选择的 URI 引用的 Location 标头字段。用户代理可以 (MAY) 使用 Location 字段值进行自动重定向。

对于没有可用内容协商形式的请求, 300 响应应该 (SHOULD) 包含一个列表, 该列表包含资源特征和地址的表示, 从中用户或用户代理可以选择最合适的一个。服务器可以 (MAY) 根据请求的标头字段选择表示格式。使用这些字段进行服务器驱动的内容协商的规范在 Section 12.1 中定义。

300 响应是启发式可缓存的; 即, 除非方法定义或显式缓存控制另有说明 (参见 [CACHING] 的 Section 4.2.2)。

注意: 历史上, 300 状态码的原始含义是 "Multiple Choices" (多种选择)。然而, 实际使用表明, 客户端不期望处理多个可能的响应, 并且实际上许多 3xx 状态码会触发相同的行为。因此, 除非实现明确知道客户端期望并能够处理多种选择, 否则建议不要使用 300 状态码。

15.4.2. 301 Moved Permanently (301 永久移动)

301 (Moved Permanently, 永久移动) 状态码表示目标资源已被分配新的永久 URI, 并且将来对此资源的任何引用应该 (SHOULD) 使用附带的 URI 之一。拥有链接编辑能力的客户端应该 (SHOULD) 在可能的情况下自动将对目标 URI 的引用重新链接到服务器在 Location 字段中发送的一个或多个新引用。

服务器应该 (SHOULD) 在响应中生成一个 Location 标头字段, 该字段包含对目标资源新 URI 的首选 URI 引用。用户代理可以 (MAY) 使用 Location 字段值进行自动重定向。服务器的响应内容通常包含一个带有指向新 URI 的超链接的简短超文本注释。

注意: 出于历史原因, 用户代理可能 (MAY) 将后续请求的请求方法从 POST 更改为 GET。如果不希望出现此行为, 则应使用 308 (Permanent Redirect, 永久重定向) 状态码。

301 响应是启发式可缓存的; 即, 除非方法定义或显式缓存控制另有说明 (参见 [CACHING] 的 Section 4.2.2)。

15.4.3. 302 Found (302 已找到)

302 (Found, 已找到) 状态码表示目标资源暂时位于不同的 URI 下。由于重定向有时可能会更改, 客户端应该 (SHOULD) 继续为将来的请求使用有效的请求 URI。

服务器应该 (SHOULD) 在响应中生成一个 Location 标头字段, 该字段包含对不同 URI 的 URI 引用。用户代理可以 (MAY) 使用 Location 字段值进行自动重定向。服务器的响应内容通常包含一个带有指向不同 URI 的超链接的简短超文本注释。

注意: 出于历史原因, 用户代理可能 (MAY) 将后续请求的请求方法从 POST 更改为 GET。如果不希望出现此行为, 则应使用 307 (Temporary Redirect, 临时重定向) 状态码。

15.4.4. 303 See Other (303 查看其他)

303 (See Other, 查看其他) 状态码表示服务器正在将用户代理重定向到不同的资源, 如 Location 标头字段中的 URI 所指示, 该资源旨在提供对原始请求的间接响应。用户代理可以 (MAY) 对 Location 字段值执行检索请求 (使用 GET 或 HEAD 方法), 而不管原始请求方法如何, 并可以 (MAY) 使用其结果来满足原始请求。

除了 HEAD 请求之外, 303 响应应该 (SHOULD) 包含一个简短的超文本注释, 其中包含指向 Location 字段中提供的 URI 的超链接。

用户代理的主要用途是让用户代理可以将表示提交的 POST 操作输出重定向到只能使用 GET 检索的资源, 以允许该输出表示被书签标记, 存储以供将来使用, 等等, 以及避免如果用户尝试刷新 POST 响应可能发生的意外副作用。

注意: 多个 HTTP 方法的响应可能导致 303 重定向, 但只有 POST 处理的结果提供了有意义的语义用于书签或提供独立访问。

303 响应默认不可缓存; 即, 除非方法定义或显式缓存控制另有说明 (参见 [CACHING] 的 Section 4.2.2)。

15.4.5. 304 Not Modified (304 未修改)

304 (Not Modified, 未修改) 状态码表示条件 GET 或 HEAD 请求已被接收, 并且如果条件评估为 false, 将导致 200 (OK) 响应。换句话说, 服务器不需要传输目标资源的表示, 因为请求指示客户端 (已经具有有效的表示) 只想检查该表示是否是当前的, 并且验证表明它确实是当前的。因此, 所发送的是没有消息内容的响应, 只有必要的标头字段来指示相对于先前接收到的表示的更新。

生成 304 响应的服务器必须 (MUST) 生成以下标头字段中的任何一个, 如果该相同字段会在 200 (OK) 响应中发送到相同请求: Cache-Control, Content-Location, Date, ETag, Expires, 和 Vary。

由于 304 响应的目标是最小化信息传输, 服务器不应该 (SHOULD NOT) 为该响应生成表示元数据, 除非该元数据在先前的响应中发送后已更改; 相反, 服务器应该 (SHOULD) 仅在 304 响应中发送那些自上次响应以来已更改的表示元数据字段。

对 304 响应的要求已被故意设计为指导缓存更新其缓存条目, 而不是为其客户端生成全新的响应。然而, 缓存可能由于实现细节而需要进行该操作。

304 响应由标头部分后的第一个空行终止; 它不能包含内容。

304 响应必须 (MUST) 包含一个 Date 标头字段 (参见 Section 6.6.1), 除非源服务器没有时钟。

如果接收 304 响应的客户端在其缓存条目中具有表示, 则客户端应该 (SHOULD) 使用 304 响应更新或替换该表示。

15.4.6. 305 Use Proxy (305 使用代理)

305 (Use Proxy, 使用代理) 状态码在 RFC 7231 的先前版本中定义, 并且现在已弃用 (Appendix B)。

15.4.7. 306 (Unused) (306 未使用)

306 状态码在 HTTP/1.1 规范的先前版本中定义, 不再使用, 并且代码是保留的。

15.4.8. 307 Temporary Redirect (307 临时重定向)

307 (Temporary Redirect, 临时重定向) 状态码表示目标资源暂时位于不同的 URI 下, 并且用户代理在向该 URI 发出自动重定向时绝对不能 (MUST NOT) 更改请求方法。

由于重定向可以随时间而改变, 客户端应该 (SHOULD) 继续为将来的请求使用原始有效的请求 URI。

15.4.9. 308 Permanent Redirect (308 永久重定向)

308 (Permanent Redirect, 永久重定向) 状态码表示目标资源已被分配新的永久 URI, 并且将来对此资源的任何引用应该 (SHOULD) 使用附带的 URI 之一。拥有链接编辑能力的客户端应该 (SHOULD) 在可能的情况下自动将对有效请求 URI 的引用重新链接到服务器在 Location 标头字段中发送的一个或多个新引用。

308 响应是启发式可缓存的; 即, 除非方法定义或显式缓存控制另有说明 (参见 [CACHING] 的 Section 4.2.2)。

注意: 308 状态码类似于 301 (Moved Permanently), 除了它不允许将请求方法从 POST 更改为 GET。

15.5. Client Error 4xx (客户端错误 4xx)

4xx (Client Error, 客户端错误) 类别的状态码表示客户端似乎犯了错误。除了在响应 HEAD 请求时之外, 服务器应该 (SHOULD) 发送包含对错误情况的解释以及它是暂时情况还是永久情况的表示。这些状态码适用于任何请求方法。用户代理应该 (SHOULD) 向用户显示任何包含的表示。

15.5.1. 400 Bad Request (400 错误请求)

400 (Bad Request, 错误请求) 状态码表示由于被认为是客户端错误的内容 (例如, 格式错误的请求语法, 无效的请求消息帧或欺骗性的请求路由), 服务器无法或不会处理请求。

15.5.2. 401 Unauthorized (401 未授权)

401 (Unauthorized, 未授权) 状态码表示请求尚未应用, 因为它缺少对目标资源的有效身份验证凭据。生成 401 响应的服务器必须 (MUST) 发送包含至少一个适用于目标资源的挑战的 WWW-Authenticate 标头字段 (Section 11.6.1)。

如果请求包含身份验证凭据, 则 401 响应表示已拒绝对这些凭据的授权。用户代理可以 (MAY) 使用新的或替换的 Authorization 标头字段 (Section 11.6.2) 重复请求。如果 401 响应包含与先前响应相同的挑战, 并且用户代理已经尝试了至少一次身份验证, 则用户代理应该 (SHOULD) 向用户呈现附带的表示, 因为它通常包含相关的诊断信息。

15.5.3. 402 Payment Required (402 需要付款)

402 (Payment Required, 需要付款) 状态码是保留的, 供将来使用。

15.5.4. 403 Forbidden (403 禁止)

403 (Forbidden, 禁止) 状态码表示服务器理解请求但拒绝满足它。想要公开请求被拒绝原因的服务器可以 (MAY) 在响应内容中描述该原因 (如果有的话)。

如果请求中提供了身份验证凭据, 则服务器认为它们不足以授予访问权限。客户端不应该 (SHOULD NOT) 使用相同的凭据自动重复请求。客户端可以 (MAY) 使用新的或不同的凭据重复请求。然而, 包含凭据的请求可能会因与凭据无关的原因而被禁止。

具有活动会话的认证用户可能会收到 403 响应, 表明在所选表示的安全策略下, 客户端的凭据不足以访问目标资源, 例如保护隐私的应用程序实现 REQUIRED_PURPOSE 注释 [RFC9111, Section 5.7.10]。

15.5.5. 404 Not Found (404 未找到)

404 (Not Found, 未找到) 状态码表示源服务器没有找到目标资源的当前表示, 或者不愿意透露存在一个表示。404 状态码不指示此缺少表示是暂时的还是永久的; 如果源服务器知道, 通过某种可配置的机制, 条件可能是永久的, 则应该使用 410 (Gone, 已消失) 状态码而不是 404。

404 响应是启发式可缓存的; 即, 除非方法定义或显式缓存控制另有说明 (参见 [CACHING] 的 Section 4.2.2)。

15.5.6. 405 Method Not Allowed (405 方法不允许)

405 (Method Not Allowed, 方法不允许) 状态码表示源服务器知道目标资源的请求方法, 但目标资源不支持该方法。生成 405 响应的源服务器必须 (MUST) 生成一个 Allow 标头字段, 其中包含目标资源当前支持的方法列表。

405 响应是启发式可缓存的; 即, 除非方法定义或显式缓存控制另有说明 (参见 [CACHING] 的 Section 4.2.2)。

15.5.7. 406 Not Acceptable (406 不可接受)

406 (Not Acceptable, 不可接受) 状态码表示目标资源没有根据请求中接收到的主动内容协商标头字段 (Section 12.1) 可接受的当前表示, 并且服务器不愿意提供默认表示。

服务器应该 (SHOULD) 生成包含可用表示特征列表及其对应 URI 引用的内容, 从中用户或用户代理可以选择最合适的一个。用户代理可以 (MAY) 自动选择最合适的选择。

注意: 在实践中, 大多数实现不会发送 406 响应, 而是假设客户端将接受任何可用的表示。

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

407 (Proxy Authentication Required, 需要代理身份验证) 状态码类似于 401 (Unauthorized, 未授权), 但它表示客户端需要自己进行身份验证才能使用代理进行此请求。代理必须 (MUST) 发送包含适用于该代理的挑战的 Proxy-Authenticate 标头字段 (Section 11.7.1)。客户端可以 (MAY) 使用 Proxy-Authorization 标头字段 (Section 11.7.2) 重复请求。

15.5.9. 408 Request Timeout (408 请求超时)

408 (Request Timeout, 请求超时) 状态码表示服务器没有在准备等待的时间内收到来自客户端的完整请求消息。服务器应该 (SHOULD) 在响应中发送一个 Connection: close 标头字段, 因为 408 表示服务器决定关闭连接而不是继续等待。如果客户端在发送请求时发生超时情况, 则客户端可以 (MAY) 重复请求而无需修改。

15.5.10. 409 Conflict (409 冲突)

409 (Conflict, 冲突) 状态码表示由于与目标资源的当前状态冲突, 请求无法完成。此代码在用户可能能够解决冲突并重新提交请求的情况下使用。服务器应该 (SHOULD) 生成包含足够信息的内容, 以便用户识别冲突的源。

冲突最有可能发生在对 PUT 请求的响应中。例如, 如果正在使用版本控制, 并且正在 PUT 的表示包含对目标资源的更改, 这些更改与先前 (第三方) 请求所做的更改冲突, 源服务器可能会使用 409 响应来表明它无法完成请求。在这种情况下, 响应内容可能包含有助于用户或用户代理解决冲突的差异列表。

15.5.11. 410 Gone (410 已消失)

410 (Gone, 已消失) 状态码表示对目标资源的访问在源服务器上不再可用, 并且此情况可能是永久性的。如果源服务器不知道或无法确定此情况是否是永久性的, 则应该使用状态码 404 (Not Found, 未找到) 而不是 410。

410 响应主要旨在通过通知收件人资源有意不再可用来协助维护 Web 的任务。此类事件在限时促销服务和属于不再在源服务器站点工作的个人的资源中很常见。不需要将所有永久不可用的资源标记为 "gone" (已消失) 或保持标记任何时间长度 -- 这完全由源服务器的所有者自行决定。

410 响应是启发式可缓存的; 即, 除非方法定义或显式缓存控制另有说明 (参见 [CACHING] 的 Section 4.2.2)。

15.5.12. 411 Length Required (411 需要长度)

411 (Length Required, 需要长度) 状态码表示服务器拒绝接受没有定义 Content-Length (Section 8.6) 的请求。

15.5.13. 412 Precondition Failed (412 前提条件失败)

412 (Precondition Failed, 前提条件失败) 状态码表示在服务器上评估时, 请求标头字段中给出的一个或多个条件被评估为 false (Section 13)。此响应状态码允许客户端对当前资源状态 (其当前表示和元数据) 设置前提条件, 从而防止请求方法在目标资源处于意外状态时应用。

15.5.14. 413 Content Too Large (413 内容太大)

413 (Content Too Large, 内容太大) 状态码表示服务器拒绝处理请求, 因为请求内容大于服务器愿意或能够处理的大小。服务器可以 (MAY) 关闭连接以防止客户端继续请求。

如果情况是暂时的, 服务器应该 (SHOULD) 生成一个 Retry-After 标头字段, 以指示它在多久之后可能可用。

15.5.15. 414 URI Too Long (414 URI 太长)

414 (URI Too Long, URI 太长) 状态码表示服务器拒绝服务请求, 因为请求目标 (Section 7.1) 的长度超过了服务器愿意解释的长度。这种罕见的情况仅可能在以下情况下发生:

客户端错误地将 POST 请求转换为 GET 请求, 并带有长查询信息,
客户端已陷入重定向的 "黑洞" (例如, 指向自身后缀的重定向 URI 前缀),
或者服务器受到客户端的攻击, 该客户端试图利用某些服务器使用固定长度缓冲区读取或操作请求目标的安全漏洞。

414 响应是启发式可缓存的; 即, 除非方法定义或显式缓存控制另有说明 (参见 [CACHING] 的 Section 4.2.2)。

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

415 (Unsupported Media Type, 不支持的媒体类型) 状态码表示源服务器拒绝服务请求, 因为内容采用目标资源在此方法上不支持的格式。

格式问题可能是由于请求的指示的 Content-Type 或 Content-Encoding, 或者是作为直接检查数据的结果。

如果问题是客户端对目标资源不支持的内容编码的使用, 则 Accept-Encoding 响应标头字段 (Section 12.5.3) 应该 (SHOULD) 用于指示服务器支持的内容编码。

另一方面, 如果不支持的是请求的表示的媒体类型, 则 Accept 响应标头字段 (Section 12.5.1) 可以 (MAY) 用于指示该资源支持的媒体类型范围。

15.5.17. 416 Range Not Satisfiable (416 范围无法满足)

416 (Range Not Satisfiable, 范围无法满足) 状态码表示请求的 Range 标头字段 (Section 14.2) 中的范围值都不与所选表示的当前范围重叠, 并且请求没有包含 If-Range 请求标头字段。

当为字节范围请求生成 416 响应时, 发送者应该 (SHOULD) 生成一个 Content-Range 标头字段, 指定所选表示的当前长度 (参见 Section 14.4)。

例如:

HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022

注意: 由于客户端通常重试不可满足的范围请求而不包含请求的 Range 标头字段, 因此服务器不应该 (SHOULD NOT) 自动使用 416 (Range Not Satisfiable) 响应生成表示的完整长度内容。

15.5.18. 417 Expectation Failed (417 期望失败)

417 (Expectation Failed, 期望失败) 状态码表示请求的 Expect 标头字段 (Section 10.1.1) 中给出的期望无法被至少一个入站服务器满足。

15.5.19. 418 (Unused) (418 未使用)

[RFC2324] 在一个愚人节笑话中定义了 418 (I'm a teapot) 状态码, 该笑话是咖啡壶控制的超文本咖啡壶控制协议 (Hyper Text Coffee Pot Control Protocol)。该状态码在各种 HTTP 实现中使用不一致。为了最大限度地实现互操作性, 服务器实现应该 (SHOULD) 不使用 418 状态码。

注意: RFC 2324 是 IETF 的传统愚人节 RFC; 它没有指定实际标准。418 状态码包含在注册表中, 因为通过愚人节笑话的知名度导致某些客户端实现期望接收此状态码作为响应。

15.5.20. 421 Misdirected Request (421 误定向请求)

421 (Misdirected Request, 误定向请求) 状态码表示请求被定向到无法生成响应的服务器。这可能由未配置为为请求 URI 中包含的方案和权威组合生成响应的服务器发送。

接收到 421 (Misdirected Request) 响应的客户端可以 (MAY) 通过不同的连接重试请求, 无论响应是否可缓存。

15.5.21. 422 Unprocessable Content (422 无法处理的内容)

422 (Unprocessable Content, 无法处理的内容) 状态码表示服务器理解请求的内容类型, 并且请求的语法正确, 但无法处理所包含的指令。例如, 如果 XML 请求正文包含格式良好但语义错误的 XML 指令, 则可以使用此响应代码。

15.5.22. 426 Upgrade Required (426 需要升级)

426 (Upgrade Required, 需要升级) 状态码表示服务器拒绝使用当前协议执行请求, 但可能愿意在客户端升级到不同协议后这样做。服务器必须 (MUST) 在 426 响应中发送一个 Upgrade 标头字段, 以指示所需的协议。

例如:

HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain

This service requires use of the HTTP/3.0 protocol.

15.6. Server Error 5xx (服务器错误 5xx)

5xx (Server Error, 服务器错误) 类别的状态码表示服务器知道它遇到了错误或无法执行请求的方法。除了在响应 HEAD 请求时之外, 服务器应该 (SHOULD) 发送包含对错误情况的解释以及它是暂时情况还是永久情况的表示。用户代理应该 (SHOULD) 向用户显示任何包含的表示。这些响应状态码适用于任何请求方法。

15.6.1. 500 Internal Server Error (500 内部服务器错误)

500 (Internal Server Error, 内部服务器错误) 状态码表示服务器遇到了意外情况, 阻止其满足请求。

15.6.2. 501 Not Implemented (501 未实现)

501 (Not Implemented, 未实现) 状态码表示服务器不支持满足请求所需的功能。这是当服务器不识别请求方法且无法为任何资源支持它时的适当响应。

501 响应是启发式可缓存的; 即, 除非方法定义或显式缓存控制另有说明 (参见 [CACHING] 的 Section 4.2.2)。

15.6.3. 502 Bad Gateway (502 错误网关)

502 (Bad Gateway, 错误网关) 状态码表示服务器在充当网关或代理时, 从其访问的入站服务器收到了无效响应。

15.6.4. 503 Service Unavailable (503 服务不可用)

503 (Service Unavailable, 服务不可用) 状态码表示由于暂时过载或计划维护, 服务器当前无法处理请求, 这可能会在一段延迟后得到缓解。服务器可以 (MAY) 发送 Retry-After 标头字段 (Section 10.2.3) 以建议客户端在重试请求之前等待的适当时间量。

注意: 503 状态码的存在并不意味着服务器在过载时必须 (MUST) 使用它。某些服务器可能只是拒绝连接。

15.6.5. 504 Gateway Timeout (504 网关超时)

504 (Gateway Timeout, 网关超时) 状态码表示服务器在充当网关或代理时, 未能及时从其需要访问以完成请求的上游服务器收到响应。

15.6.6. 505 HTTP Version Not Supported (505 HTTP 版本不支持)

505 (HTTP Version Not Supported, HTTP 版本不支持) 状态码表示服务器不支持或拒绝支持请求消息中使用的 HTTP 主版本。服务器表示它无法或不愿意使用与客户端相同的主版本完成请求, 如 Section 2.5 中所述, 而不是此错误消息。响应应该 (SHOULD) 包含描述为什么不支持该版本以及该服务器支持哪些其他协议的表示。

📊 翻译质量自检

段落对齐: 原文与译文段落 1:1 对应
链接格式: 所有章节标题已转为链接
术语双语: 首次术语已标注双语
RFC 2119: MUST→必须, SHOULD→应该, MAY→可以
MDX 安全: URL 已包裹反引号, HTML 已自闭合
标点规范: 已使用英文标点
清理杂项: 已移除页码/页眉
语言纯净: 内容为真实的简体中文
目录正确: 文件已放置在正确的中文目录

📍 当前进度

RFC 编号: 9110
目标语言: 🇨🇳 简体中文
已完成章节: Section 15 (Status Codes)
包含子章节: 15.1-15.6, 共 28 个状态码定义
总体进度: Section 15 已完成, 等待 Section 16, 17