2015-11-06 22:55:41 +01:00
|
|
|
---
|
|
|
|
|
set: 2
|
|
|
|
|
code: 207
|
|
|
|
|
title: Multi-Status
|
2015-11-07 02:41:41 +01:00
|
|
|
references:
|
|
|
|
|
"Rails HTTP Status Symbol": ":multi_status"
|
2015-11-06 22:55:41 +01:00
|
|
|
---
|
|
|
|
|
|
2015-11-07 02:41:41 +01:00
|
|
|
A Multi-Status response conveys information about multiple resources in
|
2015-11-07 06:31:20 +01:00
|
|
|
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.
|
2015-11-07 02:41:41 +01:00
|
|
|
|
|
|
|
|
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
|
2015-11-09 01:28:54 +01:00
|
|
|
of the message execution for the identified resource as a
|
|
|
|
|
whole<sup>[1](#ref-1)</sup>. Some method definitions provide information
|
2015-11-07 02:41:41 +01:00
|
|
|
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
|
2015-11-07 04:03:35 +01:00
|
|
|
rules defined in [Section 10 of RFC2616][3].
|
2015-11-07 02:41:41 +01:00
|
|
|
|
|
|
|
|
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
|
2015-11-07 04:03:35 +01:00
|
|
|
described in detail in [RFC4918 Sections 9.1][4] and [RFC4918 9.2][5].
|
2015-11-07 02:41:41 +01:00
|
|
|
|
2015-11-09 01:28:54 +01:00
|
|
|
---
|
|
|
|
|
|
|
|
|
|
* <span id="ref-1"><sup>1</sup> Example - DELETE [RFC4918 Section 9.6.2][2]</span>
|
|
|
|
|
* Source: [RFC4918 Section 13][1]
|
2015-11-07 02:41:41 +01:00
|
|
|
|
2015-11-07 04:03:35 +01:00
|
|
|
[1]: <http://tools.ietf.org/html/rfc4918#section-13>
|
|
|
|
|
[2]: <http://tools.ietf.org/html/rfc4918#section-9.6.2>
|
|
|
|
|
[3]: <http://tools.ietf.org/html/rfc2616#section-10>
|
|
|
|
|
[4]: <http://tools.ietf.org/html/rfc4918#section-9.1>
|
|
|
|
|
[5]: <http://tools.ietf.org/html/rfc4918#section-9.2>
|
