通用面试：HTTP 508 Loop Detected 何时成立，如何避免 WebDAV 深度遍历循环？
题干与适用场景
一个 WebDAV 服务允许集合之间建立多个 binding。客户端发送 Depth: infinity 的 PROPFIND 后，服务端发现遍历回到已经访问的集合，于是返回 508。请解释 508 的准确语义，区分它与普通重试环路，说明何时可以用 208 Already Reported，如何避免资源耗尽，以及客户端应如何处理。
这是 HTTP 状态语义、图遍历、协议兼容和安全边界的综合题。RFC 5842 将 508 定义为处理无限深度操作时遇到循环并终止整个操作；IANA 将 508 登记为 RFC 5842 状态码。
面试官在考察什么
- 是否知道 508 的上下文是 WebDAV 绑定和
Depth: infinity，不会把它泛化成任意重定向错误。 - 能否把资源、URI binding、访问路径和已访问集合建模为图。
- 能否区分发现重复资源后继续返回 208，与操作因客户端不理解 208 而整体失败的 508。
- 能否给出确定性终止、预算、观测和客户端回退，而不是只说“加一个 visited 集合”。
先澄清哪些问题
- 请求方法和 Depth 值是什么？只有需要递归遍历的范围才会触发该语义。
- 服务是否实现 RFC 5842 binding 扩展并声明 DAV 能力？客户端是否理解 208？
- 图节点按资源 ID、规范化 URI 还是 binding 路径去重？同一资源可能有多个 URI。
- 响应要报告部分结果，还是协议要求整个操作原子失败？
- 最大节点数、响应体大小、CPU 时间和认证范围如何限制恶意深遍历？
30 秒回答框架
先限定语义：508 表示服务器在处理 WebDAV Depth: infinity 操作时遇到绑定循环，因而终止整个操作，不是通用的 HTTP 重试状态。把绑定关系看成图，按资源身份检测回边；若客户端理解 208，可在多次绑定只报告一次资源并继续返回多状态结果；不理解 208 时，服务可用 508 明确失败。遍历还要有节点、深度、字节和时间预算，记录 cycle 位置并让客户端停止自动重试。
分步作答
1. 画出资源图而非只看 URL 字符串
节点是资源或集合，边是 binding。URI 是访问路径，不一定是资源身份；同一资源可能拥有多个 binding。因此同时保留资源 ID、当前路径和父路径，用于结果去重、审计和诊断。
2. 采用显式 DFS/BFS 状态
维护当前递归栈和全局已报告集合。进入节点前检查它是否已在当前栈中；命中就是回边。若只是另一条路径再次到达同一资源，可按协议能力决定返回已报告标记，而不是无限展开。
visit(node, path):
if node in activePath: return CYCLE
if node in reported: return ALREADY_REPORTED
budget.consume(node)
activePath.add(node)
report(node)
for child in children(node): visit(child, path + child)
activePath.remove(node)activePath 识别真正的回路，reported 防止多 binding 重复输出；不能只用一个集合，否则可能把合法的共享资源误判成循环。
3. 根据客户端能力选择 208 或 508
如果客户端声明理解 binding 扩展及 208，服务可以在多状态响应中让首次出现的资源正常返回，后续重复 binding 标为 Already Reported，并省略其后代。若客户端不理解 208，RFC 5842 的兼容路径允许因无限深度循环让整次操作以 508 失败。响应不能伪装成成功的 200。
4. 设计确定性预算与安全边界
即使没有循环，深层或宽集合也可能耗尽 CPU、内存和响应体。设置最大节点数、活动路径长度、总字节、墙钟时间和并发限制；超预算时记录原因并返回明确的业务错误或协议允许的失败，不要继续重试。对跨租户 binding 做权限检查，避免把不可见节点泄露到多状态响应。
5. 处理写操作与并发变化
BIND、REBIND、UNBIND 会改变图。读操作开始时固定一致性视图或版本，避免遍历中途拓扑变化让检测失效。写操作在创建可能成环的 binding 前可执行可达性检查，或要求显式允许 cycle；检查与提交要在同一事务边界内。
6. 让客户端停止错误重试
508 表示请求操作失败，客户端不应像 503 那样盲目按指数退避重试。客户端应读取响应体和日志关联 ID，改用有限深度、修复 binding 或请求服务器提供能力信息。若 API 代理把 508 映射成统一错误，也必须保留原始状态和可诊断字段。
高质量示范答案
我会把 binding 建模成有向图，并区分资源身份与访问 URI。处理 Depth: infinity 时，用当前递归栈检测回边，用已报告集合抑制同一资源经多个 binding 重复输出；两者不能混为一个集合。遍历前设节点、深度、响应字节和时间预算，并在一致性视图中执行。
若客户端声明理解 RFC 5842 的 208，服务可以在 207 多状态响应中首次报告资源，后续重复项标记 Already Reported，避免展开后代。对不理解 208 的客户端，遇到循环时按 RFC 5842 以 508 终止整个无限深度操作。508 不是通用重试错误，客户端应停止自动重试并修复图或降低深度。所有路径还要做权限检查、指标和关联日志，防止循环与超深遍历成为 DoS。
常见失分点
- 把 508 解释成反向代理重试次数耗尽或普通 URL 重定向循环。
- 只按字符串 URI 去重，忽略多个 binding 指向同一资源。
- 只设置全局 visited，误把共享资源当成回边，或无法区分 208 与 508。
- 没有节点、字节、时间和权限预算，任意接受
Depth: infinity。 - 对 508 自动重试，导致同一拓扑持续消耗资源。
- 忘记客户端能力协商、207 多状态响应和写操作竞态。
追问与参考回答
508 与 208 的边界是什么？
208 用于客户端理解绑定扩展时报告已经出现过的资源，允许操作继续返回其余结果；508 表示遇到循环后整个无限深度操作被终止，常用于不理解 208 的兼容路径。
为什么不能只用 URI 作为 visited key？
多个 URI 可能 binding 到同一资源，单看 URI 会重复遍历；反过来，路径上下文仍有诊断价值，所以应同时保存资源身份与路径。
如何避免检查与写入之间的 TOCTOU？
在同一事务或版本化快照中做可达性检查与 binding 提交；若跨节点无法原子化，就用版本条件失败并重新检查。
客户端收到 508 是否应该重试？
默认不应盲重试。它表示当前拓扑下操作失败，应限制深度、修复循环或获取能力信息；只有拓扑明确改变后才重新发起。
如何验证循环检测没有误报？
构造无环 DAG、共享资源、多 binding 环和深度超限四组夹具，分别检查结果数量、状态码、遍历预算、审计日志和响应体上限。
508 是否适用于任意微服务调用环？
不能直接泛化。508 的标准语义来自 WebDAV RFC 5842；其他服务环路应使用自身错误契约，必要时保留 5xx 但不能声称符合 508 的 WebDAV 语义。