HTTP 208 Already Reported

HTTP 208 Already Reported is a WebDAV extension (RFC 5842) used inside a 207 Multi-Status response to indicate that members of a DAV binding have already been enumerated in a preceding part of the multistatus response and are not being included again. This prevents infinite loops and redundant data when a WebDAV collection contains multiple bindings (hard links) to the same resource, ensuring each resource appears exactly once in the response.

Debug HTTP 208 live
Analyze real 208 behavior — headers, caching, CORS, redirects
Open Inspector →

Try it (live endpoint)

Response includes the status code, standard headers (including Content-Type), and a small diagnostic JSON body describing the request and returned status.

Simulator URL (copy in the app after load — not a normal link):

https://httpstatus.com/api/status/208

Example request:

curl -i "https://httpstatus.com/api/status/208"
Try in playground

Meaning

The members of a DAV binding have already been enumerated in a previous reply to this request.

What it guarantees
  • The server accepted the request and produced a final response.
What it does NOT guarantee
  • The underlying business operation is correct across all downstream systems.
  • The response is cacheable unless headers explicitly allow it.

When to use this status

  • GET succeeds and returns a representation of the resource.
  • PUT/PATCH succeeds and returns an updated representation.
  • POST succeeds and returns an immediate result.

When NOT to use this status (common misuses)

Returning 200 for partial failures or errors embedded only in the body.
Clients and monitors treat it as success; failures become silent and harder to alert on.
Returning 200 for creation instead of 201 with Location.
Clients lose a reliable created-resource identifier; SDK behavior becomes inconsistent.
Returning 200 for async acceptance instead of 202.
Clients assume the work is complete and proceed incorrectly.

Critical headers that matter

Content-Type
Defines how clients parse the body.
Clients mis-parse payloads; SDKs and browsers apply wrong decoding.
Cache-Control
Controls cacheability and revalidation.
CDNs/browsers cache dynamic data or fail to cache static content.
ETag / Last-Modified
Enables conditional requests and revalidation.
Unnecessary bandwidth; poor cache consistency.

Tool interpretation

Browsers
Treats as success; caches/revalidates based on headers and validators.
API clients
Deserializes per Content-Type; conditional requests use validators when implemented.
Crawlers / SEO tools
Indexes depending on headers and canonical stability; caches behavior via validators and cache directives.
Uptime monitors
Typically marks success; advanced checks may flag header anomalies or latency.
CDNs / reverse proxies
Caches/revalidates based on Cache-Control, ETag, and Vary; compression and content-type affect behavior.

Inspector preview (read-only)

On this code, Inspector focuses on semantics, headers, and correctness warnings that commonly affect clients and caches.

Signals it will highlight
  • Status semantics vs method and body expectations
  • Header sanity (Content-Type, Cache-Control, Vary) and evidence completeness
Correctness warnings
No common correctness warnings are specific to this code.

Guided Lab outcome

  • Reproduce HTTP 208 Already Reported using a controlled endpoint and capture the full exchange.
  • Practice distinguishing status semantics from transport issues (redirects, caching, proxies).

Technical deep dive

208 Already Reported (RFC 5842 Section 7.1) solves a specific problem: WebDAV bindings allow a single resource to appear in multiple collections (similar to hard links in a filesystem). When a PROPFIND with Depth: infinity traverses a collection tree, the same resource could appear multiple times. The 208 status in a <response> element signals 'this resource was already listed earlier in this multistatus response.' The client knows to reference the earlier entry. This is exclusively used within 207 multistatus bodies — you'll never see a standalone 208 response.

Real-world examples

WebDAV collection with bindings
A PROPFIND on /shared/ discovers that /shared/docs/report.pdf and /shared/archive/report.pdf are bindings to the same resource. The first occurrence returns 200 with full properties. The second returns 208 Already Reported, signaling the client to use the first entry's data.
CalDAV recurring events
A CalDAV client queries a calendar collection. Recurring events with multiple instances could generate duplicate entries. The server uses 208 to indicate instances that reference an already-reported master event.
CardDAV shared contacts
A contact shared across multiple groups in a CardDAV server. When listing all groups with Depth: infinity, the shared contact appears once with 200 and subsequent appearances use 208.

Framework behavior

Express.js (Node)
No built-in support. Only relevant if implementing a WebDAV server with binding support. Would be part of a custom XML multistatus response builder.
Django / DRF (Python)
No built-in support. Relevant only for WebDAV implementations using django-webdav or similar. The 208 status would appear inside XML multistatus responses.
Spring Boot (Java)
No built-in support. Milton (Java WebDAV library) may handle this for binding-aware WebDAV servers. For custom implementations, include 208 in multistatus XML generation.
FastAPI (Python)
No built-in support. Extremely unlikely to need this unless building a WebDAV server with Python. Would be part of custom XML response construction.

Debugging guide

  1. 208 only appears inside 207 Multi-Status XML bodies — never as a standalone response
  2. If you see 208 in a WebDAV response, it means a resource was already listed earlier — check preceding <response> elements
  3. Client-side: when processing 207, track reported resource URIs; on 208, look up the earlier entry
  4. If duplicate resources appear despite 208, the client may not be deduplicating — check the client's multistatus parser
  5. Most modern applications never encounter 208 — it's specific to WebDAV servers with binding support

Code snippets

Node.js
// WebDAV multistatus with 208 Already Reported
const xml = `<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:">
  <D:response>
    <D:href>/shared/docs/report.pdf</D:href>
    <D:propstat>
      <D:prop><D:getcontentlength>1048576</D:getcontentlength></D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <D:response>
    <D:href>/shared/archive/report.pdf</D:href>
    <D:status>HTTP/1.1 208 Already Reported</D:status>
  </D:response>
</D:multistatus>`;
res.status(207).type('application/xml').send(xml);
Python
# WebDAV multistatus response with 208
from lxml import etree

def build_multistatus(resources):
    DAV = 'DAV:'
    ms = etree.Element(f'{{{DAV}}}multistatus')
    reported = set()
    for resource in resources:
        resp = etree.SubElement(ms, f'{{{DAV}}}response')
        href = etree.SubElement(resp, f'{{{DAV}}}href')
        href.text = resource.path
        if resource.canonical_id in reported:
            status = etree.SubElement(resp, f'{{{DAV}}}status')
            status.text = 'HTTP/1.1 208 Already Reported'
        else:
            reported.add(resource.canonical_id)
            # ... add full propstat ...
    return etree.tostring(ms, xml_declaration=True)
Java (Spring)
// Milton WebDAV library handles 208 for bound resources
// Custom implementation:
public String buildMultistatus(List<DavResource> resources) {
    Set<String> reported = new HashSet<>();
    StringBuilder xml = new StringBuilder();
    xml.append("<D:multistatus xmlns:D='DAV:'>");
    for (DavResource r : resources) {
        xml.append("<D:response><D:href>").append(r.getPath()).append("</D:href>");
        if (reported.contains(r.getCanonicalId())) {
            xml.append("<D:status>HTTP/1.1 208 Already Reported</D:status>");
        } else {
            reported.add(r.getCanonicalId());
            xml.append(buildPropstat(r));
        }
        xml.append("</D:response>");
    }
    xml.append("</D:multistatus>");
    return xml.toString();
}
Go
// 208 is only used inside WebDAV 207 multistatus XML
type MultistatusResponse struct {
	Href   string `xml:"href"`
	Status string `xml:"status,omitempty"`
}

func buildMultistatus(resources []Resource) []byte {
	reported := map[string]bool{}
	var responses []MultistatusResponse
	for _, r := range resources {
		if reported[r.CanonicalID] {
			responses = append(responses, MultistatusResponse{
				Href:   r.Path,
				Status: "HTTP/1.1 208 Already Reported",
			})
		} else {
			reported[r.CanonicalID] = true
			// add full response with properties
		}
	}
	// marshal to XML
}

FAQ

When would I actually encounter HTTP 208?
Almost never in modern web development. 208 is specific to WebDAV servers that support bindings (RFC 5842). You'd encounter it when using a WebDAV client (like macOS Finder or Windows Explorer) to browse a collection with resources that appear in multiple locations via bindings. REST APIs and web applications don't use this status code.
Is 208 the same as a redirect?
No. A redirect (301/302/307) tells the client to make a new request to a different URL. 208 tells the client 'I already told you about this resource earlier in this same response' — it's a deduplication signal within a single 207 multistatus response, not a navigation instruction.
Can I use 208 in a REST API for deduplication?
You could, but it's non-standard outside WebDAV. For batch API responses, better approaches are: include a 'duplicate_of' field pointing to the canonical result, or simply omit duplicates from the response. Using 208 in a JSON API would confuse clients familiar with its WebDAV semantics.
What is a WebDAV binding?
A WebDAV binding is similar to a hard link in a filesystem — it creates an additional path to the same resource. Unlike a copy, changes to the resource are visible from all bound paths. RFC 5842 defines the BIND method to create bindings. This is what makes 208 necessary: without it, PROPFIND Depth: infinity would list the same resource multiple times.

Client expectation contract

Client can assume
  • A final HTTP response was produced and processed by the server.
Client must NOT assume
  • The change is durable across all downstream systems.
Retry behavior
Retries are generally unnecessary; treat as final unless domain rules require revalidation.
Monitoring classification
Success
Use payload and header checks to avoid false positives; cacheability depends on Cache-Control/ETag/Vary.

Related status codes

207 Multi-Status
Provides status for multiple independent operations (WebDAV). The response body contains XML with status information for each operation.
226 IM Used
The server has fulfilled a GET request using delta encoding. The response represents the result of one or more instance-manipulations applied to the current instance.

Explore more

Related tools
Related utilities