Http 邮件正文后是否有CRLF？

我不知道在发送完正文的所有字节后，我是否应该发送下一条消息，而不使用CRLF将第一条消息的正文分隔到第二条消息的起始行

这是符合RFC 7230的语法：

 HTTP-message   = start-line
                  *( header-field CRLF )
                  CRLF
                  [ message-body ]

根据语法，正文末尾没有CRLF，但看起来很奇怪，因为其他所有内容似乎都被CRLF分隔开，特别是对于分块正文的语法

 chunk          = chunk-size [ chunk-ext ] CRLF
                  chunk-data CRLF

这就是没有CRLF的情况

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 3

abcHTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 3

这就是它的样子

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 3

abc
HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 3

abc

---

那么，CRLF是否应该跟在正文后面？

否，当存在内容长度，并且未使用分块传输编码时，正文的长度正好是由内容长度定义的长度

然后必须将其包含在消息正文中：

:

HTTP/1.1用户代理程序不能为 或者根据请求添加额外的CRLF。如果终止请求 如果需要以行结尾的消息正文，则用户代理必须 将终止的CRLF八位字节计数为消息正文长度的一部分

---

我知道CRLF不应该在主体内，我在问您是否可以在主体后添加一个。HTTP消息以主体的最后一个字节结束。您多久“查看”一次HTTP服务器和浏览器之间的keepalive流？因为这是唯一一次“看到”两条连接的HTTP消息，浏览器和服务器可以很好地理解语法。为什么要在它们之间添加换行符？使用CRLF对我来说更容易阅读。