HTTP 207 Multi-Status is a WebDAV response code that reports multiple result states within one HTTP response. It carries a structured body, usually XML, that lists the outcome for each sub-request or resource, so a client can see which parts succeeded, failed, or need more action.
What the 207 status code means in WebDAV
HTTP 207 Multi-Status is not a simple success or failure signal. It tells the client that the server is returning a collection of per-resource or per-operation outcomes in one response, which is common in WebDAV-style batch activity where one request may touch many files or properties.
This makes 207 useful when a single operation spans multiple targets, because the client can distinguish partial success from partial failure without losing the detail of which sub-request produced each result. In practice, the code shifts complexity from the HTTP status line into the structured response body.
Why multi-status responses exist
Multi-status responses solve a coordination problem: a batch request can complete unevenly, and a single yes-or-no code would hide that nuance. The structured body is the real carrier of meaning, often using XML elements to enumerate each resource and its specific status.
That design is especially important for clients that need to resume, retry, or reconcile work after a partial outcome. It also means that implementers must treat the body as authoritative for item-level results, rather than assuming the top-level code tells the whole story.
How clients should read and interpret it
A 207 response should be parsed as a set of individual results, not as a blanket success. Clients need to map each listed path, property, or sub-request to its outcome and decide whether to continue, retry, alert the user, or reconcile state.
When a client assumes a 207 means “everything worked,” it can miss failed items and leave systems out of sync. Good handling means checking both the overall response and the item-level details, then applying application logic to each returned status.
Common implementation and interoperability pitfalls
207 depends on the client and server agreeing on the response format, ordering, and semantics of the embedded results. If a parser is too rigid, it may ignore valid entries; if it is too loose, it may misread failure states or accept incomplete data as complete.
It is also easy to overuse 207 for generic API batching when the underlying protocol or client ecosystem does not understand WebDAV conventions. In those cases, the response may be technically valid but operationally confusing, because downstream tooling expects a single terminal outcome rather than a result set.
Risk and Threat Considerations
Multi-status responses can hide partial failure, inconsistent state, or missed error handling when clients only inspect the top-level HTTP code. In security-sensitive workflows, that can leave some resources updated while others remain unchanged, which creates integrity gaps and can complicate recovery or audit trails.
Failure mechanism: A client or intermediary treats 207 as a generic success, skips per-item inspection, or fails to surface embedded errors, allowing partial completion to look like full completion.
Impact: Attackers and operational failures can both exploit the ambiguity, because unnoticed partial outcomes may preserve unauthorized access, leave stale data in place, or delay detection of a compromised or failed sub-operation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V16 — Security Logging and Error Handling | 207 requires clients to surface per-item outcomes clearly. |
| Recommendation — Log and surface each sub-request outcome so partial failures are not hidden. | ||
| NIST SP 800-53 Rev 5 | AU-3 — Content of Audit Records | Multi-status bodies can carry item-level results that need traceable records. |
| Recommendation — Record each relevant sub-operation outcome with enough context to reconstruct the batch result. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Incorrect handling of multi-status responses can expose parsing and interpretation flaws. |
| Recommendation — Validate response handling so batch APIs do not mis-handle embedded per-resource statuses. | ||
Practitioner Guidance
What to watch for: Use 207 only when the client can reliably parse the structured body and enforce per-resource handling rules. If you are building or reviewing an integration, verify that monitoring, retries, and user feedback are driven by the item-level statuses, not just the outer response code.
Governance implication: For batch or WebDAV-style workflows, define ownership for partial-success handling so that teams know who remediates failed sub-requests, who records completion, and how state reconciliation is verified after the response is received.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org