題干與適用場景
這道 HTTP 與 API 基礎題適合後端、平台、SRE 和基礎設施職位。請求原則上有效，但伺服器因配額、檔案系統、記憶體預算或應用程式限制耗盡，無法保存最後的資源狀態。回答要說明 507 何時有意義、何時應選其他狀態碼，以及如何避免重複寫入。
面試官考察點
- 能否區分伺服器容量耗盡與請求無論如何都過大的情況。
- 是否知道 507 源自 WebDAV，代表暫時的伺服器條件，不是通用驗證錯誤。
- 能否定義重試、退避、冪等和使用者補救動作，同時不隱藏原因。
- 能否沿著應用程式、儲存、配額、代理和快取層定位真正限制。
回答前需要釐清的問題
先問失敗的操作、請求表示是否合法、耗盡的是哪種資源、限制是否按租戶劃分，以及操作是否已留下部分狀態。確認用戶端能否安全重試、服務是否提供配額或容量訊號。若內容不論目前容量如何都超過策略或解析器限制，應使用 413；若服務整體暫時無法處理請求，503 可能更準確。不要因為某台機器出現磁碟告警，就把所有寫入失敗都歸為 507。
30 秒回答框架
當操作本身有效，但伺服器因可用儲存或適用的伺服器限制耗盡而無法記錄最後資源狀態時，我會回傳 507。413 表示請求過大，503 表示更廣泛的暫時不可用，三者邊界要依實際故障層判斷。回應包含穩定的錯誤類型和請求 ID，不洩漏內部路徑。只有冪等操作或帶冪等鍵的寫入才允許帶界限退避重試；維運需要找出耗盡的具體維度、釋放或擴容，並在恢復後驗證完整寫入。
分步驟深入解答
- 先分類故障。 RFC 4918 將 507 定義為方法執行後無法記錄資源狀態，因為目的端沒有足夠空間。MDN 也說明實作中可能用於其他耗盡的伺服器資源或應用程式限制。關鍵條件是請求有效，卻被伺服器容量邊界阻斷。
- 區分相鄰狀態碼。 內容獨立於目前容量都過大時回傳 413；狀態衝突或前置條件失敗時使用 409 或 412；服務整體處理能力暫時不可用時使用 503，並可搭配
Retry-After。507 不應成為所有寫入失敗的兜底。 - 讓錯誤可採取行動。 回傳穩定的 problem type、可讀標題、請求 ID；只有預期容量會恢復時才給重試提示。租戶配額可以給安全的配額識別或補救入口，但檔案路徑、主機名稱和內部策略留在日誌中。
- 保護重試。 上傳逾時後提交狀態可能未知。要求冪等鍵或可恢復上傳權杖，保存操作狀態，讓用戶端先查詢再重放。設定指數退避和總期限；無限重試會進一步放大資源耗盡。
- 定位資源邊界。 記錄可用位元組或 inode、物件儲存配額、資料庫或 blob 暫存、記憶體限制、租戶分配，以及發出 507 的層。透過請求 ID 對齊應用程式日誌和儲存指標，避免把代理錯誤誤認為來源站決定。
- 恢復並驗證。 必要時暫停或拒絕新寫入，釋放或擴容後用原冪等鍵重試有界操作。核對物件校驗和、詮釋資料、可見性與配額帳本。為重複故障設告警，並驗證一個租戶耗盡資源時不會侵佔另一租戶的預留量。
高品質示範回答
我只在請求有效、但伺服器因儲存或其他伺服器資源限制無法保存最後狀態時使用 507。固定請求大小策略導致的失敗用 413；維護或整體過載導致的暫時不可用可能用 503。回應提供穩定錯誤類型和請求 ID，只有容量確實可能恢復時才提供重試提示：
HTTP/1.1 507 Insufficient Storage
Content-Type: application/problem+json
Cache-Control: no-store
Retry-After: 120
{
"type": "https://api.example.com/problems/storage-exhausted",
"title": "The resource could not be stored",
"status": 507,
"detail": "The workspace storage limit prevented this operation.",
"request_id": "req-7f2"
}用戶端不能盲目重送狀態未知的上傳，而應使用同一個冪等鍵或先查詢操作狀態。維運把請求與配額、暫存區、物件儲存、資料庫和 inode 指標關聯，恢復後核對校驗和、可見性與帳本。若閘道回傳 507 而來源站回傳 200，就把閘道視為發出錯誤的層，逐跳驗證。
常見錯誤
- 把請求過大回傳 507 → 容量變化也不會讓它合法 → 固定大小策略應使用 413。
- 每次 507 都立即重試 → 已滿資源會更擁塞 → 使用有界退避和操作期限。
- 逾時後重放上傳 → 原寫入可能已經成功 → 查詢狀態或複用冪等鍵。
- 只說「磁碟滿了」卻不定位邊界 → 配額、inode、暫存區和物件儲存可能分別失敗 → 識別發出層和耗盡維度。
- 向用戶端回傳路徑和主機名稱 → 可能洩漏拓撲和租戶資訊 → 回傳穩定錯誤類型與請求 ID，診斷留在受保護日誌中。
追問及應對
用戶端應重試 HTTP 507 嗎？
只有操作可安全重試且容量預計會恢復時才重試。寫入要使用冪等鍵或狀態查詢，搭配指數退避和總期限。若是硬性租戶配額，應提供補救動作而不是繼續重試。
如何區分 507 與 503？
507 指向保存有效資源狀態時遇到儲存或伺服器限制；503 指向更廣泛的暫時無法服務，可能來自維護或過載。依測量到的故障邊界和一致的服務策略選擇，不要只憑 HTTP 層猜測。
來源站成功但代理回傳 507 怎麼辦？
用請求 ID 比對直連來源站、代理和冷快取請求。代理就是發出錯誤的層，可能擁有自己的緩衝區或配額。重試前先核對用戶端最終狀態，因為來源站可能已經保存資源。