HTTP 424 Failed Dependency
Quick reference
| Code | 424 |
|---|---|
| Name | Failed Dependency |
| Category | 4xx Client Error |
| Spec | RFC 4918 §11.4 |
| Used inside | 207 Multi-Status response body |
What 424 means
HTTP 424 Failed Dependency means a WebDAV method failed not because of an intrinsic problem with that specific operation, but because another operation it depends on had already failed. 424 is part of WebDAV's atomicity reporting mechanism: when a PROPPATCH or similar multi-part operation fails partway through, every sub-operation that did not fail on its own but could not proceed because of the earlier failure is marked 424.
RFC 4918 §11.4 defines 424 specifically for use within the XML body of a 207 Multi-Status response. Each failed or skipped property operation in a PROPPATCH gets its own <D:response> element. Properties that failed for their own reasons get their actual error code (403, 409, etc.). Properties that were rolled back or skipped because a different property failed get 424.
The design intent is atomic multi-property updates. PROPPATCH is supposed to either apply all property changes successfully or roll back all of them if any fail. 424 tells the client which properties were collateral victims of the actual failure.
PROPPATCH atomicity and 424
A PROPPATCH request can set and remove multiple properties in a single request:
PROPPATCH /documents/report.docx HTTP/1.1
Host: dav.example.com
Content-Type: application/xml
<?xml version="1.0" encoding="UTF-8"?>
<D:propertyupdate xmlns:D="DAV:" xmlns:Z="http://example.com/ns/">
<D:set>
<D:prop>
<Z:author>Alice</Z:author>
<Z:department>Engineering</Z:department>
<Z:readonly/>
</D:prop>
</D:set>
</D:propertyupdate>
If the server can set Z:author and Z:department but cannot set Z:readonly (a protected property), and PROPPATCH atomicity requires all-or-nothing, the server rolls back Z:author and Z:department and reports them as 424:
HTTP/1.1 207 Multi-Status
Content-Type: application/xml
<?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:Z="http://example.com/ns/">
<D:response>
<D:href>/documents/report.docx</D:href>
<!-- This one actually failed -->
<D:propstat>
<D:prop><Z:readonly/></D:prop>
<D:status>HTTP/1.1 403 Forbidden</D:status>
</D:propstat>
<!-- These failed because Z:readonly failed (dependency) -->
<D:propstat>
<D:prop>
<Z:author/>
<Z:department/>
</D:prop>
<D:status>HTTP/1.1 424 Failed Dependency</D:status>
</D:propstat>
</D:response>
</D:multistatus>
Reading this response, the client knows the actual blocker is Z:readonly returning 403. The author and department properties are fine — they will succeed once the readonly issue is resolved.
424 in non-WebDAV bulk APIs
Some non-WebDAV APIs use 424 (or an analogous concept in their response bodies) for batch operations where one item failing blocks others. This is a non-standard use, but the semantics map cleanly: "this item did not fail on its own — it failed because something it depended on failed first."
In distributed systems, 424 is occasionally used when an operation fails because a prerequisite microservice call failed. For example, an order creation API that must first reserve inventory might return 424 if the inventory reservation fails, to indicate that the order record itself was not the source of failure.
If you use 424 outside WebDAV, document the dependency clearly in the response body so clients can distinguish the root cause (the actual failure) from the dependent failures (424).
Fixing 424 errors
A 424 in a PROPPATCH response is never the root cause — it is a symptom. To resolve it: find the property or operation in the same 207 response body that returned a non-424 error code (403, 409, 423, etc.), fix that underlying issue, and resubmit the PROPPATCH.
If the failing property is a server-protected property (marked read-only by the WebDAV implementation), remove it from the PROPPATCH set operation. If it returned 403 due to access control, ensure the client has write permission on that property namespace. If it returned 423 Locked, release the lock before modifying properties.
424 vs related codes
| Code | Meaning | Difference from 424 |
|---|---|---|
| 424 | Dependency failure — another action failed first | — |
| 207 Multi-Status | Multiple statuses in one response | The outer wrapper that contains 424 entries |
| 412 Precondition Failed | Conditional header was false | Client-supplied precondition; not a dependency relationship |
| 409 Conflict | State conflict prevents operation | Conflict with current resource state, not a dependency |
Frequently asked questions
Is 424 always inside a 207 response?
Per RFC 4918, yes — 424 is defined for use within 207 Multi-Status response bodies. As a top-level response, it is non-standard. Some APIs use it as a top-level code for dependency failures in non-WebDAV contexts, but this is not covered by any RFC.
How do I find the root cause when I receive 424 entries?
Look at all <D:propstat> elements in the same <D:response> block. The one with a non-424 error code (403, 409, 423, etc.) is the actual failure. Every 424 in the same response is a dependency of that root failure.
Does PROPPATCH always use 424 for rollbacks?
RFC 4918 requires PROPPATCH to be atomic — either all succeed or none take effect. The failed properties get their actual error codes. Successfully-set properties that were rolled back due to the failure get 424. This behavior is required by the spec and not optional for compliant WebDAV servers.
Can 424 appear in COPY or MOVE operations?
RFC 4918 defines 424 for use in property operations (PROPPATCH). COPY and MOVE operations that involve property setting may also use 424 in their 207 response bodies if property setting is part of the operation and a dependency fails, but this is less common in practice.