Failed Dependency

Server perspective

Use 424 in WebDAV-style multi-step operations when this action failed only because a dependent action failed first.

When to use

• •Return 424 when one command in a compound request depends on another command that already failed
• •Use it to explain cascading failure in dependency-aware operations
• •WebDAV transaction failures with dependencies
• •Multi-step operations where earlier steps failed
• •Atomic operations that must succeed or fail together
• •File system operations with prerequisite failures
• •Batch operations with interdependent steps

How to respond

• •Identify the failed prerequisite action clearly in the response body
• •Keep the dependency chain understandable so clients know which step actually broke first

Headers to consider

• •No status-specific header is required; still send normal HTTP metadata such as Content-Type, caching, or tracing headers when they help the client.

Response body

• •WebDAV responses typically describe the original failed dependency in XML details

Server-side pitfalls

• •Do not use 424 as a vague batch-failure shortcut without identifying the broken dependency
• •Do not use it for standalone requests with no real prerequisite action
• •Single operation failures (use appropriate 4xx/5xx codes)
• •Independent operation failures (use 207 Multi-Status)
• •Non-WebDAV APIs (use appropriate error codes)
• •Simple validation errors (use 422 Unprocessable Content)

Examples