HTTP
208 - Already Reported
HTTP 208 Already Reported is a success status code used exclusively within a 207 Multi-Status response. It indicates that a resource has already been listed in a previous part of the same response, preventing redundant data and infinite loops in hierarchical collections.
Last reviewed: March 13, 2026|Editorial standard: source-backed technical guidance
What Does Already Reported Mean?
A 208 status is a "Deduplication Checkpoint." It is never sent as a standalone response; it only lives inside a 207 Multi-Status body. In systems where a resource can be reached via multiple paths (like hard links or shortcuts in WebDAV), the server reports it fully the first time (200 OK) and uses 208 thereafter. This is the primary defense against infinite loops in recursive directory traversals.
Common Causes
- -Multiple Bindings: A file or folder is accessible via more than one URI (e.g., a shared folder appearing in two different collection paths).
- -Recursive Traversals: A client requests an "infinity depth" search on a system with circular symbolic links.
- -Idempotent Batch APIs: A bulk update processed multiple items that resolve to the same internal entity; the server processes the first one and marks duplicates as 208.
- -WebDAV Sync Engines: Synchronization tasks encountering the same resource multiple times due to a graph-based file structure.
How to Fix Already Reported
- 1Deduplicate by URI: In your client-side logic, use the
hreffield to index resources rather than counting the total number of sub-responses. - 2Update Client Parsers: Ensure your XML/JSON parser treats 208 as a "Skip & Sync" signal rather than an unexpected error code.
- 3Audit 207 Wrapper: Verify that 208 is correctly nested within a 207 Multi-Status; if it appears alone, the server-side implementation is non-compliant.
- 4Cycle Detection: If 208 appears too frequently, check your backend for unintended circular references in the database or file system.
Step-by-Step Diagnosis for Already Reported
- 1Confirm the 208 status is contained within a 207 Multi-Status response body.
- 2Identify the first occurrence: Locate the
hrefassociated with the 208 and find its earlier 200/201 entry in the same payload. - 3Check for "Unexpected Status Code" logs in the client; many SDKs fail because they aren't configured for 208 inside batches.
- 4Use
curl -X PROPFINDto manually inspect the XML structure and verify the binding logic.
Status Decision Matrix (200 vs. 208)
- -First Encounter (200 OK): Server provides full metadata/properties for the resource.
- -Subsequent Encounter (208 Already Reported): Server provides only the identifier (href) and the 208 code to save bandwidth and prevent loops.
Recursive Safety Audit
- -208 acts as a "Circuit Breaker" for
Depth: infinityrequests. Without it, a circular link could cause a server to generate an infinite XML stream, crashing the client.
Implementation Examples
WebDAV Multi-Status with 208xml
<d:multistatus xmlns:d="DAV:">
<d:response>
<d:href>/files/report.pdf</d:href>
<d:status>HTTP/1.1 200 OK</d:status>
</d:response>
<d:response>
<d:href>/shared/report-link.pdf</d:href>
<d:status>HTTP/1.1 208 Already Reported</d:status>
</d:response>
</d:multistatus>Handling 208 in a Batch Result Loopjavascript
const processResults = (items) => {
const store = new Map();
items.forEach(item => {
if (item.status === 200 || item.status === 201) {
store.set(item.href, item.data);
} else if (item.status === 208) {
// 208 detected: Log and skip to avoid duplicate state updates
console.debug(`Resource ${item.href} already indexed.`);
}
});
return Array.from(store.values());
};How to Verify the Fix
- -Ensure the client-side data store correctly links multiple URIs to a single resource without duplication.
- -Verify that the total response size is reduced when 208 is used instead of repeating full 200 OK payloads.
- -Confirm that recursive sync operations complete without timing out or entering infinite loops.
How to Prevent Recurrence
- -Canonical Mapping: Use a single canonical URI for the first report of any resource to make deduplication predictable.
- -Client SDK Hardening: Use WebDAV-compliant libraries (like
sardineordav-client) that explicitly handle 208. - -Monitoring: Alert on high rates of 208 sub-responses in non-WebDAV APIs, as this may indicate inefficient client batching.
- -Pro-tip: For modern Bulk APIs, use 208 to signal that an item was already processed in the current session, reducing audit log clutter.
Decision Support
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.