HTTP 响应状态行最大大小答案

【问题标题】：HTTP Response Status-Line maximum sizeHTTP 响应状态行最大大小
【发布时间】：2012-03-01 09:15:37
【问题描述】：

快速提问 - HTTP 响应的状态行是否有最大大小？

在 RFC 中我找不到这些信息，就像这样：

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

据此我可以假设：

这将是 46 个字节的总和。

这个假设是正确的还是我遗漏了什么？

更新：

由于下面的答案，我只想说明一下我的问题：

我正在使用来自服务器的 TCP 消息解析某种日志文件。现在有一些我不关心的随机数据和一些我想阅读的 HTTP 消息。现在我得到的所有数据都解析为\r\n 以找到状态行。因为我需要假设我的标头被拆分为几个 TCP 包，所以我只是缓冲所有数据并解析它。

如果标题状态行没有最大大小，我需要缓冲所有数据，直到出现下一个\r\n。在最坏的情况下，这意味着我节省了千字节的随机数据，因为它可能（但很可能不会）是标题状态行的一部分。

或者，在这种情况下，是否更适合解析 HTTP 版本字符串而不是 CRLF？

【问题讨论】：

【解决方案1】：

RFC 2616、6.1.1：

此处列出的原因短语只是建议 -- 它们可能是在不影响协议的情况下替换为本地等效项。

除此之外，“允许”HTTP 协议在不将 HTTP 版本更改为 1.2 的情况下添加更多状态代码（在新 RFC 中），前提是新代码不会对 HTTP 客户端引入额外要求。客户端应该将未知状态代码视为 x00（其中 x 是他们获得的代码的第一个数字，表示响应的类别），除了他们不应该缓存响应。

因此，唯一的限制是 HTTP 标头行或响应标头的总长度的最大长度。据我所知，RFC 没有定义任何限制，尽管特定的服务器有自己的限制。

您可以确定的是，用户代理可能会完全忽略原因短语。因此，如果它很大，您可以将其分成小块阅读，然后一次扔掉，直到达到 CRLF。如果您想显示人类可读的消息，大多数情况下您可以使用推荐的原因短语作为服务器提供的状态代码，而不管服务器发送什么原因短语。

【讨论】：

感谢您的回答 - 我更详细地说明了我的问题，以使我的问题更准确！
@Toby：鉴于您的更新，我会说是，首先检查 HTTP 版本字符串以确保您有 HTTP 响应。如果它在那里，请查看 HTTP 响应的其余部分（尽管理论上可能有 kb 的原因短语，但实际上不会有，因为这些消息都来自可能表现得相当理智的真实服务器，而不是来自理论服务器将其原因短语发送为 24fps ASCII 艺术，以解释性舞蹈的形式描述问题）。如果它不存在，请继续。
好的，所以这意味着我至少可以假设 HTTP 标头状态行将始终以 HTTP/X.X ..? 开头？
@Toby：嗯，您的服务器最终可能会支持 HTTP 的未来版本，因此每个“X”可以是多个数字。但是无论如何，您都需要在某处更新一些代码，以便了解这个新 HTTP 版本的响应标头。在此之前，HTTP 响应将以“HTTP/1.0”或“HTTP/1.1”开头。

【解决方案2】：

我认为 ReasonPHrase 的长度没有任何限制。 W3C 文档声明这是一条“短消息”，但这不是规范的。

我不会假设版本是 8 个字符。也许未来的版本可能有 3 位数字，即：HTTP/10.1。语法指定版本由空格分隔，所以我会通过在第一个空格处停止来解析它。

原因短语旨在给出状态代码的简短文本描述。状态代码供自动机使用，原因短语供人类用户使用。客户不需要检查或显示原因短语。

【讨论】：