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

10 Status Code Definitions

下面描述每个 Status-Code, 包括它可以跟随哪些 method, 以及 response 中要求的任何元信息.

10.1 信息性 1xx

这一类 status code 表示临时 response, 只由 Status-Line 和可选 header 组成, 并由空行终止. 这一类 status code 没有必需 header. 由于 HTTP/1.0 未定义任何 1xx status code, server MUST NOT 向 HTTP/1.0 client 发送 1xx response, 除非处于实验条件下.

client MUST 准备在常规 response 之前接受一个或多个 1xx status response, 即使 client 并不期待 100 (Continue) status message. user agent MAY 忽略意外的 1xx status response.

proxy MUST 转发 1xx response, 除非 proxy 与其 client 之间的 connection 已关闭, 或者 1xx response 的生成是 proxy 自己请求的. (例如, 如果 proxy 在转发 request 时添加了 "Expect: 100-continue" field, 则它不需要转发相应的 100 (Continue) response.)



10.1.1 100 Continue

client SHOULD 继续其 request. 该 interim response 用于通知 client: request 的初始部分已经收到, 且 server 尚未拒绝该 request. client SHOULD 继续发送 request 的其余部分; 如果 request 已完成, 则忽略此 response. server MUST 在 request 完成后发送 final response. 关于此 status code 的使用和处理详见第 8.2.3 节.

10.1.2 101 Switching Protocols

server 理解并愿意遵从 client 通过 Upgrade message header field (第 14.42 节) 提出的请求, 即改变此 connection 上正在使用的 application protocol. server 将在终止 101 response 的空行之后, 立即切换到 response 的 Upgrade header field 所定义的协议.

只有在有利时才 SHOULD 切换协议. 例如, 切换到较新版本 HTTP 相比旧版本是有利的; 当交付使用实时同步特性的 resource 时, 切换到实时同步协议也可能有利.

10.2 成功 2xx

这一类 status code 表示 client 的 request 已被成功接收, 理解并接受.

10.2.1 200 OK

request 已成功. 随 response 返回的信息取决于 request 中使用的 method, 例如:

GET response 中发送与所请求 resource 对应的 entity;

HEAD response 中发送与所请求 resource 对应的 entity-header field, 不带任何 message-body;

POST 描述或包含动作结果的 entity;



TRACE 包含 end server 所收到 request message 的 entity.

10.2.2 201 Created

request 已被满足, 并导致创建了新 resource. 新创建的 resource 可由 response entity 中返回的 URI 引用, 其中 Location header field 给出该 resource 最具体的 URI. response SHOULD 包含一个 entity, 其中包含 resource 特征和 location 列表, 用户或 user agent 可从中选择最适合的一项. entity 格式由 Content-Type header field 给出的 media type 指定. origin server MUST 在返回 201 status code 前创建 resource. 如果动作无法立即执行, server SHOULD 改以 202 (Accepted) response 响应.

201 response MAY 包含 ETag response header field, 指示刚创建的被请求 variant 的 entity tag 当前值, 见第 14.19 节.

10.2.3 202 Accepted

request 已被接受用于处理, 但处理尚未完成. 该 request 最终可能会被执行, 也可能不会, 因为实际处理时可能不允许执行. 对于这种异步操作, 没有重新发送 status code 的机制.

202 response 有意保持不承诺. 其目的在于允许 server 接受交由其他过程处理的 request (可能是每天只运行一次的批处理过程), 而不要求 user agent 到 server 的 connection 持续到该过程完成. 随此 response 返回的 entity SHOULD 包含 request 当前 status 的指示, 以及指向 status monitor 的指针或用户可预期 request 完成时间的某种估计.

10.2.4 203 Non-Authoritative Information

entity-header 中返回的元信息不是 origin server 可用的权威集合, 而是从本地或第三方副本收集的. 所呈现集合 MAY 是原始版本的子集或超集. 例如, 包含关于该 resource 的本地注释信息可能导致元信息超出 origin server 已知集合. 使用此 response code 不是必需的, 且只在 response 原本会是 200 (OK) 时才适当.



10.2.5 204 No Content

server 已满足 request, 但不需要返回 entity-body, 并且可能希望返回更新后的元信息. response MAY 以 entity-header 形式包含新的或更新后的元信息; 如果存在, 它们 SHOULD 与所请求 variant 关联.

如果 client 是 user agent, 它 SHOULD NOT 改变导致 request 被发送的 document view. 该 response 主要用于允许动作输入发生, 而不导致 user agent 的活动 document view 改变, 尽管任何新的或更新后的元信息 SHOULD 应用于 user agent 当前活动视图中的 document.

204 response MUST NOT 包含 message-body, 因而始终由 header field 后的第一个空行终止.

10.2.6 205 Reset Content

server 已满足 request, 且 user agent SHOULD 重置导致 request 被发送的 document view. 该 response 主要用于允许通过用户输入执行动作, 随后清空提供输入的表单, 使用户可以轻松发起另一次输入动作. response MUST NOT 包含 entity.

10.2.7 206 Partial Content

server 已满足对 resource 的 partial GET request. request MUST 已包含 Range header field (第 14.35 节), 指明期望 range, 并且 MAY 包含 If-Range header field (第 14.27 节) 以使 request 条件化.

response MUST 包含以下 header field:

  - Content-Range header field (第 14.16 节), 指明此 response 包含的 range;
    或者 multipart/byteranges Content-Type, 其中每个 part 都包含 Content-Range field.
    如果 response 中存在 Content-Length header field, 其值 MUST 匹配 message-body 中实际传输的 OCTET 数.

  - Date

  - ETag 和/或 Content-Location, 如果同一 request 的 200 response 本会发送该 header



  - Expires, Cache-Control 和/或 Vary, 如果 field-value 可能不同于先前对同一 variant 的任一 response 中发送的值

如果 206 response 是使用 strong cache validator 的 If-Range request 的结果 (见第 13.3.3 节), response SHOULD NOT 包含其他 entity-header. 如果 response 是使用 weak validator 的 If-Range request 的结果, response MUST NOT 包含其他 entity-header; 这可防止缓存 entity-body 与更新后 header 之间不一致. 否则, response MUST 包含同一 request 的 200 (OK) response 本会返回的所有 entity-header.

如果 ETag 或 Last-Modified header 不完全匹配, cache MUST NOT 将 206 response 与其他先前缓存内容合并, 见第 13.5.4 节.

不支持 Range 和 Content-Range header 的 cache MUST NOT 缓存 206 (Partial) response.

10.3 重定向 3xx

这一类 status code 表示 user agent 需要采取进一步动作才能满足 request. 当且仅当第二个 request 使用的 method 是 GET 或 HEAD 时, 所需动作 MAY 由 user agent 在不与用户交互的情况下执行. client SHOULD 检测无限重定向循环, 因为此类循环会为每次重定向产生网络流量.

  注意: 本规范的先前版本建议最多重定向五次. content developer 应知道,
  可能存在实现了这种固定限制的 client.

10.3.1 300 Multiple Choices

所请求 resource 对应于一组 representation 中的任意一个, 每个 representation 都有自己的特定 location, 且正在提供 agent-driven negotiation 信息 (第 12 节), 以便用户 (或 user agent) 可以选择首选 representation, 并将 request 重定向到该 location.

除非这是 HEAD request, response SHOULD 包含一个 entity, 其中包含 resource 特征和 location 列表, 用户或 user agent 可从中选择最适合的一项. entity 格式由 Content-Type header field 给出的 media type 指定. 根据格式和 user agent 能力, MAY 自动选择最适合的选项. 但是, 本规范不定义任何此类自动选择标准.



如果 server 对 representation 有首选项, 它 SHOULD 在 Location field 中包含该 representation 的具体 URI; user agent MAY 使用 Location field value 进行自动重定向. 除非另有指示, 此 response 可缓存.

10.3.2 301 Moved Permanently

所请求 resource 已分配新的永久 URI, 以后对此 resource 的任何引用 SHOULD 使用返回 URI 之一. 具有 link editing 能力的 client 应在可能时自动把对 Request-URI 的引用重新链接到 server 返回的新引用之一. 除非另有指示, 此 response 可缓存.

新的永久 URI SHOULD 由 response 中的 Location field 给出. 除非 request method 是 HEAD, response 的 entity SHOULD 包含一个简短 hypertext note, 其中带有指向新 URI 的 hyperlink.

如果针对 GET 或 HEAD 以外 request 收到 301 status code, user agent MUST NOT 自动重定向该 request, 除非能够由用户确认, 因为这可能改变发出 request 时的条件.

  注意: 在收到 301 status code 后自动重定向 POST request 时, 某些现有 HTTP/1.0 user agent 会错误地将其改为 GET request.

10.3.3 302 Found

所请求 resource 临时驻留在不同 URI 下. 由于重定向可能偶尔变化, client SHOULD 在未来 request 中继续使用 Request-URI. 只有在 Cache-Control 或 Expires header field 指示时, 此 response 才可缓存.

临时 URI SHOULD 由 response 中的 Location field 给出. 除非 request method 是 HEAD, response 的 entity SHOULD 包含一个简短 hypertext note, 其中带有指向新 URI 的 hyperlink.



如果针对 GET 或 HEAD 以外 request 收到 302 status code, user agent MUST NOT 自动重定向该 request, 除非能够由用户确认, 因为这可能改变发出 request 时的条件.

  注意: RFC 1945 和 RFC 2068 规定 client 不允许改变被重定向 request 的 method.
  但是, 大多数现有 user agent 实现会把 302 当作 303 response 处理,
  不管原始 request method 是什么, 都对 Location field-value 执行 GET.
  status code 303 和 307 是为希望明确说明 client 应采取哪种反应的 server 添加的.

10.3.4 303 See Other

对 request 的 response 可在不同 URI 下找到, 且 SHOULD 使用 GET method 在该 resource 上检索. 该 method 主要用于允许 POST 激活脚本的输出把 user agent 重定向到选定 resource. 新 URI 不是原始请求 resource 的替代引用. 303 response MUST NOT 被缓存, 但第二个 (被重定向) request 的 response 可能可缓存.

不同 URI SHOULD 由 response 中的 Location field 给出. 除非 request method 是 HEAD, response 的 entity SHOULD 包含一个简短 hypertext note, 其中带有指向新 URI 的 hyperlink.

  注意: 许多 HTTP/1.1 之前的 user agent 不理解 303 status.
  当需要与此类 client 互操作时, 可以改用 302 status code,
  因为大多数 user agent 对 302 response 的反应与此处针对 303 描述的相同.

10.3.5 304 Not Modified

如果 client 已执行 conditional GET request 且允许访问, 但 document 未被修改, server SHOULD 以此 status code 响应. 304 response MUST NOT 包含 message-body, 因而始终由 header field 后的第一个空行终止.

response MUST 包含以下 header field:

  - Date, 除非第 14.18.1 节要求省略



如果无时钟 origin server 遵守这些规则, 且 proxy 和 client 向任何未带 Date 的 response 添加自己的 Date (如 [RFC 2068] 第 14.19 节已规定), cache 将正确运行.

  - ETag 和/或 Content-Location, 如果同一 request 的 200 response 本会发送该 header

  - Expires, Cache-Control 和/或 Vary, 如果 field-value 可能不同于先前对同一 variant 的任一 response 中发送的值

如果 conditional GET 使用 strong cache validator (见第 13.3.3 节), response SHOULD NOT 包含其他 entity-header. 否则 (即 conditional GET 使用 weak validator), response MUST NOT 包含其他 entity-header; 这可防止缓存 entity-body 与更新后 header 之间不一致.

如果 304 response 指示一个当前未缓存的 entity, cache MUST 忽略该 response 并在无条件情况下重复 request.

如果 cache 使用收到的 304 response 更新 cache entry, cache MUST 更新该 entry, 以反映 response 中给出的任何新 field value.

10.3.6 305 Use Proxy

所请求 resource MUST 通过 Location field 给出的 proxy 访问. Location field 给出 proxy 的 URI. recipient 预期通过该 proxy 重复这一次 request. 305 response MUST 只由 origin server 生成.

  注意: RFC 2068 未明确说明 305 旨在重定向单个 request, 且只由 origin server 生成.
  不遵守这些限制会产生重大安全后果.

10.3.7 306 (Unused)

306 status code 曾在本规范先前版本中使用, 现在不再使用, 且该代码被保留.



10.3.8 307 Temporary Redirect

所请求 resource 临时驻留在不同 URI 下. 由于重定向 MAY 偶尔变化, client SHOULD 在未来 request 中继续使用 Request-URI. 只有在 Cache-Control 或 Expires header field 指示时, 此 response 才可缓存.

临时 URI SHOULD 由 response 中的 Location field 给出. 除非 request method 是 HEAD, response 的 entity SHOULD 包含一个简短 hypertext note, 其中带有指向新 URI 的 hyperlink, 因为许多 HTTP/1.1 之前的 user agent 不理解 307 status. 因此, 该 note SHOULD 包含用户在新 URI 上重复原始 request 所需的信息.

如果针对 GET 或 HEAD 以外 request 收到 307 status code, user agent MUST NOT 自动重定向该 request, 除非能够由用户确认, 因为这可能改变发出 request 时的条件.

10.4 Client Error 4xx

4xx 类 status code 用于 client 似乎出错的情况. 除响应 HEAD request 外, server SHOULD 包含一个 entity, 解释错误情况以及该情况是临时还是永久. 这些 status code 适用于任何 request method. user agent SHOULD 向用户显示任何包含的 entity.

如果 client 正在发送数据, 使用 TCP 的 server 实现 SHOULD 谨慎确保 client 确认收到包含 response 的 packet, 然后 server 再关闭 input connection. 如果 client 在关闭后继续向 server 发送数据, server 的 TCP stack 会向 client 发送 reset packet, 这可能在 HTTP 应用读取和解释 client 未确认的 input buffer 前将其擦除.

10.4.1 400 Bad Request

由于语法格式错误, server 无法理解 request. client SHOULD NOT 在不修改的情况下重复该 request.



10.4.2 401 Unauthorized

request 需要用户认证. response MUST 包含 WWW-Authenticate header field (第 14.47 节), 其中包含适用于所请求 resource 的 challenge. client MAY 使用适当 Authorization header field (第 14.8 节) 重复 request. 如果 request 已包含 Authorization credential, 则 401 response 表示这些 credential 的授权已被拒绝. 如果 401 response 包含与先前 response 相同的 challenge, 且 user agent 已至少尝试认证一次, 则 SHOULD 向用户呈现 response 中给出的 entity, 因为该 entity 可能包含相关诊断信息. HTTP access authentication 在 "HTTP Authentication: Basic and Digest Access Authentication" [43] 中说明.

10.4.3 402 Payment Required

此代码保留供将来使用.

10.4.4 403 Forbidden

server 理解 request, 但拒绝满足它. Authorization 无济于事, request SHOULD NOT 重复. 如果 request method 不是 HEAD, 且 server 希望公开说明 request 未被满足的原因, 它 SHOULD 在 entity 中描述拒绝原因. 如果 server 不希望向 client 提供此信息, 可以改用 status code 404 (Not Found).

10.4.5 404 Not Found

server 未找到任何与 Request-URI 匹配的内容. 不指明该情况是临时还是永久. 如果 server 通过某种内部可配置机制知道旧 resource 永久不可用且没有 forwarding address, SHOULD 使用 410 (Gone) status code. 当 server 不希望准确揭示 request 被拒绝的原因, 或没有其他 response 适用时, 通常使用此 status code.

10.4.6 405 Method Not Allowed

Request-Line 中指定的 method 不允许用于 Request-URI 所标识的 resource. response MUST 包含 Allow header, 其中列出所请求 resource 的有效 method.



10.4.7 406 Not Acceptable

request 所标识的 resource 只能生成具有某些 content characteristic 的 response entity, 而这些特征按照 request 中发送的 accept header 不可接受.

除非这是 HEAD request, response SHOULD 包含一个 entity, 其中包含可用 entity 特征和 location 列表, 用户或 user agent 可从中选择最适合的一项. entity 格式由 Content-Type header field 给出的 media type 指定. 根据格式和 user agent 能力, MAY 自动选择最适合的选项. 但是, 本规范不定义任何此类自动选择标准.

  注意: HTTP/1.1 server 允许返回按照 request 中发送的 accept header 不可接受的 response.
  在某些情况下, 这甚至可能优于发送 406 response. 鼓励 user agent 检查传入 response 的 header,
  以确定它是否可接受.

如果 response 可能不可接受, user agent SHOULD 暂时停止接收更多数据, 并询问用户对后续动作的决定.

10.4.8 407 Proxy Authentication Required

此代码类似 401 (Unauthorized), 但表示 client 必须先向 proxy 认证自身. proxy MUST 返回 Proxy-Authenticate header field (第 14.33 节), 其中包含适用于该 proxy 的对所请求 resource 的 challenge. client MAY 使用适当 Proxy-Authorization header field (第 14.34 节) 重复 request. HTTP access authentication 在 "HTTP Authentication: Basic and Digest Access Authentication" [43] 中说明.

10.4.9 408 Request Timeout

client 未在 server 准备等待的时间内产生 request. client MAY 在之后任意时间不加修改地重复 request.

10.4.10 409 Conflict

由于与 resource 当前状态冲突, request 无法完成. 该代码只允许用于预期用户可能能够解决冲突并重新提交 request 的情况. response body SHOULD 包含足够信息, 使用户能够识别冲突来源.



理想情况下, response entity 会包含足够信息, 供用户或 user agent 修复问题; 但是, 这可能不可行, 且不是必需的.

冲突最可能出现在对 PUT request 的响应中. 例如, 如果使用了版本控制, 且正在 PUT 的 entity 包含对某个 resource 的修改, 这些修改与先前 (第三方) request 所作修改冲突, server 可能使用 409 response 表示无法完成 request. 在这种情况下, response entity 很可能包含两个版本之间差异的列表, 其格式由 response Content-Type 定义.

10.4.11 410 Gone

所请求 resource 在 server 上不再可用, 且不知道 forwarding address. 该情况预期被视为永久. 具有 link editing 能力的 client SHOULD 在用户批准后删除对 Request-URI 的引用. 如果 server 不知道或没有机制确定该情况是否永久, SHOULD 改用 status code 404 (Not Found). 除非另有指示, 此 response 可缓存.

410 response 主要用于帮助 Web 维护工作, 通知 recipient 该 resource 被有意设为不可用, 且 server owner 希望移除指向该 resource 的远程 link. 对限时促销服务以及属于不再在 server 站点工作的个人的 resource, 此类事件很常见. 不必把所有永久不可用 resource 都标记为 "gone", 也不必将该标记保留任意时长 -- 这由 server owner 自行决定.

10.4.12 411 Length Required

server 拒绝接受没有定义 Content-Length 的 request. 如果 client 添加有效 Content-Length header field, 其中包含 request message 中 message-body 的长度, 则 MAY 重复 request.

10.4.13 412 Precondition Failed

在 server 上测试时, 一个或多个 request-header field 中给出的 precondition 求值为 false. 该 response code 允许 client 对当前 resource 元信息 (header field data) 设置 precondition, 从而防止所请求 method 被应用到非预期 resource.



10.4.14 413 Request Entity Too Large

server 拒绝处理 request, 因为 request entity 大于 server 愿意或能够处理的大小. server MAY 关闭 connection, 以防止 client 继续 request.

如果该情况是临时的, server SHOULD 包含 Retry-After header field, 指示该情况是临时的以及 client MAY 在什么时间之后重试.

10.4.15 414 Request-URI Too Long

server 拒绝服务 request, 因为 Request-URI 长于 server 愿意解释的长度. 这种少见情况只可能发生在 client 不正确地把 POST request 转换为带长 query 信息的 GET request, client 进入重定向 URI "black hole" (例如, 被重定向 URI 前缀指向自身后缀), 或 server 正遭受 client 试图利用某些 server 中使用固定长度缓冲区读取或操作 Request-URI 的安全漏洞的攻击时.

10.4.16 415 Unsupported Media Type

server 拒绝服务 request, 因为 request 的 entity 所用格式不受所请求 resource 针对所请求 method 的支持.

10.4.17 416 Requested Range Not Satisfiable

如果 request 包含 Range request-header field (第 14.35 节), 且该 field 中没有任何 range-specifier value 与所选 resource 的当前范围重叠, 并且 request 不包含 If-Range request-header field, server SHOULD 返回带此 status code 的 response. (对于 byte-range, 这意味着所有 byte-range-spec 值的 first-byte-pos 都大于所选 resource 的当前长度.)

当为 byte-range request 返回此 status code 时, response SHOULD 包含 Content-Range entity-header field, 指定所选 resource 的当前长度 (见第 14.16 节). 此 response MUST NOT 使用 multipart/byteranges content-type.



10.4.18 417 Expectation Failed

Expect request-header field (见第 14.20 节) 中给出的 expectation 无法由此 server 满足; 或者, 如果 server 是 proxy, 该 server 有明确证据表明 next-hop server 无法满足该 request.

10.5 Server Error 5xx

以数字 "5" 开头的 response status code 表示 server 知道自己出错或无法执行 request 的情况. 除响应 HEAD request 外, server SHOULD 包含一个 entity, 解释错误情况以及该情况是临时还是永久. user agent SHOULD 向用户显示任何包含的 entity. 这些 response code 适用于任何 request method.

10.5.1 500 Internal Server Error

server 遇到意外情况, 阻止其满足 request.

10.5.2 501 Not Implemented

server 不支持满足 request 所需的功能. 当 server 不识别 request method, 且无法为任何 resource 支持该 method 时, 这是适当 response.

10.5.3 502 Bad Gateway

server 在充当 gateway 或 proxy 时, 在尝试满足 request 的过程中, 从其访问的 upstream server 收到了无效 response.

10.5.4 503 Service Unavailable

server 当前因临时过载或维护而无法处理 request. 这意味着该情况是临时的, 经过一段延迟后会缓解. 如果已知, MAY 在 Retry-After header 中指示延迟长度. 如果未给出 Retry-After, client SHOULD 像处理 500 response 一样处理该 response.

  注意: 503 status code 的存在并不意味着 server 过载时必须使用它.
  某些 server 可能希望简单地拒绝 connection.



10.5.5 504 Gateway Timeout

server 在充当 gateway 或 proxy 时, 在尝试完成 request 的过程中, 未及时从 URI 指定的 upstream server (例如 HTTP, FTP, LDAP) 或它需要访问的某个其他辅助 server (例如 DNS) 收到 response.

  注意: 给实现者的说明: 已知某些已部署 proxy 在 DNS lookup 超时时会返回 400 或 500.

10.5.6 505 HTTP Version Not Supported

server 不支持或拒绝支持 request message 中使用的 HTTP protocol version. server 表明除了使用此 error message 外, 它无法或不愿使用与 client 相同的 major version 完成 request, 如第 3.1 节所述. response SHOULD 包含一个 entity, 说明为何不支持该版本以及该 server 支持哪些其他协议.