11. Status Code Extensions to HTTP/1.1 (HTTP/1.1 的状态码扩展)

以下状态码添加到 HTTP/1.1 [RFC2616] 中定义的状态码。

11.1 207 Multi-Status (多状态)

207 (Multi-Status, 多状态) 状态码为多个独立操作提供状态 (有关更多信息, 请参见第 13 节)。

11.2 422 Unprocessable Entity (无法处理的实体)

422 (Unprocessable Entity, 无法处理的实体) 状态码意味着服务器理解请求实体的内容类型 (因此 415(Unsupported Media Type) 状态码不合适), 并且请求实体的语法是正确的 (因此 400 (Bad Request) 状态码不合适), 但无法处理包含的指令。例如, 如果 XML 请求主体包含格式良好 (即语法正确) 但语义错误的 XML 指令, 则可能发生此错误条件。

11.3 423 Locked (已锁定)

423 (Locked, 已锁定) 状态码意味着方法的源或目标资源已锁定。此响应应该包含适当的前置条件或后置条件代码, 例如 'lock-token-submitted' 或 'no-conflicting-lock'。

11.4 424 Failed Dependency (失败的依赖)

424 (Failed Dependency, 失败的依赖) 状态码意味着无法对资源执行该方法, 因为请求的操作依赖于另一个操作, 而该操作失败了。例如, 如果 PROPPATCH 方法中的命令失败, 则至少其余命令也将失败并返回 424 (Failed Dependency)。

11.5 507 Insufficient Storage (存储空间不足)

507 (Insufficient Storage, 存储空间不足) 状态码意味着无法对资源执行该方法, 因为服务器无法存储成功完成请求所需的表示。此条件被视为临时的。如果收到此状态码的请求是用户操作的结果, 则在单独的用户操作请求之前, 绝对不能重复该请求。

12. Use of HTTP Status Codes (HTTP 状态码的使用)

这些 HTTP 代码没有重新定义, 但 WebDAV 方法和要求在某种程度上扩展了它们的使用。一般来说, 许多 HTTP 状态码可以用于响应任何请求, 而不仅仅是本文档中描述的情况。还请注意, 已知 WebDAV 服务器使用 300 级重定向响应 (早期互操作性测试发现客户端没有准备好看到这些响应)。当服务器响应请求创建了新资源时, 绝对不能使用 300 级响应。

12.1 412 Precondition Failed (前置条件失败)

任何请求都可以包含 HTTP 中定义的条件头 (If-Match, If-Modified-Since 等) 或本规范中定义的 "If" 或 "Overwrite" 条件头。如果服务器评估条件头, 并且该条件不成立, 则必须返回此错误代码。另一方面, 如果客户端在请求中不包含条件头, 则服务器绝对不能使用此状态码。

12.2 414 Request-URI Too Long (请求 URI 过长)

此状态码在 HTTP 1.1 中仅用于 Request-URIs, 而不用于其他位置的 URIs。

13. Multi-Status Response (多状态响应)

Multi-Status response (多状态响应) 在可能需要多个状态码的情况下传达有关多个资源的信息。默认的 Multi-Status 响应主体是具有 'multistatus' 根元素的 text/xml 或 application/xml HTTP 实体。其他元素包含在方法调用期间生成的 200, 300, 400 和 500 系列状态码。100 系列状态码不应该记录在 'response' XML 元素中。

尽管 '207' 用作总体响应状态码, 但接收者需要查阅 multistatus 响应主体的内容, 以获取有关方法执行成功或失败的更多信息。响应可以在成功, 部分成功以及失败情况下使用。

'multistatus' 根元素以任何顺序保存零个或多个 'response' 元素, 每个元素都包含有关单个资源的信息。每个 'response' 元素必须具有 'href' 元素来标识资源。

Multi-Status 响应使用两种不同格式之一来表示状态:

'response' 元素的子元素 'status' 指示整个标识资源的消息执行状态 (例如, 参见第 9.6.2 节)。一些方法定义提供了有关客户端应准备在响应中看到的特定状态码的信息。但是, 客户端必须能够使用 [RFC2616] 第 10 节中定义的通用规则处理其他状态码。
对于 PROPFIND 和 PROPPATCH, 格式已使用 'propstat' 元素而不是 'status' 进行扩展, 提供有关资源的各个属性的信息。此格式特定于 PROPFIND 和 PROPPATCH, 并在第 9.1 和 9.2 节中详细描述。

13.1 Response Headers (响应头)

HTTP 定义 Location 头来指示在 Request-URI 中寻址的资源的首选 URL (例如, 响应成功的 PUT 请求或重定向响应)。但是, 当响应主体中存在 URL 时 (如 Multi-Status), 使用此头会产生歧义。因此, 在 Multi-Status 响应中使用 Location 头是有意未定义的。

13.2 Handling Redirected Child Resources (处理重定向的子资源)

HTTP 1.1 中定义的重定向响应 (300-303, 305 和 307) 通常采用 Location 头来指示从 Request-URI 重定向的单个资源的新 URI。Multi-Status 响应包含许多资源地址, 但 [RFC2518] 中的原始定义没有为服务器提供重定向资源的新 URI 的任何位置。本规范确实为此信息定义了一个 'location' 元素 (参见第 14.9 节)。服务器必须在 Multi-Status 中的重定向响应中使用这个新元素。

在 Multi-Status 中遇到重定向资源的客户端绝对不能依赖 'location' 元素与新 URI 一起存在。如果该元素不存在, 则客户端可以向单个重定向资源重新发出请求, 因为对该请求的响应可以使用包含新 URI 的 Location 头进行重定向。

13.3 Internal Status Codes (内部状态码)

第 9.2.1, 9.1.2, 9.6.1, 9.8.3 和 9.9.2 节定义了在 Multi-Status 响应中使用的各种状态码。本规范不定义可能出现在这些响应中的其他状态码的含义。