Prompt and scope
WebDAV resources can appear at multiple paths through bindings. A recursive collection traversal can therefore revisit the same resource or follow a cycle forever. RFC 5842 defines 208 Already Reported for members already reported in the same multistatus response and 508 Loop Detected when the operation is terminated after encountering a loop.
What the interviewer is testing
- Whether you place 508 in its WebDAV context instead of treating it as a generic gateway error.
- Whether you distinguish 208 for an already reported member from 508 for a terminated operation.
- Whether depth, node count, time, and response bytes become enforceable budgets.
- Whether client behavior is idempotent, observable, and free of infinite retries.
Clarifying questions
- Is the method PROPFIND, and is Depth set to infinity?
- Does the resource support DAV bindings, and does the client understand 208?
- Should the server return the full tree, a bounded result, or only finite depth?
- Is the collection cross-tenant, and which properties may be disclosed?
30-second answer
I would first confirm a WebDAV binding cycle rather than an ordinary HTTP redirect. During traversal I would track a stable resource ID and enforce depth, node, time, and response-byte budgets. If the client understands 208, an already reported member can be represented as such; when traversal returns to the active recursion stack and cannot safely complete, the server terminates with 508 and a stable error body. The client must not blindly retry the same infinite-depth request; it should reduce depth or request that the binding be repaired.
Deep-dive answer
1. Define the 508 boundary
508 means that a server terminated a WebDAV operation because it encountered a loop while processing infinite-depth semantics. It is not a generic code for full disks, upstream timeouts, or every recursive failure. The error body may include a stable code and request ID, but should not expose another tenant's paths or internal topology.
2. Track binding identity
Use DAV resource-id or another stable resource identity while traversing instead of comparing only the current URL. One resource can have several paths, so URL-only deduplication misses aliases; stable identity detects repeated members without treating a valid alias as a cycle.
3. Choose 208 or 508
When the client and response semantics allow it, a member already present in the same multistatus result can be marked 208 while other reachable members continue. If traversal returns to a resource in the active recursion stack and the operation cannot safely continue, stop and return 508. The meanings are respectively “already reported” and “terminated because of a loop.”
4. Enforce resource budgets
Even an acyclic graph needs limits for maximum depth, unique nodes, recursion stack, response bytes, and wall-clock time. On budget exhaustion, use a stable application error or a bounded-result policy and record the reason. Do not let a huge collection consume unbounded CPU, memory, or network bandwidth.
5. Design client recovery
After 508, the client should retain the request ID and resource context and stop automatically retrying the same infinite-depth request. It can use finite depth, segmented reads, or wait for an administrator to repair the binding. A Retry-After value, if supplied, is not proof that the cycle has disappeared.
6. Concurrency and caching
Concurrent traversals of the same graph still need per-request budgets and cancellation. Caches may reduce property reads, but they cannot bypass authorization or reuse one tenant's graph for another. After a cycle is repaired, invalidate affected caches and summaries by version or change token.
7. Verification and observability
Test self-bindings, two-node cycles, aliases, finite and infinite depth, clients that do not understand 208, budget exhaustion, cancellation races, and permission changes. Monitor detected cycles, unique nodes, traversal time, response bytes, 508 rate, 208 rate, and retries, segmented by tenant.
Model answer
508 is the explicit result of terminating a WebDAV binding traversal after finding a cycle. I would maintain the active recursion stack and an already-reported set using stable resource IDs; an already reported member can use 208 when the client supports it, while returning to the active stack produces 508. Each request has depth, node, time, and byte budgets, and the error body contains only a stable code and request ID. The client stops retrying the same infinite-depth request and switches to bounded traversal or binding repair. Load tests cover cycles, aliases, permissions, and cancellation, with cycle, budget, and retry metrics.
Common mistakes
- Treating 508 as any 5xx → The client cannot choose a targeted fix → Use it for the binding-loop context.
- Deduplicating by URL → Aliases are missed or misclassified → Use stable resource identity.
- Treating 208 as a loop error → A reported member is confused with termination → 208 means the member was already reported.
- Retrying 508 forever → The directory problem keeps consuming resources → Reduce depth or repair the binding.
Follow-up questions
Can 208 and 508 appear in the same response?
Yes. Some members may be marked 208 because they were already reported; a later cycle can still cause the overall operation to terminate with 508. The response structure must follow WebDAV multistatus semantics.
Is a recursion-depth limit enough?
No. A wide, shallow collection can still create many nodes and a large response, so also bound unique nodes, bytes, CPU, and wall-clock time.
Should a reverse proxy rewrite 508 to 500?
Usually no. Preserve the status and stable error fields. If an external contract requires mapping, retain the original cause in logs and ensure the client still stops retrying.
How do you prove aliases still work after the fix?
Test an acyclic graph with a shared binding: the same resource ID reached through multiple paths should produce 208 or equivalent deduplication, while authorization remains checked independently for each path.