Prompt and scope
A WebDAV service lets multiple bindings point to the same resource. A client sends PROPFIND with Depth infinity, and the server encounters that resource repeatedly in one 207 Multi-Status response. Explain 208 Already Reported, when to emit it, how to handle old clients, and how it differs from 508 Loop Detected.
This is the RFC 5842 WebDAV binding extension. 208 is not a generic REST success code for “already exists.”
What the interviewer is testing
- Identify 208 as a status line inside a 207 Multi-Status response, not the standalone HTTP response status.
- Connect binding aliases, resource identity, and repeated enumeration.
- Distinguish an already reported resource from a real binding loop and use 508 correctly.
- Design Depth limits, client capability handling, XML parsing, and observability.
Clarifying questions
- Does the service implement RFC 5842 binding methods and
DAV:resource-id? - Do clients understand 208, or only basic WebDAV 207 responses?
- Is PROPFIND Depth 0, 1, or infinity, and what server limit applies?
- Is repetition caused by bindings, symbolic links, or a real parent-child cycle?
- Must the product list every alias, or only report each resource once?
A 30-second answer
“208 marks a resource that was already reported in the same 207 Multi-Status response, commonly when WebDAV bindings cause repeated enumeration. I deduplicate by a stable resource identity, return a full propstat for the first occurrence, and use 208 for later bindings; a binding loop that cannot be safely terminated is 508. For clients that do not understand 208, I limit Depth or return a parseable 207 within the WebDAV contract, and record deduplication, depth, loop, and truncation reasons. I would never use 208 for an ordinary REST ‘already exists’ result.”
Step-by-step design
1. Confirm the response layer
The outer HTTP response is normally 207 Multi-Status. Each response contains a resource URI and one or more propstat elements. 208 is the status line inside the relevant DAV property response, indicating that the binding’s resource was already reported in this Multi-Status response. Do not replace the outer 207 with 208.
2. Deduplicate by resource identity
A URI is not necessarily a resource identity. Different bindings can expose different URIs for one resource. Use DAV:resource-id or a stable internal ID for a per-traversal visited set. Emit complete properties for the first encounter, then 208 for later bindings while retaining each URI’s relationship.
PROPFIND Depth: infinity
/alias-a -> resource R: full propstat
/alias-b -> resource R: 208 Already Reported
/child -> resource C: full propstat3. Keep 208 in its intended context
208 saves repeated 207 property payloads and prevents binding enumeration from expanding indefinitely. It does not mean a database insert conflict, an idempotent retry succeeded, or a cache hit. An ordinary JSON API should choose explicit 200, 201, 204, or 409 semantics instead.
4. Distinguish 508 Loop Detected
If traversal finds a binding relation that forms a cycle rather than a second reference to an already completed resource, stop recursion and use 508 Loop Detected. 208 means the resource was successfully reported earlier; 508 means processing was stopped to avoid an infinite loop. Test aliases, real cycles, and depth limits separately.
5. Handle compatibility and resource limits
Negotiate or observe client support for 208. For an old client, cap Depth infinity, reject unsafe requests, or return understandable propstat content without violating WebDAV semantics. Bound node count, response bytes, time, and visited-set memory so a hostile binding graph cannot exhaust the service.
6. Observe and recover
Record request ID, Depth, visited-resource count, 208 count, 508 count, truncation reason, response size, and client capability; never log file contents or credentials. If the deduplication index fails, truncate safely with an explicit error rather than emitting unbounded recursion. Keep a reproducible binding graph for identity and loop debugging.
Model high-quality answer
“The outer response remains 207 Multi-Status; 208 appears in a propstat status to say that the same resource was already reported. For a Depth infinity PROPFIND I build a visited set from resource identity: the first binding returns full properties, and later aliases return 208 while retaining their URIs. A real cycle stops with 508. I would not use 208 for a generic API’s already-exists or retry result. Older clients get a depth cap or a safe rejection, and telemetry covers resources, response size, 208, 508, and truncation.”
Common mistakes
- Set the whole HTTP response to 208 → the 207 Multi-Status structure is lost → put 208 in the relevant propstat status.
- Use URI as the resource key → aliases still duplicate the resource → deduplicate by resource ID.
- Use 208 for already-exists → generic REST clients misinterpret it → use 409 or an explicit business response.
- Treat every duplicate as 508 → normal aliases look like loops → separate reported resources from cycles.
- Set no Depth or response limit → a binding graph can exhaust memory → bound nodes, time, bytes, and visited-set size.
Follow-up questions and responses
Does a 208 entry still need a URI?
Yes. Retain the response for that binding so the client knows which URI was traversed, but do not repeat the complete property payload. The XML must follow the WebDAV Multi-Status parsing contract.
Why not delete duplicate entries entirely?
Deletion hides the fact that an alias was traversed and may look like a server omission. 208 preserves traversal evidence while avoiding duplicate property data.
When should the server reject Depth infinity?
Reject or cap it when the client cannot parse 208, the binding graph exceeds resource limits, or a reliable visited set cannot be built. A bounded response is safer than incomplete output or unbounded recursion.