207 Multi-Status

When a single request affects multiple resources, the server responds with the 207 Multi-Status status code. Unlike other 2xx status codes, 207 Multi-Status does not signal outright success. The message body contains an aggregate block of individual status codes, one per sub-operation.

Table of Contents

Usage

A 207 Multi-Status response arrives when a single HTTP request touches multiple resources. For example, a POST request updating several databases might succeed on some and fail on others. The response body lists individual results for each resource.

By default, the body is an XML document with a multistatus root element. The client parses each node to determine the outcome of every sub-operation.

The root element contains zero or more response elements in any order. Each response includes an href element identifying the target resource. Two formats exist: the status refers either to the resource as a whole, or to specific properties of the resource.

Status of the resource as a whole

A child status element holds the resulting HTTP status code for the identified resource. Clients are expected to handle standard HTTP status codes found here.

<d:response>
  <d:href>http://example.re/tasks</d:href>
  <d:status>HTTP/1.1 200 OK</d:status>
</d:response>

Status of individual properties

The PROPFIND and PROPPATCH methods use propstat in place of status to report on individual properties of a resource.

<d:response>
  <d:href>http://example.re/tasks</d:href>
  <d:propstat>
    <d:prop>
      <d:getcontentlanguage>
        "en-CA"
      </d:getcontentlanguage>
    </d:prop>
    <d:status>HTTP/1.1 200 OK</d:status>
  </d:propstat>
</d:response>

Success or failure indication

A 207 Multi-Status response signals overall success, overall failure, or a mix of both. The client examines each response element to assess completeness of the operation.

Example

A WebDAV client deletes a collection. The server removes every member it can, and the 207 response lists only the members the delete failed on, both held by locks. Members removed cleanly are absent from the body, so the client reads the response as a list of leftovers to resolve.

Request

DELETE /projects/ HTTP/1.1
Host: www.example.re
Depth: infinity

Response

HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: 456

<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV:">
  <d:response>
    <d:href>http://example.re/projects/specs/</d:href>
    <d:status>HTTP/1.1 423 Locked</d:status>
    <d:error><d:lock-token-submitted/></d:error>
  </d:response>
  <d:response>
    <d:href>http://example.re/projects/drafts/plan.doc</d:href>
    <d:status>HTTP/1.1 423 Locked</d:status>
    <d:error><d:lock-token-submitted/></d:error>
  </d:response>
</d:multistatus>

Code references

.NET

HttpStatusCode.MultiStatus

Rust

http::StatusCode::MULTI_STATUS

Rails

:multi_status

Go

http.StatusMultiStatus

Symfony

Response::HTTP_MULTI_STATUS

Python3.5+

http.HTTPStatus.MULTI_STATUS

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_MULTI_STATUS

Angular

@angular/common/http/HttpStatusCode.MultiStatus

See also

Last updated: August 17, 2026