修改HTTP響應的原因是否是一種好的做法？

HTTP錯誤具有與其數字代碼關聯的標準化響應字符串。例如。 404「未找到」或500「內部服務器錯誤」。從RFC中可以清楚地看出，這些字符串與識別錯誤（只有數字碼）是無關的，但是用例如龍捲風很明顯，原因是由錯誤代碼自動生成的，並且HTTPError類中的原因參數存在（根據文檔）使用非標準代碼，這意味着您通常不應該使用它。修改HTTP響應的原因是否是一種好的做法？

我的問題是：是否將原因字符串更改爲更具體的實際錯誤的良好實踐，例如「500無法連接到後端數據庫」或「500硬盤正在着火」，或者這種做法不鼓勵，錯誤應該保持「500內部服務器錯誤」，並且任何附加信息應該在有效載荷中？

來源

2016-07-29 Stefano Borini

問題是誰會使用這些信息。典型的客戶不會對信息做任何事情，甚至不會向用戶顯示價值。如果你有一個自定義的客戶端，你知道這個信息是以某種方式使用的，那麼它怎麼處理它或多或少取決於你。 – deceze

假設我正在開發自己的客戶端。 @deceze –

那麼，它只是在你和你的服務器之間，寶貝。只是你和你的服務器...;） – deceze

按照RFC 7230，用於消息語法和路由在HTTP/1.1的電流基準，原因短語的與提供與所述數字狀態代碼相關聯的文本描述的唯一目的存在和客戶端應該忽略原因短語內容。 RFC還指出，原因短語可以爲空。

查看報價以下：

3.1.2. Status Line

的響應消息的第一行是狀態行，由協議版本，一個空格（SP），狀態代碼，另一個空間，一個描述狀態代碼的可能爲空的文本短語，並以CRLF結尾。

status-line = HTTP-version SP status-code SP reason-phrase CRLF

[...]

原因短語元素存在於早期的互聯網應用協議提供與數字狀態代碼相關的文字說明，主要是出尊重的唯一目的是更經常地與交互式文本客戶端一起使用的是。客戶應該忽略原因短語內容。

reason-phrase = *(HTAB/SP/VCHAR/obs-text)

引述RFC 7231，用於語義電流基準和內容的HTTP/1.1協議：

6.1. Overview of Status Codes

[...]此處列出的原因短語是僅建議 - 它們可以用本地等價物替換而不影響協議。 [...]

理論上，有什麼都沒有，阻止你改變原因詞組。

然而，existing reason phrases是真正廣爲人知和廣泛採用。假設客戶端應該忽略原因短語，我會說這是不正確的地方發送錯誤消息。考慮使用響應負載。

來源

2016-07-29 09:42:14

這是我的問題的核心。我發現龍捲風確實會在4xx錯誤中提供個性化的原因字符串，所以至少在龍捲風中這是一種公認的做法。 –

修改HTTP響應的原因是否是一種好的做法？

回答

相關問題