2.1 KiB
| set | code | title | references | ||
|---|---|---|---|---|---|
| 2 | 207 | Multi-Status |
|
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:
1. 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 RFC4918 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.
2. 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 RFC4918 Sections 9.1 and RFC4918 9.2.
Source: RFC4918 Section 13