題幹與適用場景
WebDAV 客戶端存取資源時，伺服器返回 HTTP 508 Loop Detected。系統包含綁定、重寫規則和多個代理。請說明 508 的協定語義、如何證明存在循環、客戶端如何回退，以及怎樣避免重試風暴。
面試官考察點
- 是否知道 508 來自 WebDAV 綁定擴充，而非一般網路逾時。
- 能否區分伺服器檢測到循環與普通上游 5xx。
- 是否會記錄請求鏈、綁定圖和檢測預算。
- 是否能設計冪等、不可重試與人工修復邊界。
- 是否會避免暴露內部拓撲並保留稽核證據。
回答前需要釐清的問題
確認請求方法、DAV 綁定類型、循環是資源綁定還是代理重寫、是否存在重試中介軟體、是否有診斷 id，以及客戶端是否只讀。若不足，假設遍歷綁定圖時回到已訪問節點。
30 秒回答框架
508 表示伺服器處理 WebDAV 綁定時檢測到循環，無法完成請求。先把請求 id、綁定邊、代理轉發和訪問節點串成有向圖，確認是循環而非單次逾時。客戶端不應盲目重試；同一拓撲應快速失敗並提示修復。伺服器限制遍歷深度並避免回傳內部路徑。
分步驟深入解答
1. 定義協定語義
RFC 5842 為 WebDAV 綁定擴充定義 508，表示伺服器完成綁定操作時檢測到循環。它不是客戶端網路中斷，也不代表所有 5xx 都能重試。
2. 畫出綁定與代理圖
為每個資源或綁定節點分配內部 id，記錄邊的來源、目標、請求 id 和代理 hop。遍歷時維護 visited 集合；再次遇到節點即可證明循環。只到達深度上限應標為不同的保護性失敗。
3. 區分上游錯誤
代理可能把後端 508 包裝成另一狀態碼，也可能自己形成重寫循環。每一跳保留 trace id、原始狀態和 Via 資訊，避免只看邊緣回應。
4. 設計重試與回退
相同配置下重試不會改變拓撲循環，應快速失敗而非指數重試。只有配置修復、版本切換或明確控制面更新後才允許有預算地重試。產品允許時可退回不跟隨綁定的唯讀元資料查詢。
5. 控制資源與安全資訊
設定最大遍歷節點數、時間預算和回應大小。錯誤正文只給修復提示和關聯 id，不洩露內部主機名或完整綁定圖。稽核記錄可保存雜湊節點、邊類型和循環長度。
6. 監控與修復流程
監控 508 率、租戶和綁定類型分布、循環長度、遍歷耗時、重試次數和修復時長。寫入配置前做靜態環檢測；發現異常時凍結問題版本並回滾綁定。
7. 測試與驗收
測試自循環、雙節點循環、跨代理循環、深但無環圖、並行更新、快取過期和部分節點不可用。驗收包括穩定狀態碼、無重試風暴、診斷 id 可追蹤、敏感資訊不洩露，及修復後請求成功。
高品質示範回答
508 是 WebDAV 綁定擴充的 Loop Detected，表示解析綁定時回到已訪問節點。我會用請求 id 把資源綁定、重寫和代理 hop 建成圖，透過 visited 集合區分真正的環與深度保護。每跳記錄原始狀態和 trace id，避免邊緣代理隱藏根因。
同一配置下重試不會消除拓撲循環，因此客戶端快速失敗。修復先阻止問題綁定繼續發布，通過環檢測後再灰度恢復。伺服器限制節點數和時間，回應只給關聯 id。監控 508 率、循環長度、遍歷耗時和修復時長，並測試自環、跨代理環、深無環圖、並行更新和快取過期。
常見錯誤
- 把 508 當成普通逾時或所有 5xx 的同義詞。
- 用深度上限觸發 508 卻沒有證明循環。
- 對同一綁定拓撲無限重試。
- 只記錄邊緣狀態，丟失中間代理資訊。
- 在回應暴露完整內部綁定圖。
- 只擴容代理，不做寫入前環檢測。
追問及應對
追問一：深度達上限就是 508 嗎？
不一定。深度上限是保護策略，只有再次訪問同一節點才能證明循環，內部原因應可區分。
追問二：客戶端何時可以重試？
只有配置已修復、控制面版本變更或伺服器提供暫時性訊號時，才在預算內重試；同一拓撲應快速失敗。
追問三：如何避免洩露資源拓撲？
回應只給修復提示和關聯 id，日誌保存雜湊節點和邊類型，受控內部系統再查看圖。
追問四：代理把 508 改成 502 怎麼辦？
保留每跳 trace、Via 和原始狀態，建立端到端映射，不只依賴邊緣狀態判斷根因。