Prompt and scope
A WebDAV client receives HTTP 508 Loop Detected while accessing a resource. The system has bindings, rewrite rules, and multiple proxies. Explain the protocol meaning, how to prove a loop, client fallback, and how to prevent a retry storm.
What the interviewer evaluates
- Knowing that 508 comes from the WebDAV binding extension, not a generic timeout.
- Distinguishing a server-detected loop from an ordinary upstream 5xx.
- Recording a request chain, binding graph, and detection budget.
- Defining idempotent, non-retryable, and human-repair boundaries.
- Preserving audit evidence without exposing internal topology.
Clarifications to ask first
Confirm the method, DAV binding type, whether the loop is in bindings or proxy rewrites, retry middleware, diagnostic identifiers, and whether the client is read-only. If missing, assume traversal returns to an already visited node.
Thirty-second answer framework
508 means the server detected a loop while processing a WebDAV binding and cannot complete the request. Use the request id to build a directed graph of binding edges, proxy hops, and visited nodes, proving a cycle instead of a single timeout. Do not blindly retry; the same topology should fail fast and direct an operator to repair it. Bound traversal and return a non-sensitive diagnostic id.
Step-by-step deep dive
1. Define the protocol meaning
RFC 5842 defines 508 for a loop detected while completing a WebDAV binding operation. It does not mean the client lost the network, and it does not make every 5xx retryable.
2. Draw the binding and proxy graph
Give each resource or binding node an internal id and record edge source, target, request id, and proxy hop. Maintain a visited set during traversal; seeing a node again proves a cycle. Hitting a depth limit is a separate protective failure and should not be mislabeled 508.
3. Separate upstream failures
A proxy may wrap a backend 508 or create its own rewrite cycle. Preserve trace id, original status, and Via information at every hop instead of examining only the edge response.
4. Design retry and fallback
Retrying the same configuration cannot remove a topology cycle, so fail fast rather than entering exponential retry. Permit budgeted retry only after a configuration repair, version change, or explicit control-plane update. If product semantics allow, fall back to read-only metadata without following the binding.
5. Bound resources and sensitive details
Set maximum nodes, time, and response size. Return an actionable repair hint and correlation id, not internal hostnames or the full binding graph. Keep hashed nodes, edge type, and cycle length in an audit record.
6. Monitor and repair
Track 508 rate, tenant and binding-type distribution, cycle length, traversal time, retry count, and repair duration. Run static cycle checks before writing configuration; freeze the bad version and roll back bindings instead of only scaling proxies.
7. Test and accept
Test self-cycles, two-node cycles, cross-proxy cycles, deep acyclic graphs, concurrent updates, stale caches, and partial node failures. Acceptance requires stable status, no retry storm, traceable diagnostics, no sensitive leakage, and successful requests after repair.
High-quality sample answer
508 is WebDAV’s Loop Detected status: traversal returned to a visited binding node. I would use the request id to construct a graph of resource bindings, rewrites, and proxy hops, using a visited set to distinguish a real cycle from a depth guard. Preserve original status and trace data at each hop so an edge proxy cannot hide the cause.
The same topology will fail again, so clients fail fast instead of retrying exponentially. Freeze the bad binding, validate cycle checks, and restore gradually after repair. Bound nodes and time, return only a correlation id, and monitor 508 rate, cycle length, traversal time, and repair duration. Test self and cross-proxy cycles, deep acyclic graphs, concurrent changes, and stale caches.
Common mistakes
- Treating 508 as a timeout or synonym for every 5xx.
- Calling a depth-limit failure 508 without proving a cycle.
- Retrying the same binding topology indefinitely.
- Logging only the edge status and losing proxy context.
- Returning a complete internal binding graph.
- Scaling proxies instead of checking configuration for cycles before write.
Follow-up questions and responses
Follow-up 1: Is a depth limit automatically 508?
No. It is a protective limit; a cycle is proven only when traversal revisits a node. Internal reasons should remain distinguishable.
Follow-up 2: When may a client retry?
Only after a configuration fix, control-plane version change, or explicit transient signal, and within a budget. The unchanged topology should fail fast.
Follow-up 3: How do you avoid topology leakage?
Return a repair hint and correlation id. Store hashed nodes and edge types in logs and expose the graph only through a controlled internal tool.
Follow-up 4: What if a proxy changes 508 to 502?
Preserve per-hop trace, Via, and original status, then map them end to end instead of inferring the cause from the edge code alone.