6. Response Status Codes (响应状态码)
状态码 (status-code) 元素是一个三位整数代码，给出尝试理解和满足请求的结果。
HTTP 状态码是可扩展的。HTTP 客户端不需要理解所有已注册状态码的含义，尽管这种理解显然是可取的。但是，客户端必须 (MUST) 理解任何状态码的类别，如第一位数字所示，并将无法识别的状态码视为等同于该类别的 x00 状态码，但接收方不得 (MUST NOT) 缓存具有无法识别状态码的响应。
例如，如果客户端收到无法识别的状态码 471，客户端可以假设其请求有问题，并将响应视为已收到 400 (Bad Request) 状态码。响应消息通常会包含解释状态的表示。
状态码的第一位数字定义了响应的类别。后两位数字没有任何分类作用。第一位数字有五个值：
- 1xx (Informational / 信息性)：请求已被接收，正在继续处理
- 2xx (Successful / 成功)：请求已成功被接收、理解和接受
- 3xx (Redirection / 重定向)：需要采取进一步的操作才能完成请求
- 4xx (Client Error / 客户端错误)：请求包含错误的语法或无法完成
- 5xx (Server Error / 服务器错误)：服务器未能完成明显有效的请求
6.1. Overview of Status Codes (状态码概述)
下面列出的状态码在本规范中定义。这里列出的原因短语只是建议——它们可以被本地等价物替换而不影响协议。
默认情况下定义为可缓存的状态码（例如，本规范中的 200、203、204、206、300、301、404、405、410、414 和 501）的响应可以由缓存通过启发式过期重用，除非方法定义或显式缓存控制另有说明 [RFC7234]；所有其他状态码默认不可缓存。
| 代码 | 原因短语 | 定义位置 |
|---|---|---|
| 100 | Continue | Section 6.2.1 |
| 101 | Switching Protocols | Section 6.2.2 |
| 200 | OK | Section 6.3.1 |
| 201 | Created | Section 6.3.2 |
| 202 | Accepted | Section 6.3.3 |
| 203 | Non-Authoritative Information | Section 6.3.4 |
| 204 | No Content | Section 6.3.5 |
| 205 | Reset Content | Section 6.3.6 |
| 206 | Partial Content | RFC7233 |
| 300 | Multiple Choices | Section 6.4.1 |
| 301 | Moved Permanently | Section 6.4.2 |
| 302 | Found | Section 6.4.3 |
| 303 | See Other | Section 6.4.4 |
| 304 | Not Modified | RFC7232 |
| 305 | Use Proxy | Section 6.4.5 |
| 306 | (Unused) | Section 6.4.6 |
| 307 | Temporary Redirect | Section 6.4.7 |
| 400 | Bad Request | Section 6.5.1 |
| 401 | Unauthorized | RFC7235 |
| 402 | Payment Required | Section 6.5.2 |
| 403 | Forbidden | Section 6.5.3 |
| 404 | Not Found | Section 6.5.4 |
| 405 | Method Not Allowed | Section 6.5.5 |
| 406 | Not Acceptable | Section 6.5.6 |
| 407 | Proxy Authentication Required | RFC7235 |
| 408 | Request Timeout | Section 6.5.7 |
| 409 | Conflict | Section 6.5.8 |
| 410 | Gone | Section 6.5.9 |
| 411 | Length Required | Section 6.5.10 |
| 412 | Precondition Failed | RFC7232 |
| 413 | Payload Too Large | Section 6.5.11 |
| 414 | URI Too Long | Section 6.5.12 |
| 415 | Unsupported Media Type | Section 6.5.13 |
| 416 | Range Not Satisfiable | RFC7233 |
| 417 | Expectation Failed | Section 6.5.14 |
| 426 | Upgrade Required | Section 6.5.15 |
| 500 | Internal Server Error | Section 6.6.1 |
| 501 | Not Implemented | Section 6.6.2 |
| 502 | Bad Gateway | Section 6.6.3 |
| 503 | Service Unavailable | Section 6.6.4 |
| 504 | Gateway Timeout | Section 6.6.5 |
| 505 | HTTP Version Not Supported | Section 6.6.6 |
6.2. Informational 1xx (信息性 1xx)
1xx (Informational) 类状态码表示在完成请求的操作并发送最终响应之前，用于传达连接状态或请求进度的临时响应。由于 HTTP/1.0 没有定义任何 1xx 状态码，服务器不得 (MUST NOT) 向 HTTP/1.0 客户端发送 1xx 响应。
1xx 响应由状态行后的第一个空行终止（空行表示头部分的结束）。由于 1xx 响应不能包含消息主体，因此它总是由头字段后的第一个空行终止。
HTTP/1.1 客户端必须 (MUST) 准备在最终响应之前接收一个或多个 1xx 响应，即使客户端不期望 100 (Continue) 状态消息。用户代理可以 (MAY) 忽略意外的 1xx 响应。
代理必须 (MUST) 转发 1xx 响应，除非代理本身请求生成 1xx 响应。例如，如果代理在转发请求时添加了 "Expect: 100-continue" 字段，则它不需要转发相应的 100 (Continue) 响应。
6.2.1. 100 Continue (继续)
100 (Continue) 状态码表示请求的初始部分已被接收并且尚未被服务器拒绝。服务器打算在完全接收并处理请求后发送最终响应。
当请求包含一个包括 100-continue 期望的 Expect 头字段时，100 响应表示服务器希望接收请求有效载荷主体，如 Section 5.1.1 中所述。客户端应该继续发送请求并丢弃 100 响应。
如果请求不包含包含 100-continue 期望的 Expect 头字段，客户端可以简单地丢弃这个临时响应。
6.2.2. 101 Switching Protocols (切换协议)
101 (Switching Protocols) 状态码表示服务器理解并愿意通过 Upgrade 头字段（[RFC7230] 的 Section 6.7）遵守客户端的请求，更改此连接上使用的应用协议。服务器必须 (MUST) 在响应中生成一个 Upgrade 头字段，指示在终止 101 响应的空行之后立即生效的协议。
假设服务器只会在有利时才同意切换协议。例如，切换到较新版本的 HTTP 可能比旧版本有利，切换到实时同步协议在传递使用此类功能的资源时可能有利。
6.3. Successful 2xx (成功 2xx)
2xx (Successful) 类状态码表示客户端的请求已成功被接收、理解和接受。
6.3.1. 200 OK (确定)
200 (OK) 状态码表示请求已成功。200 响应中发送的有效载荷取决于请求方法。对于本规范定义的方法，有效载荷的预期含义可以概括为：
- GET：目标资源的表示；
- HEAD：与 GET 相同的表示，但没有表示数据；
- POST：操作的状态或从中获得的结果的表示；
- PUT, DELETE：操作状态的表示；
- OPTIONS：通信选项的表示；
- TRACE：最终服务器接收到的请求消息的表示。
除了对 CONNECT 的响应外，200 响应始终有有效载荷，尽管源服务器可以 (MAY) 生成长度为零的有效载荷主体。如果不需要有效载荷，源服务器应该发送 204 (No Content)。对于 CONNECT，不允许有效载荷，因为成功的结果是一个隧道，它在 200 响应头部分之后立即开始。
200 响应默认是可缓存的；即，除非方法定义或显式缓存控制另有说明（参见 [RFC7234] 的 Section 4.2.2）。
6.3.2. 201 Created (已创建)
201 (Created) 状态码表示请求已完成并导致创建一个或多个新资源。由请求创建的主要资源由响应中的 Location 头字段标识，或者如果未收到 Location 字段，则由有效请求 URI 标识。
201 响应有效载荷通常描述并链接到创建的资源。有关 201 响应中验证器头字段（如 ETag 和 Last-Modified）的含义和目的的讨论，请参见 Section 7.2。
6.3.3. 202 Accepted (已接受)
202 (Accepted) 状态码表示请求已被接受处理，但处理尚未完成。请求最终可能会或可能不会被执行，因为在实际处理时可能会被禁止。HTTP 中没有用于从异步操作重新发送状态码的工具。
202 响应故意不做承诺。其目的是允许服务器接受某个其他进程的请求（可能是每天只运行一次的面向批处理的进程），而不要求用户代理与服务器的连接持续到进程完成。与此响应一起发送的表示应该描述请求的当前状态，并指向（或嵌入）状态监视器，该监视器可以为用户提供请求何时完成的估计。
6.3.4. 203 Non-Authoritative Information (非权威信息)
203 (Non-Authoritative Information) 状态码表示请求成功，但封闭的有效载荷已被转换代理（[RFC7230] 的 Section 5.7.2）从源服务器的 200 (OK) 响应修改。此状态码允许代理在应用转换时通知接收方，因为该知识可能会影响以后关于内容的决策。例如，对内容的未来缓存验证请求可能仅适用于相同的请求路径（通过相同的代理）。
203 响应类似于 214 Transformation Applied 的警告代码（[RFC7234] 的 Section 5.5），其优点是适用于具有任何状态码的响应。
203 响应默认是可缓存的；即，除非方法定义或显式缓存控制另有说明（参见 [RFC7234] 的 Section 4.2.2）。
6.3.5. 204 No Content (无内容)
204 (No Content) 状态码表示服务器已成功完成请求，并且响应有效载荷主体中没有要发送的额外内容。响应头字段中的元数据是指在应用请求的操作后的目标资源及其选定的表示。
例如，如果在响应 PUT 请求时收到 204 状态码，并且响应包含 ETag 头字段，则 PUT 成功，ETag 字段值包含该目标资源的新表示的实体标签。
204 响应允许服务器指示操作已成功应用于目标资源，同时暗示用户代理不需要离开其当前的"文档视图"（如果有）。服务器假设用户代理将根据其自己的接口向其用户提供成功的某种指示，并将响应中的任何新的或更新的元数据应用于其活动表示。
例如，204 状态码通常与对应于"保存"操作的文档编辑界面一起使用，以便正在保存的文档仍可供用户编辑。它也经常与期望自动数据传输普遍存在的界面一起使用，例如在分布式版本控制系统中。
204 响应由头字段后的第一个空行终止，因为它不能包含消息主体。
204 响应默认是可缓存的；即，除非方法定义或显式缓存控制另有说明（参见 [RFC7234] 的 Section 4.2.2）。
6.3.6. 205 Reset Content (重置内容)
205 (Reset Content) 状态码表示服务器已完成请求，并希望用户代理将导致发送请求的"文档视图"重置为从源服务器接收时的原始状态。
此响应旨在支持常见的数据输入用例，其中用户接收支持数据输入的内容（表单、记事本、画布等），在该空间中输入或操作数据，导致输入的数据在请求中提交，然后重置数据输入机制以进行下一次输入，以便用户可以轻松地启动另一个输入操作。
由于 205 状态码暗示不会提供额外的内容，服务器不得 (MUST NOT) 在 205 响应中生成有效载荷。换句话说，服务器必须 (MUST) 对 205 响应执行以下操作之一：a) 通过包含值为 0 的 Content-Length 头字段来指示响应的主体长度为零；b) 通过包含值为 chunked 的 Transfer-Encoding 头字段和由单个零长度块组成的消息主体来指示响应的有效载荷长度为零；或者，c) 在发送终止头部分的空行后立即关闭连接。
6.4. Redirection 3xx (重定向 3xx)
3xx (Redirection) 类状态码表示用户代理需要采取进一步的操作才能完成请求。如果提供了 Location 头字段（Section 7.1.2），即使不理解特定的状态码，用户代理也可以 (MAY) 自动将其请求重定向到 Location 字段值引用的 URI。对于未知为安全的方法（如 Section 4.2.1 中所定义），需要谨慎进行自动重定向，因为用户可能不希望重定向不安全的请求。
有几种类型的重定向：
-
指示资源可能在 Location 字段提供的不同 URI 处可用的重定向，如状态码 301 (Moved Permanently)、302 (Found) 和 307 (Temporary Redirect)。
-
提供匹配资源选择的重定向，每个资源都能够表示原始请求目标，如 300 (Multiple Choices) 状态码。
-
重定向到由 Location 字段标识的不同资源，该资源可以表示对请求的间接响应，如 303 (See Other) 状态码。
-
重定向到先前缓存的结果，如 304 (Not Modified) 状态码。
注意： 在 HTTP/1.0 中，状态码 301 (Moved Permanently) 和 302 (Found) 为第一种类型的重定向定义（[RFC1945]，Section 9.3）。早期的用户代理在应用于重定向目标的方法是否与原始请求相同还是将被重写为 GET 方面存在分歧。尽管 HTTP 最初为 301 和 302 定义了前者的语义（以匹配其在 CERN 的原始实现），并定义了 303 (See Other) 以匹配后者的语义，但主流实践逐渐也收敛于 301 和 302 的后者语义。HTTP/1.1 的第一次修订版添加了 307 (Temporary Redirect) 以指示前者的语义而不受分歧实践的影响。10 多年后，大多数用户代理仍然对 301 和 302 进行方法重写；因此，本规范在原始请求是 POST 时使该行为符合规范。
客户端应该 (SHOULD) 检测并干预循环重定向（即，"无限"重定向循环）。
注意： 本规范的早期版本建议最多五次重定向（[RFC2068]，Section 10.3）。内容开发人员需要注意，某些客户端可能会实现这样的固定限制。
6.4.1. 300 Multiple Choices (多种选择)
300 (Multiple Choices) 状态码表示目标资源有多个表示，每个都有自己更具体的标识符，并且正在提供有关备选方案的信息，以便用户（或用户代理）可以通过将其请求重定向到这些标识符中的一个或多个来选择首选表示。换句话说，服务器希望用户代理参与反应性协商，以为其需求选择最合适的表示（Section 3.4.2）。
如果服务器有首选选择，服务器应该 (SHOULD) 生成包含首选选择的 URI 引用的 Location 头字段。用户代理可以 (MAY) 使用 Location 字段值进行自动重定向。
对于 HEAD 以外的请求方法，服务器应该 (SHOULD) 在 300 响应中生成有效载荷，其中包含表示元数据和 URI 引用的列表，用户或用户代理可以从中选择最喜欢的一个。如果用户代理理解提供的媒体类型，它可以 (MAY) 从该列表中自动进行选择。本规范未定义用于自动选择的特定格式，因为 HTTP 试图与其有效载荷的定义保持正交。实际上，表示以某种易于解析的格式提供，该格式被认为是用户代理可接受的，通过共享设计或内容协商确定，或者以某种常用的超文本格式提供。
300 响应默认是可缓存的；即，除非方法定义或显式缓存控制另有说明（参见 [RFC7234] 的 Section 4.2.2）。
注意： 300 状态码的原始提案将 URI 头字段定义为提供替代表示的列表，这样它就可以用于 200、300 和 406 响应，并在对 HEAD 方法的响应中传输。但是，由于缺乏部署和对语法的分歧，URI 和 Alternates（后续提案）都从本规范中删除。可以使用一组 Link 头字段 [RFC5988] 来传达列表，每个都具有"alternate"的关系，尽管部署是一个鸡和蛋的问题。
6.4.2. 301 Moved Permanently (永久移动)
301 (Moved Permanently) 状态码表示目标资源已被分配了一个新的永久 URI，对该资源的任何未来引用都应该使用封闭的 URI 之一。具有链接编辑功能的客户端应该在可能的情况下自动将对有效请求 URI 的引用重新链接到服务器发送的一个或多个新引用。
服务器应该 (SHOULD) 在响应中生成包含新永久 URI 的首选 URI 引用的 Location 头字段。用户代理可以 (MAY) 使用 Location 字段值进行自动重定向。服务器的响应有效载荷通常包含一个简短的超文本注释，其中包含指向新 URI 的超链接。
注意： 出于历史原因，用户代理可以 (MAY) 将后续请求的请求方法从 POST 更改为 GET。如果不希望这种行为，可以改用 307 (Temporary Redirect) 状态码。
301 响应默认是可缓存的；即，除非方法定义或显式缓存控制另有说明（参见 [RFC7234] 的 Section 4.2.2）。
6.4.3. 302 Found (找到)
302 (Found) 状态码表示目标资源暂时位于不同的 URI 下。由于重定向有时可能会更改，客户端应该继续使用有效请求 URI 进行未来的请求。
服务器应该 (SHOULD) 在响应中生成包含不同 URI 的 URI 引用的 Location 头字段。用户代理可以 (MAY) 使用 Location 字段值进行自动重定向。服务器的响应有效载荷通常包含一个简短的超文本注释，其中包含指向不同 URI 的超链接。
注意： 出于历史原因，用户代理可以 (MAY) 将后续请求的请求方法从 POST 更改为 GET。如果不希望这种行为，可以改用 307 (Temporary Redirect) 状态码。
6.4.4. 303 See Other (参见其他)
303 (See Other) 状态码表示服务器正在将用户代理重定向到不同的资源，如 Location 头字段中的 URI 所示，该资源旨在提供对原始请求的间接响应。用户代理可以执行针对该 URI 的检索请求（如果使用 HTTP，则为 GET 或 HEAD 请求），该请求也可能被重定向，并将最终结果作为对原始请求的答案呈现。请注意，Location 头字段中的新 URI 不被认为等同于有效请求 URI。
此状态码适用于任何 HTTP 方法。它主要用于允许 POST 操作的输出将用户代理重定向到选定的资源，因为这样做以可以单独标识、加书签和缓存的形式提供对应于 POST 响应的信息，独立于原始请求。
对 GET 请求的 303 响应表示源服务器没有可以由服务器通过 HTTP 传输的目标资源的表示。但是，Location 字段值是指描述目标资源的资源，因此对该其他资源进行检索请求可能会产生对接收方有用的表示，而不意味着它表示原始目标资源。请注意，关于什么可以被表示、什么表示是充分的以及什么可能是有用的描述的问题超出了 HTTP 的范围。
除了对 HEAD 请求的响应外，303 响应的表示应该包含一个简短的超文本注释，其中包含指向 Location 头字段中提供的相同 URI 引用的超链接。
6.4.5. 305 Use Proxy (使用代理)
305 (Use Proxy) 状态码在本规范的先前版本中定义，现已弃用（附录 B）。
6.4.6. 306 (Unused / 未使用)
306 状态码在本规范的先前版本中定义，不再使用，代码已保留。
6.4.7. 307 Temporary Redirect (临时重定向)
307 (Temporary Redirect) 状态码表示目标资源暂时位于不同的 URI 下，如果用户代理对该 URI 执行自动重定向，则不得 (MUST NOT) 更改请求方法。由于重定向可能随时间而变化，客户端应该继续使用原始有效请求 URI 进行未来的请求。
服务器应该 (SHOULD) 在响应中生成包含不同 URI 的 URI 引用的 Location 头字段。用户代理可以 (MAY) 使用 Location 字段值进行自动重定向。服务器的响应有效载荷通常包含一个简短的超文本注释，其中包含指向不同 URI 的超链接。
注意： 此状态码类似于 302 (Found)，除了它不允许将请求方法从 POST 更改为 GET。本规范没有为 301 (Moved Permanently) 定义等效的对应项（但是，[RFC7538] 为此目的定义了状态码 308 (Permanent Redirect)）。
6.5. Client Error 4xx (客户端错误 4xx)
4xx (Client Error) 类状态码表示客户端似乎出错了。除非响应 HEAD 请求，否则服务器应该 (SHOULD) 发送包含错误情况解释的表示，以及这是临时还是永久条件。这些状态码适用于任何请求方法。用户代理应该 (SHOULD) 向用户显示任何包含的表示。
6.5.1. 400 Bad Request (错误请求)
400 (Bad Request) 状态码表示由于被认为是客户端错误的原因（例如，格式错误的请求语法、无效的请求消息框架或欺骗性的请求路由），服务器无法或将不处理请求。
6.5.2. 402 Payment Required (需要付款)
402 (Payment Required) 状态码保留供将来使用。
6.5.3. 403 Forbidden (禁止)
403 (Forbidden) 状态码表示服务器理解请求但拒绝授权它。希望公开为何请求被禁止的服务器可以在响应有效载荷（如果有）中描述该原因。
如果在请求中提供了认证凭证，服务器认为它们不足以授予访问权限。客户端不应该 (SHOULD NOT) 使用相同的凭证自动重复请求。客户端可以 (MAY) 使用新的或不同的凭证重复请求。但是，请求可能因与凭证无关的原因而被禁止。
希望"隐藏"禁止目标资源当前存在的源服务器可以 (MAY) 改为使用状态码 404 (Not Found) 进行响应。
6.5.4. 404 Not Found (未找到)
404 (Not Found) 状态码表示源服务器没有找到目标资源的当前表示，或者不愿意透露存在一个。404 状态码不表示这种缺乏表示是临时的还是永久的；如果源服务器知道（大概是通过某种可配置的方式）条件可能是永久的，则 410 (Gone) 状态码优于 404。
404 响应默认是可缓存的；即，除非方法定义或显式缓存控制另有说明（参见 [RFC7234] 的 Section 4.2.2）。
6.5.5. 405 Method Not Allowed (方法不允许)
405 (Method Not Allowed) 状态码表示请求行中接收的方法被源服务器知道但不被目标资源支持。源服务器必须 (MUST) 在 405 响应中生成包含目标资源当前支持的方法列表的 Allow 头字段。
405 响应默认是可缓存的；即，除非方法定义或显式缓存控制另有说明（参见 [RFC7234] 的 Section 4.2.2）。
6.5.6. 406 Not Acceptable (不可接受)
406 (Not Acceptable) 状态码表示根据请求中接收的主动协商头字段（Section 5.3），目标资源没有用户代理可接受的当前表示，并且服务器不愿意提供默认表示。
服务器应该 (SHOULD) 生成包含可用表示特征和相应资源标识符列表的有效载荷，用户或用户代理可以从中选择最合适的一个。用户代理可以 (MAY) 从该列表中自动选择最合适的选择。但是，本规范未定义此类自动选择的任何标准，如 Section 6.4.1 中所述。
6.5.7. 408 Request Timeout (请求超时)
408 (Request Timeout) 状态码表示服务器在其准备等待的时间内没有收到完整的请求消息。服务器应该 (SHOULD) 在响应中发送"close"连接选项（[RFC7230] 的 Section 6.1），因为 408 暗示服务器已决定关闭连接而不是继续等待。如果客户端有正在传输的未完成请求，客户端可以 (MAY) 在新连接上重复该请求。
6.5.8. 409 Conflict (冲突)
409 (Conflict) 状态码表示由于与目标资源的当前状态冲突，无法完成请求。此代码用于用户可能能够解决冲突并重新提交请求的情况。服务器应该 (SHOULD) 生成包含足够信息的有效载荷，以便用户识别冲突的来源。
冲突最有可能发生在对 PUT 请求的响应中。例如，如果正在使用版本控制，并且正在 PUT 的表示包括对与较早（第三方）请求所做的更改冲突的资源更改，则源服务器可能会使用 409 响应来指示它无法完成请求。在这种情况下，响应表示可能包含对基于修订历史合并差异有用的信息。
6.5.9. 410 Gone (已删除)
410 (Gone) 状态码表示对目标资源的访问在源服务器上不再可用，并且这种情况可能是永久的。如果源服务器不知道或没有工具确定条件是否是永久的，则应该改用状态码 404 (Not Found)。
410 响应主要旨在通过通知接收方资源有意不可用并且服务器所有者希望删除对该资源的远程链接来协助 Web 维护任务。对于有限时间的促销服务以及属于不再与源服务器站点关联的个人的资源，这样的事件很常见。没有必要将所有永久不可用的资源标记为"gone"或将标记保留任何时间长度——这由服务器所有者自行决定。
410 响应默认是可缓存的；即，除非方法定义或显式缓存控制另有说明（参见 [RFC7234] 的 Section 4.2.2）。
6.5.10. 411 Length Required (需要长度)
411 (Length Required) 状态码表示服务器拒绝接受没有定义的 Content-Length（[RFC7230] 的 Section 3.3.2）的请求。如果客户端添加了包含请求消息中消息主体长度的有效 Content-Length 头字段，则客户端可以 (MAY) 重复请求。
6.5.11. 413 Payload Too Large (有效载荷过大)
413 (Payload Too Large) 状态码表示服务器拒绝处理请求，因为请求有效载荷大于服务器愿意或能够处理的。服务器可以 (MAY) 关闭连接以防止客户端继续请求。
如果条件是临时的，服务器应该 (SHOULD) 生成 Retry-After 头字段以指示它是临时的，并在什么时间之后客户端可以 (MAY) 重试。
6.5.12. 414 URI Too Long (URI 过长)
414 (URI Too Long) 状态码表示服务器拒绝服务请求，因为请求目标（[RFC7230] 的 Section 5.3）比服务器愿意解释的长。这种罕见的情况只有在客户端不当地将 POST 请求转换为带有长查询信息的 GET 请求时，当客户端陷入重定向的"黑洞"（例如，重定向的 URI 前缀指向其自身的后缀）时，或者当服务器受到试图利用安全漏洞的客户端攻击时才有可能发生。
414 响应默认是可缓存的；即，除非方法定义或显式缓存控制另有说明（参见 [RFC7234] 的 Section 4.2.2）。
6.5.13. 415 Unsupported Media Type (不支持的媒体类型)
415 (Unsupported Media Type) 状态码表示源服务器拒绝服务请求，因为有效载荷的格式不受目标资源上的此方法支持。格式问题可能是由于请求指示的 Content-Type 或 Content-Encoding，或者是由于直接检查数据的结果。
6.5.14. 417 Expectation Failed (期望失败)
417 (Expectation Failed) 状态码表示请求的 Expect 头字段（Section 5.1.1）中给出的期望无法由至少一个入站服务器满足。
6.5.15. 426 Upgrade Required (需要升级)
426 (Upgrade Required) 状态码表示服务器拒绝使用当前协议执行请求，但可能愿意在客户端升级到不同协议后这样做。服务器必须 (MUST) 在 426 响应中发送 Upgrade 头字段以指示所需的协议（[RFC7230] 的 Section 6.7）。
示例：
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.
6.6. Server Error 5xx (服务器错误 5xx)
5xx (Server Error) 类状态码表示服务器意识到它出错了或无法执行请求的方法。除非响应 HEAD 请求，否则服务器应该 (SHOULD) 发送包含错误情况解释的表示，以及这是临时还是永久条件。用户代理应该 (SHOULD) 向用户显示任何包含的表示。这些状态码适用于任何请求方法。
6.6.1. 500 Internal Server Error (内部服务器错误)
500 (Internal Server Error) 状态码表示服务器遇到了意外情况，阻止它完成请求。
6.6.2. 501 Not Implemented (未实现)
501 (Not Implemented) 状态码表示服务器不支持完成请求所需的功能。当服务器不识别请求方法并且不能支持它用于任何资源时，这是适当的响应。
501 响应默认是可缓存的；即，除非方法定义或显式缓存控制另有说明（参见 [RFC7234] 的 Section 4.2.2）。
6.6.3. 502 Bad Gateway (错误网关)
502 (Bad Gateway) 状态码表示服务器在充当网关或代理时，从它在尝试完成请求时访问的入站服务器收到了无效响应。
6.6.4. 503 Service Unavailable (服务不可用)
503 (Service Unavailable) 状态码表示由于临时过载或计划维护，服务器当前无法处理请求，这在一些延迟后可能会得到缓解。服务器可以 (MAY) 发送 Retry-After 头字段（Section 7.1.3）以建议客户端在重试请求之前等待的适当时间。
注意： 503 状态码的存在并不意味着服务器在过载时必须使用它。某些服务器可能只是拒绝连接。
6.6.5. 504 Gateway Timeout (网关超时)
504 (Gateway Timeout) 状态码表示服务器在充当网关或代理时，没有从它需要访问以完成请求的上游服务器及时收到响应。
6.6.6. 505 HTTP Version Not Supported (HTTP 版本不支持)
505 (HTTP Version Not Supported) 状态码表示服务器不支持或拒绝支持请求消息中使用的 HTTP 主要版本。服务器表示它无法或不愿意使用与客户端相同的主要版本完成请求，如 [RFC7230] 的 Section 2.6 中所述，除了使用此错误消息。服务器应该 (SHOULD) 生成包含为什么不支持该版本以及该服务器支持哪些其他协议的解释的表示。