Multi-Status

Description

Examples

PROPFIND /webdav/project/ HTTP/1.1
Host: dav.example.com
Depth: 1
Content-Type: application/xml
Authorization: Bearer token123

<?xml version="1.0" encoding="utf-8"?>
<D:propfind xmlns:D="DAV:">
  <D:prop>
    <D:getcontentlength/>
    <D:getlastmodified/>
    <D:resourcetype/>
  </D:prop>
</D:propfind>

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

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:">
  <D:response>
    <D:href>/webdav/project/</D:href>
    <D:propstat>
      <D:prop>
        <D:resourcetype><D:collection/></D:resourcetype>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <D:response>
    <D:href>/webdav/project/report.pdf</D:href>
    <D:propstat>
      <D:prop>
        <D:getcontentlength>2048576</D:getcontentlength>
        <D:getlastmodified>Mon, 15 Jan 2024 10:00:00 GMT</D:getlastmodified>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <D:response>
    <D:href>/webdav/project/secret.docx</D:href>
    <D:propstat>
      <D:prop/>
      <D:status>HTTP/1.1 403 Forbidden</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>

POST /api/v1/messages/batch-delete HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer admin-token

{"ids": ["msg_001", "msg_002", "msg_003", "msg_004"]}

HTTP/1.1 207 Multi-Status
Content-Type: application/json

{"results": [{"id": "msg_001", "status": 200, "message": "Deleted"}, {"id": "msg_002", "status": 200, "message": "Deleted"}, {"id": "msg_003", "status": 404, "message": "Message not found"}, {"id": "msg_004", "status": 423, "message": "Message is locked by retention policy"}]}

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

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:">
  <D:response>
    <D:href>/webdav/dest/file1.txt</D:href>
    <D:status>HTTP/1.1 201 Created</D:status>
  </D:response>
  <D:response>
    <D:href>/webdav/dest/file2.txt</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>/webdav/dest/file3.txt</D:href>
    <D:status>HTTP/1.1 424 Failed Dependency</D:status>
  </D:response>
</D:multistatus>

Edge Cases

• •207 does NOT mean success — a response where every inner status is 4xx or 5xx is still wrapped in a 207. Clients MUST parse the body to find actual outcomes.
• •If ALL sub-operations fail with the same error, the server MAY return that error directly (e.g., 403) instead of wrapping in 207. Only use 207 when results genuinely vary.
• •424 Failed Dependency frequently appears INSIDE a 207 body — it signals that a sub-operation failed because another sub-operation it depended on already failed (cascade failure).
• •The Depth header in WebDAV PROPFIND controls whether 207 returns results for just the target (Depth: 0), immediate children (Depth: 1), or the entire subtree (Depth: infinity).
• •Non-WebDAV APIs using 207 for batch operations often use JSON instead of XML, but the semantic contract is identical: outer code = container, inner codes = verdicts.
• •A 207 response body can be extremely large for deep collection operations — clients should stream-parse rather than buffering the entire response before processing.
• •Some proxies and CDNs may cache 207 responses incorrectly because they treat all 2xx as cacheable successes. Use Cache-Control: no-store when 207 responses contain mutable or per-user data.

When You'll See This

• →WebDAV PROPFIND retrieving properties of all files in a folder — some accessible, some permission-denied
• →COPY or MOVE of a collection where some destination resources are locked by other users
• →Batch API deleting 20 items where 3 are not found, 2 are locked, and 15 succeed
• →Microsoft Graph batch endpoint processing 10 API calls — mix of successes and rate-limited failures
• →CalDAV/CardDAV syncing multiple calendar events or contacts where some have conflicts
• →Bulk permission update on a file tree where some files have inherited locks
• →PROPPATCH setting multiple properties on a resource — some writable, some read-only

Implementation References

History

Introduced in RFC 2518 (1999) as part of the original WebDAV specification by Jim Whitehead and Yaron Goland. The problem it solved: HTTP's single-status-per-response model broke down when a single request (like COPY of a directory tree) affected dozens of resources that could independently succeed or fail. RFC 4918 (2007) revised and updated the WebDAV specification, retaining 207 with clarified semantics. The concept migrated beyond WebDAV as batch APIs became common — Microsoft's Graph API (2015+) adopted 207 for batch request endpoints, establishing a pattern that other cloud APIs followed. The status code remains registered under IANA's HTTP Status Code Registry referencing RFC 4918.

Related Status Codes

Related Headers

FAQ