11. HTTP/1.1的状态码扩展 (Status Code Extensions to 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)状态码意味着无法对资源执行该方法,因为服务器无法存储成功完成请求所需的表示。此条件被认为是临时的。如果收到此状态码的请求是用户操作的结果,则在由单独的用户操作请求之前,不得重复该请求。

These HTTP codes are not redefined, but their use is somewhat extended by WebDAV methods and requirements. In general, many HTTP status codes can be used in response to any request, not just in cases described in this document. Note also that WebDAV servers are known to use 300-level redirect responses (and early interoperability tests found clients unprepared to see those responses). A 300-level response MUST NOT be used when the server has created a new resource in response to the request.

12.1 412 Precondition Failed

Any request can contain a conditional header defined in HTTP (If-Match, If-Modified-Since, etc.) or the "If" or "Overwrite" conditional headers defined in this specification. If the server evaluates a conditional header, and if that condition fails to hold, then this error code MUST be returned. On the other hand, if the client did not include a conditional header in the request, then the server MUST NOT use this status code.

12.2 414 Request-URI Too Long

This status code is used in HTTP 1.1 only for Request-URIs, not URIs in other locations.

13. Multi-Status Response

A Multi-Status response conveys information about multiple resources in situations where multiple status codes might be appropriate. The default Multi-Status response body is a text/xml or application/xml HTTP entity with a 'multistatus' root element. Further elements contain 200, 300, 400, and 500 series status codes generated during the method invocation. 100 series status codes SHOULD NOT be recorded in a 'response' XML element.

Although '207' is used as the overall response status code, the recipient needs to consult the contents of the multistatus response body for further information about the success or failure of the method execution. The response MAY be used in success, partial success and also in failure situations.

The 'multistatus' root element holds zero or more 'response' elements in any order, each with information about an individual resource. Each 'response' element MUST have an 'href' element to identify the resource.

A Multi-Status response uses one out of two distinct formats for representing the status:

A 'status' element as child of the 'response' element indicates the status of the message execution for the identified resource as a whole (for instance, see Section 9.6.2). Some method definitions provide information about specific status codes clients should be prepared to see in a response. However, clients MUST be able to handle other status codes, using the generic rules defined in Section 10 of [RFC2616].
For PROPFIND and PROPPATCH, the format has been extended using the 'propstat' element instead of 'status', providing information about individual properties of a resource. This format is specific to PROPFIND and PROPPATCH, and is described in detail in Sections 9.1 and 9.2.

13.1 Response Headers

HTTP defines the Location header to indicate a preferred URL for the resource that was addressed in the Request-URI (e.g., in response to successful PUT requests or in redirect responses). However, use of this header creates ambiguity when there are URLs in the body of the response, as with Multi-Status. Thus, use of the Location header with the Multi-Status response is intentionally undefined.

13.2 Handling Redirected Child Resources

Redirect responses (300-303, 305, and 307) defined in HTTP 1.1 normally take a Location header to indicate the new URI for the single resource redirected from the Request-URI. Multi-Status responses contain many resource addresses, but the original definition in [RFC2518] did not have any place for the server to provide the new URI for redirected resources. This specification does define a 'location' element for this information (see Section 14.9). Servers MUST use this new element with redirect responses in Multi-Status.

Clients encountering redirected resources in Multi-Status MUST NOT rely on the 'location' element being present with a new URI. If the element is not present, the client MAY reissue the request to the individual redirected resource, because the response to that request can be redirected with a Location header containing the new URI.

13.3 Internal Status Codes

Sections 9.2.1, 9.1.2, 9.6.1, 9.8.3, and 9.9.2 define various status codes used in Multi-Status responses. This specification does not define the meaning of other status codes that could appear in these responses.