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

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

428 Precondition Required (要求先決條件)

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

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

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

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

429 Too Many Requests (太多請求)

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

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

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

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

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

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

511 Network Authentication Required (要求網(wǎng)絡(luò)認(rèn)證)

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

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

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

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

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

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

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

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