HTTP状态码消息的长度是否有最大限制？

Question

我正在一个项目中负责前端开发，还有另外一位负责构建API。我提议所有请求都应该按照以下JSON格式进行：

{
  "success": true, // true/false
  "message": null, // a string if success==false indicating the error
  "data": {} // The actual data in the response
}

他们更关心使API更加符合RESTful规范，而不是使用“message”字段。他们建议在状态码消息中发送消息，例如在HTTP头中：

HTTP/1.1 401 Authentication Failed for [e-mail]. Please log in again.

前端将会以弹窗或其他方式显示“[e-mail]认证失败，请重新登录。”

我担心有长度限制，但是我没有找到任何指示没有最大长度的东西。我们是否应该确保将这些消息保持在最小长度？有没有不这样做的好理由，而是将其作为内容发送（JSON或纯文本）？

- jkjustjoshing

---

在我使用IIS Express和Google Chrome进行测试时，当错误消息过长和/或包含换行符时，我会收到“ERR_CONNECTION_RESET”错误。 - Uwe Keim

Answer 1

一点测试可以解决大问题，但您应该能够这样做，并且事实上RFC明确指出：

此处列出的原因短语仅供参考--它们可能被本地等效物替换而不影响协议。

您唯一可能担心的问题是标题大小（某些服务器可能存在限制，但我认为它们都相对较大）以及一些旧版浏览器可能如何反应。老实说，我认为使用响应正文更有意义，因为它更易于解释和清晰，但您的方法应该没有任何问题。

- Explosion Pills

---

请注意，RFC 2616已于上个月被RFC 7231至7235所取代。 RFC 7230指定了各种元素的长度要求，但未涉及状态响应中的“reason-phrase”。 - Barmar

Answer 2

我想补充一点，虽然规范中可能没有限制，但实际上实现可能会截断状态消息。我发现当我尝试在Jetty 9.4.14中进行类似OP的操作时，出现了这种情况。

我花了一些时间才找到截断消息的原因 - 存在一个硬编码、不可配置的1024个字符限制[请参见方法getReasonBytes(String)]。

（由于声望不足，无法将此作为评论发布）

- Archangel1C