Skip to content
Control Plane Labs

424 Failed Dependency

Client error response defined by RFC 4918 §11.4.

Last updated July 27, 2026

Common causes at a glance

  • A member of a deep DELETE or COPY failed, so siblings were abandoned
  • One property in an atomic PROPPATCH was rejected, invalidating the rest
  • A locked or permission-denied child resource aborting a collection operation
  • Non-WebDAV APIs reusing 424 to mean an upstream dependency call failed

Reproduce it

curl -i -X DELETE -H 'Depth: infinity' https://dav.example.com/projects/archive/

What 424 Failed Dependency means

WebDAV methods routinely operate on many resources at once: a deep DELETE, a COPY of a collection, a PROPPATCH setting several properties in one atomic instruction. When one part fails, the server needs a way to report the rest. 424 is that marker: this resource was not tried, or was rolled back, because a sibling operation failed.

So a 424 on its own tells you nothing about the real problem. It is a pointer. Somewhere else in the same response there is a 403, a 423, or a 507 that is the actual failure, and that is the one to fix.

What the spec says

RFC 4918 §11.4 defines 424 and notes it can appear in the status element of a response inside a 207 Multi-Status body, described in §13. PROPPATCH is the clearest case: §9.2 requires the instructions to be applied atomically, so if one property update is rejected every other property in the request is reported 424. The spec also says a server should not use 424 in place of the real error when it knows the actual cause for that resource, which is why a good implementation hands you one genuine failure and a pile of 424s rather than 424 everywhere.

What actually causes it

Inside WebDAV, 424 is nearly always downstream of a 423 or a 403 on one child of a collection: a deep DELETE across a thousand files hits one locked document and the whole operation reports partial failure. Outside WebDAV, some APIs have borrowed 424 to mean “a service this endpoint calls returned an error”, which is a reasonable-sounding but non-standard reading. 502 or 503 describe an upstream failure with far less ambiguity. If you are designing an API, do not reach for this code.

How to debug it

Never debug the 424 itself. Fetch the full 207 body and find the entry whose status is not 424:

curl -sS -X DELETE -H 'Depth: infinity' \
https://dav.example.com/projects/archive/ | xmllint --format -

Each response element pairs an href with a status. Scan for the one carrying 403, 423, or 507 — that href is the resource that actually blocked the operation. For a 423, chase the lock with a lockdiscovery PROPFIND. For a 403, check permissions on that single path, not the collection root.

If you are seeing 424 as a top-level status from a non-WebDAV API, the vendor is using it loosely; read their documentation, because there is no interoperable meaning to rely on and the status reference will not help here.

Working examples

curl

# Deep operations return 207 with per-resource statuses. Format the XML to read it.
curl -sS -X DELETE -H 'Depth: infinity' \
  https://dav.example.com/projects/archive/ | xmllint --format -

# The href next to a 403 or 423 is the real failure; every 424 is collateral.

Python (requests)

import requests
import xml.etree.ElementTree as ET

resp = requests.delete(
    "https://dav.example.com/projects/archive/",
    headers={"Depth": "infinity"},
    timeout=60,
)
if resp.status_code == 207:
    ns = {"d": "DAV:"}
    for r in ET.fromstring(resp.text).findall("d:response", ns):
        href = r.findtext("d:href", namespaces=ns)
        status = r.findtext("d:status", namespaces=ns) or ""
        if "424" not in status:  # this is the one that actually failed
            print(href, status)

Node (fetch)

const res = await fetch("https://dav.example.com/projects/archive/", {
  method: "DELETE",
  headers: { Depth: "infinity" },
});

const xml = await res.text();
// Pull out every href/status pair and ignore the 424 noise.
const pairs = /<d:href>(.*?)<\/d:href>[\s\S]*?<d:status>(.*?)<\/d:status>/g;
for (const [, href, status] of xml.matchAll(pairs)) {
  if (!status.includes("424")) console.log("root cause:", href, status);
}

Reference and tooling

The authoritative list of assigned status codes is theIANA HTTP Status Code Registry. For a searchable copy with the semantics summarised, use theHTTP status code reference on this site. To see exactly what a server is sending, theheader inspector shows the raw status line and response headers, and thecurl builder assembles the request flags for you.

Other 4xx codes