1、428 Precondition Required (要求先決條件)

先決條件是客戶端傳送 HTTP 請求時，必須要滿足的一些預設條件。一個好的例子就是 If-None-Match 頭，經常用在 GET 請求中。如果指定了 If-None-Match ，那麼客戶端只在響應中的 ETag 改變後才會重新接收回應。

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

當伺服器端使用 428 Precondition Required 狀態碼時，表示客戶端必須傳送上述的請求頭才能執行該請求操作。這個方法為伺服器提供一種有效的方法來阻止 “lost update”問題的出現。

2、429 Too Many Requests (太多請求)

當你需要限制客戶端請求某個服務的數量，也就是限制請求速度時，該狀態碼就會非常有用。在此之前，有一些類似的狀態碼。例如“509 Bandwidth Limit Exceeded”。

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

3、431 Request Header Fields Too Large (請求頭欄位太大)

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

4、511 Network Authentication Required (要求網路認證)

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

如果你頻繁使用筆記本和智慧手機，你可能會注意到大量的公用 Wifi 服務要求你必須接受一些協議或者必須登入後才能使用，這是通過攔截HTTP流量實現的。當用戶試圖訪問網路返回一個重定向和登入，這很討厭，但是實際情況就是這樣的。

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

• 如果你在登入Wifi前訪問某個網站，網路裝置將會攔截首個請求，這些裝置往往也有自己的網站圖示“favicon.ico”。登入後你會發現，有一段時間內你訪問的網站圖示一直是Wifi登入網站的圖示。
• 如果客戶端使用HTTP請求來查詢文件，網路將會響應一個登入頁，這樣你的客戶端就會解析錯誤並導致客戶端執行異常，在現實中這種問題非常常見。

而 511 狀態碼的提出就是為了解決這個問題。因此，如果你正在編寫 HTTP 的客戶端，你最好還是檢查 511 狀態碼以確認是否需要認證後才能訪問。