< HTTP/1.1 207 Multi-Status

TL;DR: 207 Multi-Status is a WebDAV code (RFC 4918) that wraps several independent results in an XML multistatus body. The top-level 207 only means “here is the report”: read each <response> element’s own <status> to know what happened.

What it means

When one request touches many resources (listing a collection, deleting a folder, moving a tree), the outcome can be mixed. Rather than choosing one status, the server returns 207 and a body with one result per resource.

PROPFIND /files/ HTTP/1.1
Host: dav.example.com
Depth: 1
Content-Type: application/xml

<?xml version="1.0"?>
<d:propfind xmlns:d="DAV:"><d:prop><d:getcontentlength/></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>/files/report.pdf</d:href>
    <d:propstat>
      <d:prop><d:getcontentlength>2457600</d:getcontentlength></d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
  </d:response>
  <d:response>
    <d:href>/files/secret.txt</d:href>
    <d:status>HTTP/1.1 403 Forbidden</d:status>
  </d:response>
</d:multistatus>

A mixed failure for a DELETE /files/ on a collection looks the same: report.pdf could be deleted, secret.txt returned 403. The collection itself is not removed, and the 207 lists only the member that failed. RFC 4918 section 9.6.1 says a server SHOULD NOT add 424 Failed Dependency entries for the ancestors in a DELETE, because the client can infer them. Where 424 does show up is inside a PROPPATCH response, when one property change fails and the rest are rolled back with it.

Every <response> carries either a <status> for the whole resource or one or more <propstat> blocks with property-level statuses (some properties 200, others 404 because they do not exist).

Where you will meet it

• WebDAV file servers: Apache mod_dav, nginx with the DAV module, Nextcloud, ownCloud, SharePoint, Synology.
• CalDAV and CardDAV: calendar and contacts sync (REPORT and PROPFIND), including iCloud, Google Calendar’s CalDAV endpoint, Radicale and Fastmail.
• Mounting network drives (macOS Finder, Windows “Map network drive”), rclone, cadaver and davfs2.

curl -s -X PROPFIND -H 'Depth: 1' -u alice https://dav.example.com/files/ | xmllint --format -

Handling it correctly

1. Treat 207 as a transport success only. Parse the XML, loop over response elements, and apply per-item status.
2. For writes, treat any non-2xx entry as a partial failure and decide whether to roll back or retry only the failed items.
3. Depth: infinity PROPFIND on big trees is expensive and often disabled; servers answer 403 with <d:propfind-finite-depth/>.
4. Do not rely on caching 207 responses. They are not in the set of status codes cacheable by default, and the body depends on the request body (PROPFIND, REPORT).

const xml = new DOMParser().parseFromString(await res.text(), 'application/xml')
for (const r of xml.getElementsByTagNameNS('DAV:', 'response')) {
  const href = r.getElementsByTagNameNS('DAV:', 'href')[0].textContent
  const status = r.getElementsByTagNameNS('DAV:', 'status')[0]?.textContent
  if (status && !/\s2\d\d\s/.test(status)) console.warn(href, status)
}

This only reads the response-level status; check each propstat too if you care about property results.

Related

• 424 Failed Dependency
• 423 Locked
• 200 OK: use a plain 200 when there is nothing per-resource to report.
• 507 Insufficient Storage: another WebDAV code.
• Status codes overview