題目與情境
伺服器拒絕解析超過設定上限的請求目標。原因可能是用戶端序列化、重導向迴圈、Cookie 或代理邊界，因此只提高一個伺服器限制未必有效。
面試官考察什麼
- 定位哪一跳的哪一個請求元件超限。
- 把資料從 URI 移到請求主體時保持 HTTP 方法語意。
- 設計有界、可觀測的查詢契約，而不是接受任意長 URL。
作答前的釐清問題
- 超長發生在路徑、查詢、重導向 Location，還是編碼後的狀態區塊？
- 哪一跳回傳 414：瀏覽器、CDN、負載平衡、閘道還是來源站？
- 操作是安全且可快取的讀取，還是會修改狀態？
- 是否需要可分享 URL、書籤，或需要保護篩選隱私？
30 秒回答框架
我會記錄請求目標長度和產生 414 的跳點，再檢查重導向、Cookie、編碼與篩選序列化。唯讀搜尋若篩選集合過大，我會增加有界 POST 搜尋介面或短期伺服器端查詢權杖，明確授權、快取與稽核規則。不會只提高單一代理上限而跳過全鏈路測試，也不會靜默截斷條件。
分步深入
1. 測量實際請求目標
記錄安全的長度指標、路由範本、重導向次數和關聯 ID，不記錄敏感查詢值。比較瀏覽器、CDN、閘道和來源站限制。Base64 狀態區塊、重複參數或重導向迴圈可能在應用程式碼執行前就讓 URI 增長。
2. 維持方法與快取語意
GET 安全且自然可快取，但 URL 不是無限資料傳輸通道。把大篩選集合移到 POST 會改變快取和書籤行為，應定義專用介面、回應快取策略和冪等預期。不要只為隱藏變更語意而把操作改成 POST。
3. 限制並規範化篩選
限制條件數量、值長度、巢狀深度和總編碼位元組數，一致拒絕格式錯誤或重複參數。規範化等價篩選，避免快取和簽章把參數順序差異當成不同請求。
4. 需要分享時使用查詢權杖
伺服器保存帶短 TTL 的規範化篩選物件，並綁定租戶、使用者授權及一次性或限定範圍的讀取。回傳可放入 URL 的短權杖。權杖或查詢字串不得放秘密和原始個人資料，並執行過期與撤銷。
5. 把 414 當作營運訊號
按路由、用戶端版本和代理跳點監控發生率，追蹤重導向鏈與序列化變更。安全回退可以提示使用者減少篩選，或提交到請求主體介面；不能靜默丟棄條件。
高品質示範回答
「我會先測量目標長度並定位哪一跳產生 414，再檢查重導向、Cookie、編碼和重複篩選。唯讀搜尋超過 URL 限制時，增加有界 POST 搜尋介面或帶授權的短期查詢權杖，明確快取和稽核語意。限制條件數與編碼位元組，絕不靜默截斷，並按路由和用戶端版本監控 414。只有測量、協調設定並完成濫用測試後才考慮提高某一跳上限。」
常見誤區
- 只提高來源站上限 → CDN 或閘道仍可能拒絕 → 測量並協調每一跳。
- 把資料移到 POST 卻不說明快取性 → 用戶端失去預期語意 → 定義快取、分享和冪等行為。
- 截斷過長篩選 → 結果不再代表使用者查詢 → 明確拒絕或使用有界替代介面。
- 在查詢權杖中放秘密 → URL 會進入日誌和 Referer → 使用有範圍、可過期和可授權的不透明權杖。
追問與回答
414 只由查詢字串造成嗎？
不是。請求目標包含路徑和查詢，重導向也可能生成過長目標。Cookie 影響的是請求標頭限制而非 URI，因此診斷必須識別具體超限元件。
所有大 GET 都應改成 POST 嗎？
不應。普通安全且可快取讀取繼續使用 GET；當請求表示無法適應實際 URI 限制時，再使用定義清楚的 POST 搜尋契約，並說明快取和分享行為變化。
為什麼不把所有限制都大幅提高？
過長目標會消耗解析、日誌、快取和安全資源，並造成跳點限制不一致。只有在有測量需求、協調設定並完成濫用測試後才提高限制。