在写一个 HTTP 服务器，想问一下请求报文中的 Content-Length 该如何验证

rfc 里面描述 content-length 时用的是 should 而不是 must，通过它来验证长度确实不靠谱。同好奇

content-length 是用来验证报文完整性而不是用来听之任之长度读取的吧。。

楼主，我觉得你的思路不对，首先 Http 是基于 TCP 的，每个连接的缓冲区都是独立的，现在假设有一个有恶意的人，伪造了 Content-Length，把它变的更长，那么就算你读下去，你读到的仍然是这个人后续发来的包，你就把后续得到的包数据也当成是 request body 的内容好了。这有什么问题呢，你是告诉我有这么长的，我就读这么长，我看过 Nginx 的实现，只有在读到不够长度的数据时才会报错断开连接，但是只要后续能继续读到数据，就会继续读下去，http 的 content-length 就是 body 长度指示器，只要它不超过 http 协议定义的最大长度，你就照着读，没错的

@abcbuzhiming 我觉得楼主可能担心客户端伪造了超长 content length

@ipwx 一段时间没数据或者 idle 很久就可以断开连接了

补充一点，仅仅两个\r\n 来进行分割，也是考虑不完全的，因为有可能对方不发这个，然后就挂了

@ipwx 超长的 content length 可以被 http 服务器的最大包长参数限制，主流的 http 服务器实现都带有这个参数，一旦超了直接 close socket

觉得楼主可以试下在已有开源的 HTTP SERVER 做修改满足需求
自己写一边太麻烦了

决定直接关闭连接，因为请求者发送的数据长度扰乱了本次连接的缓冲区管理

首先 HTTP 是基于 TCP 的
TCP 不是报文，而是流
只有坚信流式思维才能想明白这个问题

根据 content-length 来截断数据包这个思路本身就有问题吧

content-length 是用户传的（而且和其他请求一样是可以随便造的）。服务器能处理正确情况，并在出错时继续稳定运行就可。