HTTP 狀態碼為甚麼分成五類？RFC 9110 與常見狀態碼的由來

後來稱為 HTTP/0.9 的早期簡易協定，回應只有實體內容，沒有狀態列，也沒有今天熟悉的回應標頭。RFC 1945 以以下形式描述這種簡易回應：

Simple-Response = [ Entity-Body ]

這與現代 HTTP 的「先讀取狀態碼與標頭，再解讀內容」不同。討論狀態碼的起源時，不能把 HTTP 的誕生與狀態列的出現視為同一件事。

三位數狀態碼在 1992 年的 W3C 文件中就已出現，不是到 RFC 1945 才首次提出。早期設計文件也以 FTP 等協定的回覆碼為參考，說明數字分類可以方便程式處理。

Tim Berners-Lee、Roy Fielding 與 Henrik Frystyk 在 1996 年 5 月發表的 RFC 1945，記錄了 HTTP/1.0 的既有用法。完整回應以狀態列開始：

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

HTTP/1.0 200 OK

RFC 1945 列出 15 個狀態碼：200、201、202、204、301、302、304、400、401、403、404、500、501、502、503。因此，它是重要的整理文件，但不是所有狀態碼概念的起點。

這種分層讓接收端遇到不認識的狀態碼時，仍能理解大類別。RFC 9110 §15 規定，用戶端必須識別第一位數字代表的類別，並將不認識的狀態碼視同該類別的 x00 狀態碼處理。這並不表示未知狀態碼與已知碼的所有細節完全相同。

不能識別狀態碼，並不代表回應一律不得存入快取。能否儲存須另按 RFC 9111 §3 的條件判斷。即使狀態碼未知，若回應帶有 max-age 等明確指示，並符合其他條件，包括 no-store 及共用快取的限制，仍可能允許儲存。不過，帶有 must-understand 指示的回應，以及狀態碼為 206 或 304 的回應，都要求快取理解該狀態碼。能判斷類別，不等於可以無條件儲存或重用回應。

RFC 9110 是 HTTP 的共通語義規格，不只屬於 HTTP/1.1。HTTP/1.1、HTTP/2 與 HTTP/3 的傳輸方式不同，但方法、狀態碼等核心語義可共用。

418 I'm a teapot 出自 1998 年 4 月 1 日的 RFC 2324，主題是 Hyper Text Coffee Pot Control Protocol。茶壺拒絕煮咖啡的設定是愚人節幽默；該 RFC 的分類是 Informational，不是 Internet Standard。

現行 RFC 9110 與 IANA 登錄表把 418 標示為 「(Unused)」，保留這個號碼以避免與既有趣味實作混淆。歷史上有茶壺這個說法，不代表應在一般 API 中把它定義成任意的業務錯誤。

RFC 7725 於 2016 年 2 月定義 451 Unavailable For Legal Reasons，用來表示因法律要求而拒絕存取資源。數字取自 Ray Bradbury 的小說 Fahrenheit 451。

RFC 致謝中提到 Terence Eden 提出這個狀態碼；RFC 的作者則是 Tim Bray。回傳 451 的不一定是來源伺服器，也可能是執行封鎖的中介系統。這個碼表達的是回應中的法律障礙資訊，不是對特定地區或法律制度的評價。

402 Payment Required 在 1992 年的歷史文件中已經出現，但現行 RFC 9110 仍將它保留供未來使用，沒有定義通用的 HTTP 付款流程。

個別付款或訂閱 API 可能自行使用 402；那是該 API 的合約，不代表所有用戶端、瀏覽器或付款服務都理解同一套語義。實作時應依服務文件解讀，不能只憑狀態碼名稱推論付款流程。

2017 年 12 月的 RFC 8297 定義 103 Early Hints，文件分類是 Experimental。伺服器可在最終回應準備好之前，先用 Link 等標頭提示可能需要的資源：

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style

HTTP/1.1 200 OK
Content-Type: text/html

上例只展示標頭流程，省略最終內容。103 可能讓支援的用戶端提早開始載入資源，但效果取決於瀏覽器、中介設備與伺服器。網站的正確運作不能依賴用戶端一定收到或處理 103，最終回應仍須能獨立成立。

截至 2026 年 9 月 4 日查核，IANA HTTP Status Code Registry 顯示最後更新日期為 2025 年 9 月 15 日，共有 64 個個別列出的狀態碼。這個計數不含未分配區間，但包含標示未使用、已淘汰或暫時登錄的個別號碼，不能解讀成「64 個全部都適合新系統採用」。

其中 104 Upload Resumption Supported 是暫時登錄，當時列出的到期日為 2026 年 11 月 13 日。數量、狀態與到期日都可能改變；實作新功能前，請重新查看 IANA 登錄表與其引用規格。

• 早期 HTTP/0.9 沒有狀態列；三位數狀態碼已見於 1992 年 W3C 文件。
• RFC 1945 記錄 HTTP/1.0 的 15 個狀態碼，五大類別則方便處理未知碼。
• RFC 9110 定義 HTTP/1.1、HTTP/2 與 HTTP/3 共用的語義。
• 現行登錄中的 418 為未使用；451 表達法律障礙；402 仍保留供未來使用。
• 103 可先提供資源提示，但不能成為網站正確運作的必要條件。
• 登錄數量與暫時登錄期限要連同查核日期一起閱讀。