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节定义了多状态响应中使用的各种状态代码。本规范未定义可能在这些响应中出现的其他状态代码的含义。