208 exists to handle WebDAV bindings, which allow a single resource to be accessible via multiple URLs (similar to hard links in a filesystem). Without 208, a PROPFIND with Depth: infinity on a collection containing DAV bindings could report the same underlying resource multiple times — once for each binding path. 208 tells the client that a resource has already been enumerated.

HTTP 208 Already Reported

Q: What does HTTP 208 Already Reported mean?

HTTP 208 Already Reported is a WebDAV status code defined in RFC 5842 that appears inside a 207 Multi-Status response body. It signals that the members of a DAV binding have already been reported in a previous response element within the same request. It prevents duplicate reporting of the same resource when DAV bindings create multiple paths to the same underlying resource.

Q: What RFC defines HTTP 208?

HTTP 208 is defined in RFC 5842 — Binding Extensions to Web Distributed Authoring and Versioning (WebDAV). RFC 5842 extends the base WebDAV specification (RFC 4918) by adding the BIND method and the 208 status code to handle DAV binding scenarios.

HTTP 208 Already Reported is a WebDAV extension status code defined in RFC 5842. It appears inside a 207 Multi-Status response body — never as a standalone outer HTTP status code — to indicate that the members of a particular DAV binding have already been enumerated in an earlier response element within the same PROPFIND response. It exists specifically to handle the complexity introduced by WebDAV bindings, which allow a single resource to be accessible at multiple URLs simultaneously.

Quick reference

Code	208
Name	Already Reported
Category	2xx Success
Specification	RFC 5842 §7.1
IANA status	Assigned
Appears in	207 Multi-Status response body only — never as outer HTTP status
Applies to	WebDAV systems implementing the BIND method (RFC 5842)
Primary use	Preventing duplicate resource reporting in DAV binding traversal

What HTTP 208 means

To understand 208, you need to understand WebDAV bindings. RFC 5842 introduced the BIND method, which creates an additional URL mapping to an existing resource — analogous to a hard link in a filesystem. A single file can become accessible at two different paths within a WebDAV namespace. Unlike a symlink (which is a separate resource pointing to another), a binding makes the same underlying resource available at two addresses with no indirection.

The problem this creates: a PROPFIND request with Depth: infinity on a collection traverses all member resources recursively. If a resource is bound into two locations within that collection, a naive traversal would report that resource twice — once for each binding path. In a namespace with many bindings, this duplication could become very large or, in a circular binding scenario, trigger an infinite loop.

208 solves this. When the server encounters a resource during PROPFIND traversal that it has already reported in an earlier DAV:response element within the same response, it emits a response element for the duplicate path with status 208 instead of reporting all the properties again. The client receives: "I already told you about this resource under a different URL — no need to report it twice."

RFC 5842 §7.1 specifies that 208 is only used inside 207 Multi-Status bodies. It is not a valid outer HTTP response code. If a server sends HTTP/1.1 208 Already Reported as the top-level status of a response, that is a server implementation error.

DAV bindings and how they create duplicate paths

A WebDAV binding is created with the BIND method. The BIND request specifies a source resource and a destination segment within an existing collection. After the binding is created, both paths resolve to the same underlying resource with the same content and properties.

Example: a document at /files/docs/annual-report.pdf is bound into /files/shared/annual-report.pdf. Both URLs serve the same underlying resource. The resource has two distinct hrefs within the WebDAV namespace.

When a client issues PROPFIND /files/ HTTP/1.1 with Depth: infinity, the server traverses the entire /files/ hierarchy. It encounters /files/docs/annual-report.pdf first and reports it fully. When it reaches /files/shared/annual-report.pdf, it recognizes the same underlying resource and emits a 208 response element instead of repeating the full property set.

The 208 response element still includes the DAV:href for the duplicate path — the client knows the binding exists. The 208 status code on that element tells the client to look at the earlier response element for the full property data, rather than expecting it to be included again.

208 in a 207 response body

This is what a 207 response containing a 208 sub-status looks like in practice:

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>/files/docs/annual-report.pdf</D:href>
    <D:propstat>
      <D:prop>
        <D:displayname>annual-report.pdf</D:displayname>
        <D:getcontentlength>512000</D:getcontentlength>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <D:response>
    <D:href>/files/shared/annual-report.pdf</D:href>
    <D:status>HTTP/1.1 208 Already Reported</D:status>
  </D:response>
</D:multistatus>

The second response element has no propstat — just a status of 208. The client understands that /files/shared/annual-report.pdf is bound to the same resource as /files/docs/annual-report.pdf, whose properties were already reported. Property data is not duplicated.

Practical relevance

HTTP 208 is highly specific. It only appears in WebDAV systems that implement RFC 5842 bindings. Standard REST APIs have no use for this code. Web application developers, API designers, and backend engineers working outside of WebDAV or distributed filesystem protocols will not encounter 208 in normal work.

The scenarios where you might encounter 208 in practice are narrow: building or maintaining a WebDAV server implementation, writing a WebDAV client that parses PROPFIND responses (such as a desktop sync client, a calendar client using CalDAV, or a contacts client using CardDAV over a WebDAV binding-capable server), or implementing storage systems that expose a WebDAV interface with hard-link-style semantics.

CalDAV and CardDAV (used for calendar and contact synchronization) are built on WebDAV but rarely use bindings in practice. Most commercial CalDAV/CardDAV servers do not implement RFC 5842, so 208 is uncommon even within the WebDAV ecosystem.

If you are seeing 208 unexpectedly in a non-WebDAV context, it is almost certainly a misconfiguration or a server-side bug. The code has no defined meaning outside of WebDAV 207 body contexts.

208 vs related status codes

Code	Name	Context
200	OK	Resource found, properties returned — standard PROPFIND result for a non-duplicate resource
207	Multi-Status	Outer HTTP code for WebDAV multi-resource responses; contains 208 elements inside its body
208	Already Reported	Sub-status inside a 207 body; resource was already enumerated under a different binding path
226	IM Used	Unrelated — HTTP delta encoding; request fulfilled using instance manipulation
508	Loop Detected	Server detected an infinite loop during WebDAV traversal and terminated the operation

FAQ

What does HTTP 208 Already Reported mean?

208 is a WebDAV sub-status code that appears inside a 207 Multi-Status response body. It tells the client that a resource at the given URL has already been reported under a different URL in an earlier response element within the same PROPFIND response. The resource properties are not repeated — the client should refer to the earlier element.

Why does 208 exist?

WebDAV bindings (RFC 5842) allow a single resource to be accessible at multiple URLs. During a PROPFIND traversal, this would cause the same resource to appear multiple times. 208 prevents that duplication by marking subsequent appearances of an already-reported resource without re-sending property data.

Will I encounter 208 in normal REST API development?

Almost never. HTTP 208 is specific to WebDAV binding semantics. It only appears in WebDAV systems implementing the BIND method. Standard REST APIs, web frameworks, and non-WebDAV services have no use for this code.

What RFC defines HTTP 208?

RFC 5842 — Binding Extensions to Web Distributed Authoring and Versioning (WebDAV). It extends the base WebDAV RFC 4918 by adding the BIND method and the 208 status code for handling duplicate resource reporting in collection traversals.

Related resources

On this site: HTTP 207 Multi-Status · HTTP 508 Loop Detected · HTTP 226 IM Used · All 2xx success codes

Standards: RFC 5842 §7.1 — Binding Extensions to WebDAV · RFC 4918 — HTTP Extensions for WebDAV · IANA HTTP Status Code Registry · MDN Web Docs: 208