有人能告诉我内容长度或传输编码：“分块”是Http请求的必要条件吗？我正在使用c编写超文本传输协议服务器。
超文本传输协议响应可以使用关闭套接字来知道消息体的长度。但是请求呢？
我已经检查了关于超文本传输协议1.1的RFC2616，但我对此不够清楚。
我的问题是，如果发送的超文本传输协议请求没有“Content-Llong”或“分块传输编码”，我如何使用“WSARecv”来知道消息体的长度，对于我使用WSARecv并获得所有标头和网络流以“\r\n\r\n”结尾的情况，我无法获得消息体的长度。如果我再次传递WSARecv，它可能会永远等待，因为没有更多的数据。如果我不再次传递“WSARecv”，如果有的话，我可能无法获得消息体。
或者"Content-Llong"和"chunked transport-编码"是超文本传输协议请求必须的？客户端应该设置其中一个来告诉服务器消息的长度？
如果您没有指定Transtrans-Encode或Content-Llong，则请求（或响应）隐式地是可变长度请求/响应，并且发出主体结束信号的唯一方法是关闭连接（相反地检测接收器中的关闭/eof）。
这意味着这种请求/响应也是隐式的Connection： close
如果您正在实现HTTP1.1，那么您必须支持所有三种传输方法。
当我编写我的HTTP服务器时，我从“连接流”的概念中抽象出了“请求流”的概念。“请求流”是多态的，支持读取“EOF”的概念。没有理由你不能在那里也有一个方法来“read_chunk”。在非分块请求的情况下，这可以简单地读取，直到EOF。
这允许我在同一个连接上实现多个请求的同时执行（但是有一些jiggry-pokery来确保响应以正确的顺序返回！）
RFC2616已过时。
答案就在https://greenbytes.de/tech/webdav/rfc7230.html#header.content-length.
