6. 响应状态码
status-code 元素是一个三位整数代码, 给出理解并满足请求这一尝试的结果.
HTTP 状态码是可扩展的. HTTP 客户端不要求理解所有已注册状态码的含义, 尽管这种理解显然是可取的. 但是, 客户端 MUST 理解任何状态码由第一位数字指示的类别, 并把无法识别的状态码视为等同于该类别的 x00 状态码, 但有一个例外: 接收者 MUST NOT 缓存带有无法识别状态码的响应.
例如, 如果客户端收到无法识别的状态码 471, 客户端可以假定其请求有问题, 并像收到 400 (Bad Request) 状态码那样处理该响应. 响应消息通常会包含解释该状态的表示.
status-code 的第一位数字定义响应类别. 最后两位数字没有任何分类作用. 第一位数字有五个取值:
- 1xx (Informational): 请求已收到, 继续处理
- 2xx (Successful): 请求已成功收到、理解并接受
- 3xx (Redirection): 需要采取进一步动作以完成请求
- 4xx (Client Error): 请求包含错误语法或无法被满足
- 5xx (Server Error): 服务器未能满足一个看似有效的请求
6.1. 状态码概述
下列状态码由本规范定义. 此处列出的 reason phrase 只是建议 -- 它们可以替换为本地等价短语而不影响协议.
默认定义为可缓存的状态码响应 (例如本规范中的 200、203、204、206、300、301、404、405、410、414, 和 501) 可由缓存使用启发式过期复用, 除非方法定义或显式缓存控制另有指示 [RFC7234]; 所有其他状态码默认不可缓存.
| Code | Reason Phrase | Defined In |
|---|---|---|
| 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. 信息性 1xx
1xx (Informational) 类状态码指示临时响应, 用于在完成所请求动作并发送最终响应之前传达连接状态或请求进度. 由于 HTTP/1.0 未定义任何 1xx 状态码, 服务器 MUST NOT 向 HTTP/1.0 客户端发送 1xx 响应.
1xx 响应由 status-line 之后的第一个空行终止 (该空行表示头部节结束). 由于 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. 成功 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 字段值包含该目标资源新表示的 entity-tag.
204 响应允许服务器指示动作已成功应用于目标资源, 同时暗示用户代理无需离开其当前 "document view" (如果有). 服务器假定用户代理会按照自身接口向用户提供某种成功指示, 并把响应中的任何新元数据或更新元数据应用到其活动表示.
例如, 204 状态码常用于与 "save" 动作对应的文档编辑接口, 使正在保存的文档仍可供用户编辑. 它也常用于预期自动化数据传输普遍存在的接口, 如分布式版本控制系统中的接口.
204 响应由头部字段之后的第一个空行终止, 因为它不能包含消息体.
204 响应默认可缓存; 即, 除非方法定义或显式缓存控制另有指示 (见 [RFC7234] Section 4.2.2).
6.3.6. 205 Reset Content
205 (Reset Content) 状态码指示服务器已满足请求, 并希望用户代理把导致请求被发送的 "document view" 重置为从源服务器收到时的原始状态.
该响应旨在支持一种常见的数据录入用例: 用户收到支持数据录入的内容 (表单、记事本、画布等), 在该空间中输入或操作数据, 使输入的数据在请求中提交, 然后重置数据录入机制以便下一次录入, 让用户可以轻松发起另一个输入动作.
由于 205 状态码暗示不会提供额外内容, 服务器 MUST NOT 在 205 响应中生成负载. 换言之, 对于 205 响应, 服务器 MUST 执行以下之一: a) 通过包含值为 0 的 Content-Length 头部字段来指示响应的零长度主体; b) 通过包含值为 chunked 的 Transfer-Encoding 头部字段, 且消息体由单个零长度 chunk 组成, 来指示响应的零长度负载; 或, c) 在发送终止头部节的空行之后立即关闭连接.
6.4. 重定向 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 检测循环重定向 (即 "infinite" 重定向循环) 并进行干预.
注意: 本规范的早期版本建议最多五次重定向 ([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 在响应中生成 Location 头部字段, 其中包含新永久 URI 的首选 URI 引用. 用户代理 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 在响应中生成 Location 头部字段, 其中包含不同 URI 的 URI 引用. 用户代理 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) 状态码在本规范的先前版本中定义, 现在已弃用 (Appendix B).
6.4.6. 306 (Unused)
306 状态码在本规范的先前版本中定义, 现已不再使用, 且该代码被保留.
6.4.7. 307 Temporary Redirect
307 (Temporary Redirect) 状态码指示目标资源暂时位于不同 URI 下, 且如果用户代理对该 URI 执行自动重定向, MUST NOT 改变请求方法. 由于重定向可能随时间变化, 客户端应继续使用原始有效请求 URI 进行未来请求.
服务器 SHOULD 在响应中生成 Location 头部字段, 其中包含不同 URI 的 URI 引用. 用户代理 MAY 使用 Location 字段值进行自动重定向. 服务器的响应负载通常包含一个简短的超文本说明, 带有指向不同 URI 的超链接.
注意: 该状态码类似于 302 (Found), 但它不允许把请求方法从 POST 改为 GET. 本规范未为 301 (Moved Permanently) 定义等价对应项 (不过 [RFC7538] 为此定义了状态码 308 (Permanent Redirect)).
6.5. 客户端错误 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
414 (URI Too Long) 状态码指示服务器拒绝服务该请求, 因为 request-target ([RFC7230] Section 5.3) 长于服务器愿意解释的长度. 这种罕见情况只可能发生在客户端错误地把 POST 请求转换为带有长查询信息的 GET 请求、客户端陷入重定向的 "black hole" (例如, 重定向 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. 服务器错误 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
505 (HTTP Version Not Supported) 状态码指示服务器不支持或拒绝支持请求消息中使用的 HTTP 主版本. 服务器正在指示, 除通过此错误消息外, 它无法或不愿使用与客户端相同的主版本完成请求, 如 [RFC7230] Section 2.6 所述. 服务器 SHOULD 生成一个表示, 说明为何不支持该版本以及该服务器支持哪些其他协议.