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

Question

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

我的问题是：将原因字符串更改为更适合实际错误的某种好习惯，例如“ 500无法连接到后端数据库”或“ 500硬盘着火”，还是不鼓励这种做法，错误应停留在“ 500 Internal Server Error”，有效载荷中应包含任何其他信息？

Answer 1

HTTP / 1.1

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

请参阅下面的报价：

3.1.2。状态线

响应消息的第一行是状态行，由协议版本，空格（SP），状态代码，另一个空格，描述状态代码的可能为空的文本短语组成，并以结尾CRLF。

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

[...]

原因短语元素的存在仅是为了提供与数字状态代码关联的文本描述，主要是出于对较早用于交互式文本客户端的Internet应用程序协议的尊重。客户应忽略原因短语内容。

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

引用RFC 7231，这是HTTP / 1.1协议的语义和内容的当前参考：

6.1。状态码概述

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

从理论上讲，没有什么可以阻止您更改原因短语。

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

HTTP / 2

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

8.1.2.4。响应伪头字段

对于HTTP / 2响应，:status定义了一个单独的伪标头字段，其中包含HTTP状态代码字段。该伪报头字段必须包含在所有响应中；否则，响应格式不正确。

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