RFC 6585 最近剛剛發布,該文檔描述了 4 個新的 HTTP 狀態碼。
HTTP 協議還在變化?是的,HTTP 協議一直在演變,新的狀態碼對於開發 REST 服務或者說是基於 HTTP 的服務非常有用,下面我們為你詳細介紹這四個新的狀態碼以及是否應該使用。
先決條件是客戶端發送 HTTP 請求時,如果想要請求能成功必須滿足一些預設的條件。
一個好的例子就是 If-None-Match 頭,經常在 GET 請求中使用,如果指定了 If-None-Match ,那麼客戶端只在響應中的 ETag 改變後才會重新接收回應。
先決條件的另外一個例子就是 If-Match 頭,這個一般用在 PUT 請求上用於指示只更新沒被改變的資源,這在多個客戶端使用 HTTP 服務時用來防止彼此間不會覆蓋相同內容。
當服務器端使用 428 Precondition Required 狀態碼時,表示客戶端必須發送上述的請求頭才能執行請求,這個方法為服務器提供一種有效的方法來阻止 'lost update' 問題。
當你需要限制客戶端請求某個服務數量時,該狀態碼就很有用,也就是請求速度限制。
在此之前,有一些類似的狀態碼,例如 '509 Bandwidth Limit Exceeded'. Twitter 使用 420 (這不是HTTP定義的狀態碼)
如果你希望限制客戶端對服務的請求數,可使用 429 狀態碼,同時包含一個 Retry-After 響應頭用於告訴客戶端多長時間後可以再次請求服務。
某些情況下,客戶端發送 HTTP 請求頭會變得很大,那麼服務器可發送 431 Request Header Fields Too Large 來指明該問題。
我不太清楚為什麼沒有 430 狀態碼,而是直接從 429 跳到 431,我嘗試搜索但沒有結果。唯一的猜測是 430 Forbidden 跟 403 Forbidden 太像了,為了避免混淆才這麼做的,天知道!
對我來說這個狀態碼很有趣,如果你在開發一個 HTTP 服務器,你不一定需要處理該狀態碼,但如果你在編寫 HTTP 客戶端,那這個狀態碼就非常重要。
如果你頻繁使用筆記本和智能手機,你可能會注意到大量的公用 WIFI 服務要求你必須接受一些協議或者必須登錄後才能使用。
這是通過攔截HTTP流量,當用戶試圖訪問網絡返回一個重定向和登錄,這很討厭,但是實際情況就是這樣的。
使用這些“攔截”客戶端,會有一些討厭的副作用。在 RFC 中有提到這兩個的例子:
因此 511 狀態碼的提出就是為了解決這個問題。
如果你正在編寫 HTTP 的客戶端,你最好還是檢查 511 狀態碼以確認是否需要認證後才能訪問。