RFC 6585 最近剛剛發(fā)布，該文檔描述了 4 個新的 HTTP 狀態(tài)碼。

HTTP 協(xié)議還在變化？是的，HTTP 協(xié)議一直在演變，新的狀態(tài)碼對于開發(fā) REST 服務或者說是基于 HTTP 的服務非常有用，下面我們?yōu)槟阍敿毥榻B這四個新的狀態(tài)碼以及是否應該使用。

428 Precondition Required (要求先決條件)

先決條件是客戶端發(fā)送 HTTP 請求時，如果想要請求能成功必須滿足一些預設的條件。

一個好的例子就是 If-None-Match 頭，經(jīng)常在 GET 請求中使用，如果指定了 If-None-Match ，那么客戶端只在響應中的 ETag 改變后才會重新接收回應。

先決條件的另外一個例子就是 If-Match 頭，這個一般用在 PUT 請求上用于指示只更新沒被改變的資源，這在多個客戶端使用 HTTP 服務時用來防止彼此間不會覆蓋相同內(nèi)容。

當服務器端使用 428 Precondition Required 狀態(tài)碼時，表示客戶端必須發(fā)送上述的請求頭才能執(zhí)行請求，這個方法為服務器提供一種有效的方法來阻止 'lost update' 問題。

429 Too Many Requests (太多請求)

當你需要限制客戶端請求某個服務數(shù)量時，該狀態(tài)碼就很有用，也就是請求速度限制。

在此之前，有一些類似的狀態(tài)碼，例如 '509 Bandwidth Limit Exceeded'. Twitter 使用 420 （這不是HTTP定義的狀態(tài)碼）

如果你希望限制客戶端對服務的請求數(shù)，可使用 429 狀態(tài)碼，同時包含一個 Retry-After 響應頭用于告訴客戶端多長時間后可以再次請求服務。

431 Request Header Fields Too Large (請求頭字段太大)

某些情況下，客戶端發(fā)送 HTTP 請求頭會變得很大，那么服務器可發(fā)送 431 Request Header Fields Too Large 來指明該問題。

我不太清楚為什么沒有 430 狀態(tài)碼，而是直接從 429 跳到 431，我嘗試搜索但沒有結(jié)果。唯一的猜測是 430 Forbidden 跟 403 Forbidden 太像了，為了避免混淆才這么做的，天知道！

511 Network Authentication Required (要求網(wǎng)絡認證)

對我來說這個狀態(tài)碼很有趣，如果你在開發(fā)一個 HTTP 服務器，你不一定需要處理該狀態(tài)碼，但如果你在編寫 HTTP 客戶端，那這個狀態(tài)碼就非常重要。

如果你頻繁使用筆記本和智能手機，你可能會注意到大量的公用 WIFI 服務要求你必須接受一些協(xié)議或者必須登錄后才能使用。

這是通過攔截HTTP流量，當用戶試圖訪問網(wǎng)絡返回一個重定向和登錄，這很討厭，但是實際情況就是這樣的。

使用這些“攔截”客戶端，會有一些討厭的副作用。在 RFC 中有提到這兩個的例子：

• 如果你在登錄WIFI前訪問某個網(wǎng)站，網(wǎng)絡設備將會攔截首個請求，這些設備往往也有自己的網(wǎng)站圖標 ‘favicon.ico'。登錄后您會發(fā)現(xiàn)，有一段時間內(nèi)你訪問的網(wǎng)站圖標一直是WIFI登錄網(wǎng)站的圖標。
• 如果客戶端使用HTTP請求來查找文檔（可能是JSON），網(wǎng)絡將會響應一個登錄頁，這樣你的客戶端就會解析錯誤并導致客戶端運行異常，在現(xiàn)實中這種問題非常常見。

因此 511 狀態(tài)碼的提出就是為了解決這個問題。

如果你正在編寫 HTTP 的客戶端，你最好還是檢查 511 狀態(tài)碼以確認是否需要認證后才能訪問。

英文原文，OSCHINA原創(chuàng)翻譯