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

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

我的问题是：对于实际错误，将原因字符串更改为更具体的内容，例如“500无法连接到后端数据库”或“500硬盘着火”，这是一种好的做法吗？还是不鼓励这种做法，错误应保持为“500 Internal Server error”，任何附加信息都应在有效负载中？

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

请参阅下面的报价：

响应消息的第一行是状态行，包括 在协议版本中，一个空格（

SP

），一个状态码，另一个 空格，一个描述状态代码的可能为空的文本短语， 并以

CRLF

结尾

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

[……]

原因短语元素存在的唯一目的是提供 与数字状态代码关联的文本描述，主要是 出于对早期互联网应用协议的尊重 更常用于交互式文本客户端。客户应该 忽略原因短语内容

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

引用HTTP/1.1协议的语义和内容的当前参考：

[…]此处列出的原因短语仅为建议-- 在不影响协议的情况下，它们可以被本地等价物替换。[……]

从理论上讲，没有什么能阻止你改变理由短语

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

HTTP/2 HTTP/2根本不支持原因短语。请参阅以下引用自：

对于HTTP/2响应，将显示单个

：status

伪头字段 已定义，其中包含HTTP状态代码字段。 此伪标头字段必须包含在所有 响应；否则，响应的格式不正确

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

---

问题是谁会使用这些信息。典型的客户端不会对信息做任何事情，甚至可能不会向用户显示值。如果您有一个自定义客户，您知道该客户以某种方式使用此信息，那么如何处理它或多或少取决于您。假设我正在开发自己的客户@那就在你和你的服务器之间，宝贝。只有你和你的服务器…；）这是我问题的核心。我发现tornado确实在一些4xx错误中加入了个性化的原因字符串，因此至少在tornado中这是一种公认的做法。@StefanoBorini我添加了一些关于HTTP/2的细节，您可能会觉得很有趣：）所以原因短语不应该用于返回业务逻辑错误？@Konrad如果它们对客户端有某种意义，否。使用响应负载返回错误的详细信息。您可能还想检查，因为它定义了一些报告HTTP API中问题的标准。@cassiomolin感谢您的详细说明-我已更正；）