後端面試：如何設計 HTTP 413 Content Too Large 的處理契約？

題干與適用場景

一個影片上傳請求可能經過 CDN、API 閘道、應用服務與物件儲存，每一層可接受大小不同。請設計 413 Content Too Large 的回應、限制發現、分片或工作階段恢復、Retry-After、錯誤本文字與監控方案。

這是後端 API 可靠性題。影片大小和層數是題設，不代表市場頻率。

面試官考察點

• 能否區分永久超限、暫時容量問題與正文校驗失敗。
• 能否正確解釋 413 與 Retry-After 的關係。
• 能否設計可恢復上傳而非盲目重試完整正文。
• 能否處理多層代理限制、冪等與錯誤資訊洩露。

回答前需要釐清的問題

1. 413 來自哪一層，回應是否保留限制範圍和請求 ID？
2. 限制按單請求、租戶、物件、時間窗口還是剩餘配額計算？
3. 客戶端是否支援分片、斷點續傳和查詢上傳工作階段？
4. 超限是固定設定還是因容量、配額而暫時發生？
5. 已接收部分是否會產生計費、鎖或物件元資料副作用？

30 秒回答框架

「413 表示伺服器拒絕處理過大的請求；固定大小限制不應讓客戶端盲目等待，暫時條件才適合提供 Retry-After。邊緣層應盡早拒絕並返回穩定錯誤碼、請求 ID 和可公開上限，應用層仍校驗真實位元組數。大檔案走建立上傳工作階段、分片和冪等完成提交，斷線先查詢狀態。客戶端只按 Retry-After 或工作階段狀態恢復，不重傳已確認分片。我會按每層、租戶和大小分布監控 413。」

分步深入解答

1. 先分層限制

固定上限、租戶配額、物件策略和執行時容量應有清晰來源。邊緣閘道可用 Content-Length 先拒絕，應用還要檢查實際接收位元組、壓縮展開後大小和內容策略。錯誤回應應帶請求 ID；不暴露內部節點、真實磁碟容量或其他租戶資訊。

2. 正確理解 Retry-After

RFC 9110 允許伺服器在 413 條件暫時存在時產生 Retry-After，值可以是 HTTP 日期或延遲秒數。固定限制通常不能靠等待解決，客戶端應修改請求或使用分片；有明確恢復時間的配額或維護窗口才適合重試。客戶端要限制最大等待並處理無效或過大的值。

HTTP/1.1 413 Content Too Large
Retry-After: 120
Content-Type: application/problem+json
X-Request-Id: req-81a

3. 讓錯誤本文字可行動

錯誤本文字可包含穩定錯誤碼、作用範圍、允許的上傳模式、單片上限和上傳工作階段入口。不要把閘道實作名、堆疊或資料庫錯誤直接返回。客戶端依錯誤碼選擇壓縮、縮小、分片或重新申請配額，而不是對相同正文無限重試。

4. 使用可恢復上傳

大物件先建立上傳工作階段，伺服器返回工作階段 ID、過期時間、分片大小範圍和已完成分片查詢介面。每片使用內容摘要和冪等鍵；完成操作只引用已驗證分片。收到 413 時，客戶端可以縮小新分片或重新建立工作階段，不必重傳已確認資料。

5. 處理多層不一致

閘道可能先於應用返回 413，應用也可能因解壓、配額或策略拒絕。統一錯誤模型不能假設每層都知道最終上限；服務端可在建立工作階段時返回目前可用約束，監控不同來源的 413，避免把一層暫時值快取成全域永久值。

6. 綁定重試、計費與監控

客戶端收到 413 後先分類：固定限制改請求，暫時限制遵循 Retry-After，工作階段失敗則查詢狀態。伺服器用冪等鍵防止完成提交重複扣費，定期清理過期工作階段。監控來源層、租戶、請求大小、已上傳位元組、Retry-After 遵從率、分片重傳和最終成功率，檢測限制設定漂移。

高品質示範回答

「我先確定 413 的產生層和限制類型。固定上限直接返回 413 與可公開上限或分片入口；只有暫時配額或容量條件才返回 Retry-After。大檔案透過上傳工作階段和分片完成，分片帶摘要與冪等鍵，客戶端斷線先查詢已確認片。邊緣層盡早拒絕，應用層仍校驗真實位元組與解壓後大小。錯誤本文字只給穩定碼、請求 ID 和下一步。我會監控 413 來源、大小分布、等待遵從、重複提交和最終恢復率。」

常見錯誤

• 所有 413 都回傳 Retry-After → 固定限制造成無效等待 → 只對暫時條件提供時間。
• 把上限寫死在客戶端 → 多層設定漂移 → 工作階段返回目前約束並監控來源層。
• 重新上傳完整正文 → 浪費頻寬並增加重複副作用 → 使用分片、查詢和冪等完成。
• 只檢查 Content-Length → 解壓或實際位元組可能超限 → 接收過程和內容階段再次校驗。
• 暴露內部限制細節 → 洩露拓撲與容量資訊 → 返回穩定錯誤碼和請求 ID。

追問及應對

413 沒有 Retry-After，客戶端應該怎麼做？

不要猜等待時間。把它視為固定或未知限制，讀取錯誤碼和工作階段狀態，改用更小請求、分片或人工配額流程；只有服務端明確提供可恢復時間才自動等待。

分片大小也超過某層上限怎麼辦？

建立工作階段時返回目前允許範圍，讓客戶端選擇不超過最小有效上限的分片。若中途策略變化，保留已確認片，使用新工作階段參數繼續，避免把舊片重新提交。

閘道返回 413，但應用沒有看到請求，如何定位？

比較邊緣、閘道和應用的請求 ID、接收位元組和回應來源。若應用完全無記錄，優先檢查閘道上限、路由和請求本文字轉發；不要把缺少應用日誌解釋成應用拒絕。