Http请求必须使用“Content-Length”还是“chunked transfer-encoding”？答案

【问题标题】：Is "Content-Length" or "chunked transfer-encoding" a must for Http request?Http请求必须使用“Content-Length”还是“chunked transfer-encoding”？
【发布时间】：2016-07-06 08:15:59
【问题描述】：

有人可以告诉我关于 Content-Length 或 Transfer-Encoding：“Chunked”是 Http 请求的必要条件吗？我正在使用c++编写一个http服务器。

http响应可以使用close socket来知道消息体的长度。但是请求呢？

我已经检查了关于 http 1.1 的 RFC2616，但我对此还不够清楚。

我的问题是，如果发送的 http 请求没有“Content-Length”或“Chunked Transfer-Encoding”，我如何使用“WSARecv”来知道消息体的长度，对于我使用 WSARecv 并获取所有信息的情况巧合的是，标头和网络流以“\r\n\r\n”结尾，我无法获得消息正文的长度。如果我再次发送 WSARecv，它可能会永远等待，因为没有更多数据了。如果我不再发送“WSARecv”，如果有的话，我可能无法获得消息正文。

或者也许“Content-Length”和“chunked transfer-encoding”对于http请求是必须的？客户端应该设置其中一个来告诉服务器消息的长度？

【问题讨论】：

标题末尾的空白行没有任何“巧合”。它在 HTTP RFC 中指定。
您是否考虑过使用诸如 libmicrohttp 之类的库来为您完成大部分繁重的工作？

标签： c++ http

【解决方案1】：

如果您没有指定Transfer-Encoding 或Content-Length，则请求（或响应）隐含可变长度请求/响应，并且发出正文结束信号的唯一方法是关闭连接（并且反过来检测接收器中的关闭/eof）。

这意味着这种请求/响应也隐含Connection: close

如果您要实现 HTTP1.1，那么您必须支持所有三种传输方法。

当我编写 HTTP 服务器时，我从“连接流”的概念中抽象出了“请求流”的概念。 “请求流”是多态的，支持读取到“EOF”的概念。没有理由你不能在那里有一个“read_chunk”的方法。在非分块请求的情况下，这可以简单地读取到 EOF。

这让我可以在同一个连接上同时执行多个请求（但是有一些诡计可以确保响应以正确的顺序返回！）

【讨论】：

我读请求直到 EOF ？你的意思是读（recv？）返回0？在我发回响应之前它不应该读取 return 0 ......
@NeoLiu 您可以在消耗完所有标题后开始响应。但是是的，使用套接字，读取长度为零且没有错误代码意味着 eof（即发送者称为 shutdown(send)）

【解决方案2】：

RFC 2616 已过时。

答案在https://greenbytes.de/tech/webdav/rfc7230.html#header.content-length。

【讨论】：