Already Reported

Active

RFC 5842 §7.1•Since 2010•WebDAV servers with binding extensions

HTTP 208 Already Reported appears inside a 207 Multi-Status response body to indicate that members of a DAV binding have already been enumerated in a preceding part of the response. Defined in RFC 5842 §7.1 (WebDAV Binding Extensions). Prevents duplicate entries when the same collection is reachable via multiple bindings.

Description

The 208 Already Reported status code is used inside a DAV:propstat response element to avoid repeatedly enumerating the internal members of multiple bindings to the same collection. It signals that the members of a resource have already been listed in a previous part of the 207 Multi-Status response, and the server is not going to repeat them.

This status code exists exclusively within the context of WebDAV Binding Extensions (RFC 5842). WebDAV bindings allow the same resource to be accessible through multiple URI paths — essentially hard links in HTTP space. When a client requests a recursive property listing (Depth: infinity) on a collection that contains multiple bindings to the same sub-collection, without 208 the server would enumerate identical members multiple times, bloating the response.

The mechanics: when the server encounters a collection it has already enumerated earlier in the same multistatus response, it returns 208 for that binding instead of re-listing all the children. The response body for the 208 entry typically contains a DAV:multistatus element that references back to the earlier listing. The client knows to look at the first occurrence for the actual member properties.

208 never appears as a top-level HTTP response code. You will never see `HTTP/1.1 208 Already Reported` as the status line of an HTTP response. It only exists inside the XML body of a 207 Multi-Status response, nested within DAV:propstat elements. Receiving 208 outside of a multistatus body would be a protocol violation.

This is one of the most niche status codes in the HTTP specification landscape. Unless you are implementing a WebDAV server with binding extension support (RFC 5842), you will never encounter or need to produce this code. Think of it as deduplication metadata within a recursive property enumeration — the server's way of saying 'I already told you about these resources earlier in this response, look there instead.'

Examples

PROPFIND request on a collection with bindings

http

PROPFIND /shared/ HTTP/1.1
Host: dav.example.com
Depth: infinity
Content-Type: application/xml

<?xml version="1.0" encoding="utf-8"?>
<D:propfind xmlns:D="DAV:">
  <D:prop>
    <D:displayname/>
    <D:resourcetype/>
    <D:getcontentlength/>
  </D:prop>
</D:propfind>

207 Multi-Status response with 208 for already-reported binding

http

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:">
  <D:response>
    <D:href>/shared/projects/</D:href>
    <D:propstat>
      <D:prop>
        <D:displayname>Projects</D:displayname>
        <D:resourcetype><D:collection/></D:resourcetype>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <!-- ... full member enumeration of /shared/projects/ ... -->
  <D:response>
    <D:href>/shared/team-a/projects/</D:href>
    <D:propstat>
      <D:prop>
        <D:displayname>Projects</D:displayname>
        <D:resourcetype><D:collection/></D:resourcetype>
      </D:prop>
      <D:status>HTTP/1.1 208 Already Reported</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>

BIND request creating a second path to the same collection

http

BIND /shared/team-a/ HTTP/1.1
Host: dav.example.com
Content-Type: application/xml

<?xml version="1.0" encoding="utf-8"?>
<D:bind xmlns:D="DAV:">
  <D:segment>projects</D:segment>
  <D:href>/shared/projects/</D:href>
</D:bind>

208 inside a propstat element — detailed structure

http

<!-- This response element appears INSIDE a 207 body -->
<D:response>
  <D:href>/collections/archive/2024/docs/</D:href>
  <D:propstat>
    <D:prop>
      <D:displayname>Docs</D:displayname>
      <D:resourcetype><D:collection/></D:resourcetype>
    </D:prop>
    <D:status>HTTP/1.1 208 Already Reported</D:status>
  </D:propstat>
  <!-- Client should reference /collections/main/docs/ enumerated above -->
</D:response>

Edge Cases

•208 NEVER appears as a top-level HTTP status line. It only exists inside the XML body of a 207 Multi-Status response. Returning `HTTP/1.1 208 Already Reported` as the response status is a protocol violation.
•A client receiving 208 must look back through the earlier parts of the same multistatus response to find the full enumeration of that collection's members.
•Circular bindings (A contains binding to B, B contains binding to A) are where 208 becomes essential — without it, a Depth:infinity PROPFIND would recurse infinitely. The server uses 208 to break the cycle.
•208 does not mean the resource hasn't changed — it means its members were already listed. The properties in the 208 propstat element may still be current; only the recursive enumeration is skipped.
•If a server doesn't support RFC 5842 bindings, it will never produce 208. Most WebDAV servers (even popular ones like Nextcloud or Apache mod_dav) do not implement binding extensions.
•Clients that don't understand 208 should treat it as a generic 2xx success, per HTTP's class-based fallback rule. They may end up with incomplete member listings but won't error.

When You'll See This

→Recursive PROPFIND (Depth:infinity) encounters the same collection via two different bindings
→WebDAV server with binding extensions breaks a circular reference in a collection hierarchy
→Document management system where the same folder is linked into multiple project trees
→Enterprise content management with shared resource pools accessible from multiple department hierarchies
→CalDAV/CardDAV server implementation that uses bindings to share calendars across user collections

Implementation References

Language	Constant
Go	208 (no named constant in net/http)
Rust	http::StatusCode::ALREADY_REPORTED
Python	http.HTTPStatus.ALREADY_REPORTED
Node.js	http.STATUS_CODES[208]
.NET	HttpStatusCode.AlreadyReported
Java	208 (no standard constant; Spring: HttpStatus.ALREADY_REPORTED)
PHP	Response::HTTP_ALREADY_REPORTED (Symfony)
Ruby	:already_reported (Rack)

History

Introduced in RFC 5842 (April 2010), 'Binding Extensions to Web Distributed Authoring and Versioning (WebDAV).' The RFC was authored by Geoffrey Clemm, Julian Reschke, and Jim Whitehead. It extended the WebDAV protocol (RFC 4918) with the concept of bindings — multiple URIs mapping to the same resource, analogous to hard links in POSIX filesystems. The 208 status code was created specifically to solve the deduplication problem in recursive PROPFIND responses when bindings create multiple paths to the same collection. Without it, Depth:infinity requests on collections with bindings would either produce duplicate entries or require complex client-side deduplication. The RFC has Standards Track status but was never widely implemented — only specialized WebDAV servers with full binding support (primarily research and enterprise document management systems) produce this code.

Related Status Codes

207 Multi-Status 226 IM Used 200 OK 404 Not Found

Related Headers

Depth Content-Type

FAQ

When would I actually encounter HTTP 208 Already Reported?

Almost never in practice. You'll only see 208 if you're interacting with a WebDAV server that implements RFC 5842 Binding Extensions and you issue a PROPFIND request with Depth:infinity on a collection that has multiple bindings (essentially hard links) to the same sub-collection. The 208 appears inside the 207 Multi-Status XML body — never as a standalone HTTP response. Unless you're building or consuming a specialized WebDAV server with binding support, you can safely ignore this status code.

What is the difference between 207 Multi-Status and 208 Already Reported?

207 is the top-level HTTP response code indicating the body contains an XML document with multiple individual status codes for multiple resources (the multistatus response). 208 appears INSIDE that 207 response body, nested within a DAV:propstat element, to indicate that a particular collection's members were already enumerated earlier in the same multistatus document. Think of 207 as the container and 208 as a deduplication marker within that container.

Can I use 208 Already Reported in my REST API for deduplication?

Technically, no. 208 is formally defined only for use within WebDAV multistatus responses and RFC 5842 binding semantics. Using it in a REST API to mean 'already reported' or 'already processed' would be a misuse of the specification. For idempotent retry scenarios, use 200 (already processed, here's the result) or 304 (not modified). For duplicate submission detection, 409 Conflict or 422 Unprocessable Content with an appropriate error body are better choices.

Source: RFC 5842 §7.1