HTTP 208 Already Reported
Quick reference
| Code | 208 |
|---|---|
| Name | Already Reported |
| Category | 2xx Success |
| Spec | RFC 5842 §7.1 |
| Used inside | 207 Multi-Status response body only |
What 208 means
HTTP 208 Already Reported is used exclusively as a status code inside the XML body of a 207 Multi-Status response — it is never returned as a top-level HTTP status. Its purpose is to signal that the properties of a particular DAV resource have already appeared elsewhere in the same 207 response body and will not be repeated.
208 was defined by RFC 5842, which extends WebDAV with binding support. A WebDAV "binding" creates multiple paths to the same underlying resource, similar to a filesystem hard link. When a server performs a PROPFIND with Depth: infinity over a collection containing bindings, the same resource can be reachable via multiple paths. Without 208, the server would either include duplicate entries (bloating the response) or risk infinite recursion following circular bindings.
208 solves the duplicate-entry problem. The first time a resource is encountered during traversal, the server includes its full properties in a <D:propstat> element. The second and subsequent times the same resource is encountered (at different bound paths), the server emits a 208 status for those paths to indicate "you already have the properties for this resource."
DAV bindings creating duplicate paths
To understand why 208 exists, consider this WebDAV collection structure:
/collections/library/
├── books/
│ └── moby-dick.epub (resource at /books/moby-dick)
└── classics/
└── moby-dick.epub (a binding — same resource, different path)
Both /collections/library/books/moby-dick.epub and /collections/library/classics/moby-dick.epub point to the same underlying resource. A PROPFIND Depth: infinity on /collections/library/ traverses both paths. Without 208, the server would either include full property sets for both paths (duplicating all the metadata) or include only one path (silently hiding the second binding).
With 208, the server includes full properties for the first path encountered, then emits a 208 for subsequent bound paths to acknowledge their existence while deferring to the already-reported entry for property details.
208 inside a 207 response body
Here is what a complete PROPFIND response looks like with a 208 entry:
PROPFIND /collections/library/ HTTP/1.1
Depth: infinity
Host: dav.example.com
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset=utf-8
<?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:">
<!-- First path: full properties reported -->
<D:response>
<D:href>/collections/library/books/moby-dick.epub</D:href>
<D:propstat>
<D:prop>
<D:getcontentlength>1048576</D:getcontentlength>
<D:getlastmodified>Fri, 25 Apr 2026 10:00:00 GMT</D:getlastmodified>
<D:getetag>"abc123"</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<!-- Second path (binding): properties already reported above -->
<D:response>
<D:href>/collections/library/classics/moby-dick.epub</D:href>
<D:status>HTTP/1.1 208 Already Reported</D:status>
</D:response>
</D:multistatus>
The client parsing this response knows that /classics/moby-dick.epub is a binding to the same resource as /books/moby-dick.epub and can use the properties from the first entry for both paths.
208 vs 508: two sides of the same binding problem
| Code | Meaning | When returned |
|---|---|---|
| 208 Already Reported | Resource properties already included in this response | Non-circular bindings: traversal continues safely, duplicates suppressed |
| 508 Loop Detected | Circular binding found — traversal aborted | Circular bindings: traversal would recurse infinitely without 208 helping |
208 handles the benign case (the same resource reachable at multiple paths without forming a cycle). 508 handles the pathological case (the binding graph contains a cycle that makes infinite traversal possible).
Practical relevance outside WebDAV
Outside of WebDAV, 208 is occasionally used in bulk API responses to signal that a sub-resource in a batch operation was already processed and will not be processed again. This is a non-standard use — 208 is not defined for non-WebDAV contexts in any RFC — but the semantic is consistent: "already handled this one."
If you are designing a bulk API and need to signal that a requested item was already processed in a previous call or earlier in the same batch, 208 conveys this intent clearly. However, consider whether a custom error field in the response body is more appropriate for non-WebDAV clients that may not know how to interpret 208.
Frequently asked questions
Can 208 ever appear as a top-level HTTP response?
RFC 5842 states that 208 is defined for use in DAV multi-status response bodies. A standalone 208 as a top-level response is not defined and would be non-standard. If received as a top-level status, treat it as 200 OK (RFC 9110 fallback rule for unknown 2xx codes) and log the anomaly.
Do standard HTTP clients understand 208?
General HTTP clients (curl, browsers, fetch API) do not have special handling for 208. It is WebDAV clients (Cyberduck, macOS Finder DAV, SabreDAV client libraries) that parse the 207 multi-status XML body and handle 208 entries correctly.
Is 208 used in COPY or MOVE operations?
208 is primarily associated with PROPFIND (property retrieval). COPY and MOVE operations may encounter the same binding duplication issue, but RFC 5842 focuses on PROPFIND for the 208 use case. COPY/MOVE with circular bindings are more likely to trigger 508.
Why does 208 use a 2xx code instead of a 4xx or 5xx?
208 is not an error. The operation completed successfully — the resource exists and its properties are available in the response. The 208 status inside the multi-status body indicates a successful but abbreviated representation: success with the note that details are elsewhere in the same response.