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

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

虽然'207'用作整体响应状态码,但接收方需要查阅多状态响应主体的内容以获取有关方法执行成功或失败的更多信息.响应可以用于成功,部分成功以及失败情况.

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

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

作为'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时(如多状态),使用此头会产生歧义.因此,在多状态响应中使用Location头是故意未定义的.

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

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

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

13.3. 内部状态码 (Internal Status Codes)

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