HTTP 1xx 中間回應與 102 Processing：面試如何判斷協定邊界？
題幹與適用場景
面試官可能會問：「HTTP 1xx 中間回應和 102 Processing 分別表示什麼？如果長請求需要進度回饋，你會怎麼設計？」
這題考察你能否區分請求尚未結束的協定訊號、最終回應和非同步工作狀態資源。RFC 9110 規定一次請求可以先收到零個或多個 1xx 中間回應，最後仍要收到一個非 1xx 的最終回應；它沒有把 102 定義成通用的百分比進度協定。102 的歷史定義來自 WebDAV RFC 2518，後來被 RFC 4918 從 WebDAV 移除。回答時應先確認協定版本、客戶端和代理能力，再決定是否採用它。
面試官考察點
- 是否知道 1xx 是中間回應，不能代表請求已完成。
- 是否能區分 100 Continue、101 Switching Protocols 與 102 Processing 的語義。
- 是否識別 102 的 WebDAV 歷史邊界，不把它當成跨客戶端可依賴的通用進度 API。
- 是否能為長工作選擇 202 加狀態端點、SSE 或 WebSocket 等較穩定的產品協定。
- 是否考慮代理轉送、逾時、重試、取消、冪等和最終結果讀取。
回答前需要澄清的問題
- 請求要同步維持連線，還是可以改成背景工作？
- 反向代理與閘道是否會轉送並暴露 1xx？
- 需求是「仍在處理」的保活訊號，還是可觀察的階段和百分比？
- 工作是否有副作用，客戶端重試是否可能重複執行？
- 完成結果是否有獨立資源、下載網址、過期時間和存取控制？
30 秒回答框架
可以這樣回答：
1xx 是最終回應之前的中間回應；客戶端最後仍要等待一個非 1xx 的結果。102 Processing 源於 WebDAV 的長處理場景，不能自然承載通用進度模型，也不能假設所有代理都會依預期傳遞。若工作可非同步化，我會回傳 202 和帶權限的狀態資源，狀態資源提供穩定狀態、錯誤、取消和結果連結；若必須維持連線，再根據客戶端能力考慮 SSE 或其他明確的事件協定，並驗證代理行為。
分步驟深入解答
先定義回應生命週期
把一次請求拆成中間階段與最終階段：
HTTP/1.1 102 Processing
HTTP/1.1 200 OK
Content-Type: application/json
{"result":"done"}102 不會結束請求，也不攜帶「工作完成」的承諾。RFC 9110 的關鍵限制是最後仍要有一個非 1xx 回應；中間回應遺失時，客戶端也不能據此推斷業務失敗。
再劃清 102 的適用邊界
RFC 2518 曾把 102 用作 WebDAV 長操作的處理中提示，目的是避免客戶端誤判連線失活。它不是帶有 percentComplete、階段列舉和錯誤契約的通用工作流資源。RFC 4918 移除了該 WebDAV 狀態碼定義，因此設計新 API 時必須說明目標實作和相容性，不能只憑狀態碼數字作跨技術棧承諾。
為產品需求選擇協定
若客戶端可以輪詢，優先把動作與狀態分離：提交回傳 202 和 Location，狀態資源回傳 Pending、Running、Succeeded、Failed、Canceled 等穩定狀態。若需要即時顯示階段，可在狀態資源之上增加 SSE；若需要雙向控制，再評估 WebSocket。每種方案都要給出斷線恢復、重試退避、取消語義和授權檢查。
處理重複提交與最終一致性
為建立工作提供冪等鍵，伺服器保存請求指紋和工作 ID；重試同一把鍵時回傳同一工作，而不是再次排隊。狀態資源的讀取應可重複，結果下載網址應短期有效並綁定租戶。失敗狀態需要結構化錯誤和可重試邊界，不能把 102 或連線中斷當成業務結論。
高品質示範回答
我先確認需求是保活提示還是可觀察的工作進度。如果只是同步請求可能超過閘道逾時，我不會直接把 102 當成通用進度介面：1xx 是最終回應前的中間回應，102 的語義還有 WebDAV 歷史，代理和客戶端支援也不一致。我的預設設計是提交介面驗證參數後回傳 202、工作 ID 和狀態 URL；狀態資源公開有限的階段、更新時間、結構化錯誤、取消入口和結果 URL，並用 Retry-After 給出輪詢建議。提交帶冪等鍵，重試不會重複建立工作。需要即時介面時再提供 SSE，並讓客戶端用最後事件 ID 或狀態資源恢復。若出現安全、合規或資料暴露風險，我會保留最終回應以外的稽核記錄並走正式升級路徑。這樣協定訊號、工作狀態和結果資源各自有清楚邊界。
常見錯誤
- 把 102 說成「進度百分比回應」，卻沒有標準欄位或客戶端契約。
- 認為收到任何 1xx 就可以關閉連線或認為請求成功。
- 忽略 RFC 4918 移除 102 的歷史，直接聲稱所有 WebDAV 客戶端都支援。
- 只討論伺服器發送回應，不驗證 CDN、代理、閘道和瀏覽器的實際行為。
- 回傳 202 卻沒有狀態資源、冪等策略、失敗狀態或結果存取控制。
- 把斷線、逾時和重試當作工作失敗，導致重複副作用。
追問及應對
1. 102 和 202 的核心差異是什麼？
102 是同一請求的中間回應，最終回應仍在後面；202 是最終回應，表示請求已被接受處理，但結果可能尚未完成。長工作若需要客戶端獨立觀察和恢復，202 加狀態資源通常更清楚。
2. 代理不轉送 1xx 時怎麼辦？
把 1xx 視為可選最佳化，不能作為業務正確性的唯一依據。透過狀態端點、SSE 或受控客戶端鏈路提供可恢復的狀態，並在真實代理鏈路上做相容性測試。
3. 什麼時候仍會使用 102？
只有在端到端實作明確支援、需求確實是同一長請求的處理中提示、且團隊接受相容性邊界時才考慮。應記錄客戶端、代理和逾時驗證結果，並準備沒有 102 時仍能正確工作的降級路徑。