修改HTTP响应的原因短语是一种好习惯吗？

Question

HTTP错误具有与其数字代码关联的标准化响应字符串。例如。 404“未找到”或500“内部服务器错误”。从RFC中可以清楚地看出，这些字符串与错误的识别无关（只有数字代码），但是对于例如龙卷风很明显，原因是从错误代码自动生成的，并且HTTPError类中的reason参数存在（根据文档）使用非标准代码，这意味着您通常不应该使用它。 / p>

我的问题是：将原因字符串更改为对实际错误更具体的内容是一种好习惯，例如“500无法连接到后端数据库”或“500硬盘处于激活状态”，或者不鼓励这种做法，错误应保持“500内部服务器错误”，并且任何其他信息应该在有效负载中？

Answer 1

HTTP / 1.1

根据RFC 7230，HTTP / 1.1中消息语法和路由的当前参考，原因短语存在，唯一目的是提供与数字状态代码相关的文本描述和客户端应忽略短语内容的原因。 RFC还声明原因短语可以为空。

见下面的引文：

  

3.1.2. Status Line

     

响应消息的第一行是状态行，包含   协议版本，空格（SP），状态代码，另一个   space，一个描述状态代码的空文本短语，   并以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

     

[...]此处列出的原因短语只是建议 -   它们可以被本地等价物替换，而不会影响协议。 [...]

理论上， nothing 阻止你改变原因短语。

然而，existing reason phrases确实众所周知并被广泛采用。假设客户端应该忽略原因短语，我会说这不是发送错误消息的正确位置。考虑使用响应有效负载。

HTTP / 2

重要的是要提到HTTP / 2根本不支持原因短语。请参阅RFC 7540：

中的以下引用

  

8.1.2.4. Response Pseudo-Header Fields

     

对于HTTP / 2响应，单个:status伪标头字段是   定义了携带HTTP状态代码字段。   这个伪头字段必须包含在所有中   对策;否则，反应不正确。

     

HTTP / 2没有定义携带版本或原因短语的方法    它包含在HTTP / 1.1状态行中。