< HTTP/1.1 424 Failed Dependency

TL;DR: 424 says “I did not do this because something it depends on failed.” It almost always appears inside a WebDAV 207 body next to the entry that holds the real error. Fix that entry and the 424s go away.

What it means

PROPPATCH is atomic: if you set three properties and one fails, none are applied. The server reports the failing property with its real status, and the other two with 424.

PROPPATCH /files/report.pdf HTTP/1.1
Host: dav.example.com
Content-Type: application/xml

<?xml version="1.0"?>
<d:propertyupdate xmlns:d="DAV:" xmlns:x="http://example.com/ns">
  <d:set><d:prop><x:author>Alice</x:author><d:getetag>"forged"</d:getetag></d:prop></d:set>
</d:propertyupdate>

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

<d:multistatus xmlns:d="DAV:" xmlns:x="http://example.com/ns">
  <d:response>
    <d:href>/files/report.pdf</d:href>
    <d:propstat>
      <d:prop><d:getetag/></d:prop>
      <d:status>HTTP/1.1 403 Forbidden</d:status>
    </d:propstat>
    <d:propstat>
      <d:prop><x:author/></d:prop>
      <d:status>HTTP/1.1 424 Failed Dependency</d:status>
    </d:propstat>
  </d:response>
</d:multistatus>

getetag is a protected property (403), so the otherwise valid author update was rolled back and marked 424. Collection operations differ: when a DELETE on a collection fails because one child is locked (423), RFC 4918 section 9.6.1 says the 207 should list only the failing child, not 424 entries for its ancestors, and the collection is left in place.

What to do

1. Read the whole 207 body, not only the 424 entries.
2. Locate the non-424 failure and fix it: protected property, lock token missing, permission, conflicting state.
3. Re-send the request unchanged. Because the operation is atomic, nothing was partially applied.
4. If you are implementing a WebDAV server, use 424 only for operations skipped due to another failure in the same request, never as a generic “dependency down” error. For that, 502, 503 or 504 are what clients and monitoring understand.

How clients should treat it

The 424 entries are not independent failures, so counting them as separate errors in logs and dashboards overstates the damage. Group them under the entry that caused them. If your client library flattens a multistatus body into a list of per-resource errors, keep the original order: servers list the root cause first, and the dependents follow.

A second trap is retry logic. Retrying only the 424 items does not work, because they were skipped and are waiting on the failed item. Fix the root cause and resend the whole request. For a PROPPATCH, nothing was applied, so a clean retry after fixing the offending property is safe.

Finally, in practice WebDAV servers use 424 for the PROPPATCH case above. If you see 424 on a plain, single-resource request outside WebDAV, the server is using the code in a custom way and its documentation is the only authority.

Try it with curl

424 Failed Dependency normally appears inside the XML body of a 207 Multi-Status response, not as the top-level status. Send a PROPPATCH like the one above with curl and read the <d:status> lines in the body.

curl -i -X PROPPATCH https://dav.example.com/files/report.pdf \
  -H 'Content-Type: application/xml' \
  --data-binary @props.xml

Expect HTTP/1.1 207 Multi-Status, with the property that failed carrying its real status and the others marked HTTP/1.1 424 Failed Dependency.

Related

• 207 Multi-Status
• 423 Locked
• 409 Conflict
• 507 Insufficient Storage