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

在可能需要多个状态代码的情况下，Multi-Status 用于响应传达多个资源的相关信息。默认的多状态响应 body 是一个带有'multistatus'根元素的 text/xml 或 application/xml 格式 HTTP 响应实体，其他在方法调用期间生成的 200、300、400 和 500 系列状态代码会被包含在它的下级元素中。但是 100 系列状态代码不应在“response”节点中被记录。

尽管将“207”用作总体响应状态代码，但是接收者还需要查询多状态响应主体的内容，以获取有关方法执行成功或失败的更多信息。所以，该响应可以用于成功，部分成功以及失败情况。

“multistatus”根元素以任何顺序保存零个或多个“response”元素，每个元素都包含有关单个资源的信息。每个“response”元素必须具有一个“href”元素以标识对应的资源。

多状态响应使用两种不同格式中的一种来表示状态：

• 作为“response”元素的子元素的“status”元素会指示整个被标识资源的执行状态（请参见第 9.6.2 节）。一些方法定义提供了客户端应该查看的特定状态码信息。但是，客户端必须能够使用[RFC2616]第 10 节中定义的通用规则来处理其他状态代码。
• 对于 PROPFIND 和 PROPPATCH，没有使用'status'而是使用'propstat'元素来扩展其响应格式，并提供对应资源的各个属性信息。该格式专用于 PROPFIND 和 PROPPATCH，并在 9.1 和 9.2 节中进行了详细说明。

13.1 Response Headers

HTTP 定义了一个 Location header，以指示在 Request-URI 中寻址资源的首选 URL（例如，成功的 PUT 请求响应或重定向响应）。但是，当响应的 body 中有 URL（正如 Multi-Status 响应中那样）时，使用此 header 会产生歧义。因此，我们故意未定义将 Location header 与 Multi-Status 响应一起使用。

13.2 处理重定向的子资源

HTTP 1.1 中定义的重定向响应（300-303、305 和 307）通常采用 Location header，以指示从 Request-URI 重定向的单个资源的新 URI。多状态响应包含许多资源地址，但是[RFC2518]中的原始定义没有任何地方让服务器为重定向的多个资源提供新 URIs。本规范确实为这个信息定义了一个“location”元素（请参见第 14.9 节）。服务器必须在 Multi-Status 中将此新元素与重定向响应一起使用。

客户端在多状态中遇到重定向的资源时，不得依赖带'location'节点中的新 URI。如果它不存在，客户端可以将请求重新发出到各个重定向的资源，因为单个的请求会带有可靠的新 Location header 从而实现对该请求的重定向响应。

13.3 内部状态码

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