HTTP 207 Multi-Status – Free, Online, Private
207 Multi-Status is a WebDAV response whose body lists a status per resource.
What HTTP 207 means
207 means the body is a multi-status document, usually XML, with a separate status for each URL in a batch. The HTTP status is 207 even when some members failed. Clients that only look at 207 and assume every member succeeded will miss a 403 or 404 inside the document. The type is defined by WebDAV.
207 Multi-Status belongs to the 2xx successful class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.
When you see HTTP 207
When you see HTTP 207 Multi-Status, stop on that exact status line. 207 Multi-Status is a WebDAV response whose body lists a status per resource. The trace that usually produces it: PROPFIND returned one response element per property. The 2xx successful class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.
Return 207 for WebDAV operations that touch several resources, such as PROPFIND or a multi-target COPY. Do not use 207 as a cute wrapper for a JSON array of results in an API that is not WebDAV, unless you document the body and every client knows to read it. A single resource should use a single status.
How to fix HTTP 207
To fix HTTP 207, change the condition that made the server choose Multi-Status. Parse the body and handle each member's status. Do not stop at the HTTP code. If you cannot parse multi-status XML, you cannot use this endpoint. Retrying the batch retries every member, including the ones that succeeded. Retry the failed members if the operation is safe to repeat. If the log line is a different code, leave this page. The mix-up people make with 207 is this one: 200 with a list is easier for JSON APIs and does not pretend to be WebDAV. 207 is the WebDAV multi-status code.
- A batch API copied 207 and clients ignored the inner failures.
- The body was JSON while the client expected the WebDAV XML vocabulary.
- One member failed and the outer 207 made the operation look successful in a metric that only counts HTTP codes.
An access log that only stores 207 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.
Example response
HTTP 207 Multi-StatusHTTP/1.1 207 Multi-Status
Content-Type: application/xml
The body is a multistatus document. Each response element has an href and a status. You have to read them. A metric labeled '2xx rate' will count this as success even when every member is 404. Split those metrics if you operate a server that emits 207.
What the client should do
Parse the body and handle each member's status. Do not stop at the HTTP code. If you cannot parse multi-status XML, you cannot use this endpoint.
Do not cache 207 as a generic representation unless the whole multi-status result is itself a defined resource. Member URLs have their own cache entries.
Retrying the batch retries every member, including the ones that succeeded. Retry the failed members if the operation is safe to repeat.
Codes people confuse with HTTP 207
200 with a list is easier for JSON APIs and does not pretend to be WebDAV. 207 is the WebDAV multi-status code.
Frequently asked questions
Does 207 mean every item succeeded?
No. The per-resource status is in the body. Some may have failed.
Is the body JSON?
In WebDAV it is XML. A JSON 207 is a private convention you must document.
Should a normal REST API use 207?
Prefer a 200 body you define, or one status per request. 207 surprises generic clients.
How do dashboards misread it?
They count the outer 207 as success and hide the inner 4xx lines.
What should I do first when I see HTTP 207?
Read the status as 207 Multi-Status specifically. 207 Multi-Status is a WebDAV response whose body lists a status per resource. Then check the cause that matches the request you sent, starting with: PROPFIND returned one response element per property.