通用面試：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 操作時遇到 binding 循環，因而終止整個操作，不是通用 HTTP 重試狀態。把 binding 關係視為圖，按資源身分偵測回邊；若客戶端理解 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 用於客戶端理解 binding 擴充時報告已出現過的資源，允許操作繼續回傳其餘結果；508 表示遇到循環後整個無限深度操作被終止，常用於不理解 208 的相容路徑。
為什麼不能只用 URI 作為 visited key？
多個 URI 可能 binding 到同一資源，單看 URI 會重複遍歷；反過來，路徑上下文仍有診斷價值，所以應同時保存資源身分與路徑。
如何避免檢查與寫入之間的 TOCTOU？
在同一交易或版本化快照中做可達性檢查與 binding 提交；若跨節點無法原子化，就用版本條件失敗並重新檢查。
客戶端收到 508 是否應該重試？
預設不應盲重試。它表示目前拓撲下操作失敗，應限制深度、修復循環或取得能力資訊；只有拓撲明確改變後才重新發起。
如何驗證循環偵測沒有誤報？
建立無環 DAG、共享資源、多 binding 環和深度超限四組夾具，分別檢查結果數量、狀態碼、遍歷預算、稽核日誌與回應體上限。
508 是否適用於任意微服務呼叫環？
不能直接泛化。508 的標準語意來自 WebDAV RFC 5842；其他服務環路應使用自身錯誤契約，必要時保留 5xx 但不能聲稱符合 508 的 WebDAV 語意。