208 vs 207: Already Reported vs Multi-Status
Both are WebDAV codes used in multi-resource responses, but 208 solves the specific problem of infinite loops in bound collection hierarchies.
| Aspect | HTTP 207 — Multi-Status | HTTP 208 — Already Reported |
|---|---|---|
| RFC | RFC 4918, Section 11.1 | RFC 5842, Section 7.1 |
| Use case | Batch operations with mixed outcomes across multiple resources | Deduplication inside a 207 body when a resource has already been listed |
| Used as outer response? | Yes — the HTTP status of the response envelope | No — only appears as an inner status inside a 207 XML body |
| Response body | WebDAV XML multistatus document | No body — appears only as <status>HTTP/1.1 208 Already Reported</status> |
| Cacheable | No | N/A (inner code) |
| Common outside WebDAV? | Yes — used in bulk REST APIs | Extremely rare — WebDAV only |
207: The Outer Envelope
207 Multi-Status is always the HTTP status code of the outer response. It says: “this response contains multiple per-resource status codes inside its body.” The body is an XML document with one <response> element per resource, each containing its own <status>.
207 is used whenever a WebDAV operation touches multiple resources: PROPFIND with Depth: 1, PROPPATCH, COPY or MOVE on a collection, or LOCK on a collection. It is also borrowed by REST bulk APIs that process arrays of items and need to report per-item outcomes.
208: Inside a 207 Body Only
208 Already Reported only appears as an inner status code within a 207 XML body. It is never the outer HTTP status of a response. Its purpose is to prevent infinite loops in WebDAV bound collections.
RFC 5842 introduced WebDAV Bind, which allows a single resource to be listed under multiple paths simultaneously — similar to hard links in a file system. When a client requests PROPFIND with Depth: infinity on a collection that contains circular bindings (resource A contains resource B, which also references resource A), listing all members would result in infinite recursion.
208 breaks this loop: the first time the server encounters a resource, it lists it with a full 200 or other status. The second time the same resource is encountered in a different traversal path, the server lists it with 208 to signal “this resource was already reported earlier in this response.”
<multistatus xmlns="DAV:">
<response>
<href>/files/doc.pdf</href>
<propstat>
<prop><displayname>doc.pdf</displayname></prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<response>
<href>/archive/doc.pdf</href>
<!-- Same resource, different binding path -- already listed above -->
<status>HTTP/1.1 208 Already Reported</status>
</response>
</multistatus>Decision Rule
If you are building a bulk REST API that returns mixed per-item outcomes, use 207 as the outer status code and define your own JSON body format. Never use 208 — it is a WebDAV-specific inner code for bound collection traversal. Outside of WebDAV Bind scenarios with circular references, 208 has no applicable use.
FAQ
Can 207 contain 208 inner statuses?
Yes. 208 is specifically designed to appear inside 207 WebDAV XML bodies. It is only meaningful in that context. A 207 response for a PROPFIND on a collection with bound (circular) resources may contain 208 entries.
Is 208 used outside of WebDAV?
Essentially never. The code exists specifically to handle circular binding traversal in WebDAV. Non-WebDAV applications have no reason to use it.
What do I use for duplicate detection in a bulk REST API?
Include a per-item status in your JSON response body, such as 409 Conflict or a custom error code. Use 207 as the outer status for mixed results. 208 is not appropriate for non-WebDAV duplicate detection.