我有一個處理文件，用於處理用戶發送的數據，但是在此之前，它將客戶端的輸入與預期值進行比較，以確保客戶端數據不會發生更改。
我可以說我對 HTTP 狀態碼了解不多，但我已經對其進行了一些研究，並選擇哪一個最適合意外輸入處理。所以我想出了：
400 Bad Request: The request cannot be fulfilled due to bad syntax
417 Expectation Failed: The server cannot meet the requirements of the Expect request-header field
現在，我不能真正確定使用哪一個，我已經看到 400 Bad Request 被大量使用，但是，我從解釋中得到的是，該錯誤是由於不存在的請求而不是非法輸入造成的。
另一方面，417 Expectation Failed 似乎很適合我的使用，但是，我以前從未見過或嘗試過此標頭狀態。
我需要您的經驗和意見，非常感謝！
有關表單/流程頁面草稿和我的實驗的完整詳細信息，請遵循這個連結。
另外：我想要這個的另一個原因是為了防止谷歌操縱。這不僅會在後端使用，還會在前端使用，其中將顯示訪客/用戶互動以及要呈現的頁面內容。
我相信*，給出 200 OK 或 403 Forbidden 狀態代碼對於存在或允許存在的頁面是有效的。
*補充二：我現在研究了 417 和 100，發現它們與我嘗試做的類似（至少僅適用於上傳處理情況），在這裡： http://benramsey.com/blog/2008/04/http-status-100-continue/
- IE：*連結到 X 網站的網頁http://www.example.com/page.php?query=lol&query2=fail由於 HTTP 標頭給出為 OK，因此將被 Google 索引。
我得出的解決方案：
事實上，404 是我可能再次得到的結果。我只是想要一個不同的解決方案，如果 HTTP 提供的話，但到目前為止，404 似乎仍然是可用的最佳解決方案，謝謝大家，我的問題已經找到了答案。
答案1
如果 GET 請求的參數不正確，則規範的操作是發回 404（未找到）或 200（正常）。
使用 GET 請求的 RESTful 方式是查詢資源（取得某些內容）。因此，如果所需的參數與現有資源不對應（因為它們不完整），則可以準確地說未找到 URI 中查詢的資源。
實際上，如果您想避免瀏覽器忽略您的404 頁面並替換自己的404 頁面（我正在查看IE 9 和10），您可能需要使用200。的；您查詢應用程序，它會傳回一個結果（這恰好是一個錯誤，但不是 HTTP 層級的錯誤）。然而，這種使用方式並不是很RESTful。
答案2
417僅當客戶端發送伺服器無法滿足的 HTTP 標頭時才會發生該錯誤Expect，該標頭與請求中應用程式的「預期輸入」沒有任何關係。不要使用它。
另一方面，400只有當 HTTP 請求中存在伺服器無法理解的錯誤語法時，才應傳送錯誤。
400儘管我認為這更適合應用程式邏輯中的驗證失敗，但這些都不是真正適合的。
403在我看來，您在 Stack Overflow 上的問題中考慮使用的錯誤是最好的選擇。
當在$_GET 中找不到預期值時，我只是使用了403 Forbidden 標頭，但是，仔細想想，這實際上並不是一個需要登入的操作（不是為了這個，當然用戶必須登入才能查看管理員）面板），它更像是一個意外的值輸入。
您正在考慮401，這是需要身份驗證時使用的回應代碼。 403是對請求的一般拒絕，這聽起來正是您想要的。
這一切都假設您想要返回一個4xx響應代碼.. 這對於 API 來說是有意義的.. 但對於面向用戶的 HTML 頁面，您更可能希望200在正文中發送包含錯誤信息的 .
答案3
我不太清楚你在做什麼，但是還有一個你可能沒有考慮過的附加選項 - 200 - 好的。原因是您正確接收了數據，問題是它對您的應用程式無效，這實際上並不是 HTTP 協定的問題。
這裡相關的rfc是RFC2616。您可以使用 400，但是您需要向客戶端提供從 rfc 修改資料的能力
10.4.1 400 錯誤請求
由於語法錯誤，伺服器無法理解該請求。客戶端不應在未經修改的情況下重複請求。
關於 417，rfc 說
10.4.18 417 期望失敗
此伺服器無法滿足 Expect 請求頭字段（請參閱第 14.20 節）中給出的期望，或者，如果伺服器是代理，則伺服器有明確的證據表明下一跳伺服器無法滿足該請求。
因此，如果您不使用 Expect 標頭，您可能不應該使用此回應。