通用面試：HTTP 208 Already Reported 何時使用，如何避免誤用？
題幹與適用場景
WebDAV 服務允許同一資源被多個 binding 指向。客戶端以 Depth infinity 發出 PROPFIND，伺服器在同一個 207 Multi-Status 回應中多次遇到相同資源。請說明 208 Already Reported 的語意、何時產生、舊客戶端策略，以及它與 508 Loop Detected 的差異。
題目聚焦 RFC 5842 的 WebDAV binding 擴充；208 不是一般 REST API 用來表示「資料已存在」的通用成功碼。
面試官考察點
- 能否指出 208 是 207 Multi-Status 內部的 status 元素結果，而非獨立 HTTP response body。
- 能否理解 binding alias、資源身分和重複列舉的關係。
- 能否區分「已報告」與真正的 binding loop，並正確使用 508。
- 能否設計 Depth、客戶端能力、XML 解析和日誌觀測。
回答前需要釐清的問題
- 服務是否支援 RFC 5842 binding 方法與
DAV:resource-id？ - 客戶端是否理解 208，還是只支援基本 WebDAV 207？
- PROPFIND 的 Depth 是 0、1 還是 infinity，是否有伺服器上限？
- 重複來源是多個 binding、符號連結，還是實際的父子迴圈？
- 產品需要完整 alias 清單，還是只需每個資源回報一次？
30 秒回答框架
「208 只在 207 Multi-Status 中標記同一回應內已經報告過的資源，通常用於 WebDAV binding 造成的重複枚舉。伺服器先以穩定 resource-id 去重，再對第一次出現回傳完整 propstat，後續同資源回傳 208；若是無法安全終止的 binding loop，應回傳 508。對不理解 208 的客戶端，我會限制 Depth 或降級成可解析的 207，並記錄去重、深度、迴圈和截斷原因。一般 REST 的『已存在』不應使用 208。」
分步驟深入解答
1. 確認回應層級
外層 HTTP 回應通常是 207 Multi-Status；每個 response 內含資源 URI 與一個或多個 propstat。208 是其中 DAV:status 的狀態行，表示該 binding 指向的資源已在同一個 Multi-Status 回應中報告，不能把整個 HTTP response status 寫成 208 來取代 207。
2. 以資源身分去重
URI 不一定等於資源身分。多個 binding 可能有不同 URI 卻指向同一資源；服務可用 DAV:resource-id 或內部穩定 ID 建立本次遍歷的 visited set。第一次遇到資源輸出完整屬性，後續 binding 輸出 208，仍保留該 URI 的關聯，避免無限重複 XML。
PROPFIND Depth: infinity
/alias-a -> resource R: full propstat
/alias-b -> resource R: 208 Already Reported
/child -> resource C: full propstat3. 將 208 限定在適用情境
208 的價值是節省 207 內容並避免 binding 重複；它不表示資料庫插入衝突、冪等重試成功或快取命中。對一般 JSON API，應選擇明確的 200、201、204 或 409 語意，避免客戶端看到無法理解的 WebDAV 狀態。
4. 區分 508 Loop Detected
如果遍歷發現 binding 關係形成迴圈，且不是單純同資源的再次列舉，伺服器需要停止遞迴並使用 508 Loop Detected。208 表示資源已在本次回應中成功報告；508 表示為避免無限迴圈而中止處理。測試要覆蓋 alias 重複、真正 cycle 和深度限制。
5. 相容與資源上限
先協商或觀測客戶端對 208 的解析能力。對舊客戶端可把 Depth infinity 限制為較小深度、拒絕不安全的請求，或在不破壞 WebDAV 語意的前提下返回可理解的 propstat。設定節點數、回應大小、時間和 visited set 上限，避免惡意 binding 消耗記憶體。
6. 觀測與故障回復
記錄 request ID、Depth、已訪問資源數、208 次數、508 次數、截斷原因、回應大小和客戶端能力；不要記錄檔案內容或憑證。若去重索引故障，寧可安全截斷並回傳明確錯誤，也不要輸出未終止的遞迴。保留可重現的 binding 圖以排查資源身分錯誤。
高品質示範回答
「外層回應仍是 207 Multi-Status，208 只出現在其中的 propstat status，表示同一資源已在這次回應報告過。對 Depth infinity 的 PROPFIND，我用 resource-id 建立 visited set：第一個 binding 回完整屬性，後續 alias 回 208；URI 仍保留，讓客戶端知道哪個 binding 被遍歷。若關係形成真正 cycle，就停止遞迴並回 508。208 不應拿來表示一般 API 的已存在或重試成功。對舊客戶端限制深度或拒絕高風險請求，並監測資源數、回應大小、208、508 和截斷原因。」
常見錯誤
- 把整個 HTTP response 設成 208 → 破壞 207 Multi-Status 結構 → 208 放在相應的 propstat status。
- 用 URI 當唯一資源鍵 → 不同 binding 仍重複列出資源 → 用 resource-id 或穩定內部身分去重。
- 用 208 表示資料已存在 → 一般 REST 客戶端語意錯誤 → 使用 409 或明確業務回應。
- 把所有重複都當 508 → 正常 alias 被誤判成迴圈 → 區分已報告資源與未終止 cycle。
- 沒有 Depth 和回應上限 → binding 圖可耗盡記憶體 → 限制節點、時間、大小並保留 visited set。
追問及應對
208 回應還需要帶 URI 嗎？
需要保留該 binding 對應的 response，讓客戶端知道哪個 URI 已被報告；但不必重複完整屬性。具體 XML 結構應符合 WebDAV Multi-Status 解析規則。
為什麼不直接刪除重複項？
刪除會讓客戶端無法知道 alias 已被遍歷，也可能誤以為伺服器漏回。208 保留遍歷證據，同時避免重複 property payload。
何時應拒絕 Depth infinity？
當客戶端不理解 208、binding 圖超過資源上限、或無法建立可靠 visited set 時，限制深度或拒絕請求比輸出不完整或無限遞迴更安全。