http响应内容长度中应该包含换行符吗？

Question

发送 HTTP 响应时，我是否应该用换行符（行分隔符）结束响应正文（内容本身）？

如果是这样，我是否应该在 Content-Length 中包含行分隔符的大小（如果发送 \r\n，我猜想将计数增加 2）？

Answer 1

发送 HTTP 响应时，我是否应该用换行符（行分隔符）结束响应正文（内容本身）？如果是这样，我是否应该在 Content-Length 中包含行分隔符的大小（如果发送 \r\n，我猜想将计数增加 2）？

不！

在 HTTP 响应的 message-body 中发送的资源数据可能包含自己的换行符（在文本文件等中很常见），但就 HTTP 本身而言，这是任意数据被关注到。消息数据中的换行符不是 HTTP 响应本身的一部分。 HTTP响应通过到达Content-Length（即资源数据的字节大小）终止，除非使用Transfer-Encoding（在这种情况下Content-Length被忽略，并且使用chunked编码，即self -terminating)，或者连接在响应结束时关闭。这在RFC 2616 Section 4.4 中有描述：

4.4 消息长度 消息的传输长度是消息体的长度，如 它出现在消息中；也就是说，在任何传输编码具有 被应用。当消息中包含消息正文时， 该主体的传输长度由以下之一确定 （按优先顺序）： 1.任何“不得”包含消息体的响应消息（例如 作为 1xx、204 和 304 响应以及对 HEAD 的任何响应 request) 总是以第一个空行结束 头字段，无论实体头字段存在于 消息。 2.如果存在传输编码头字段（第 14.41 节）并且 具有除“identity”以外的任何值，则传输长度为 通过使用“分块”传输编码（第 3.6 节）定义， 除非通过关闭连接来终止消息。 3.如果存在 Content-Length 标头字段（第 14.13 节），则其 OCTET 中的十进制值表示实体长度和 传输长度。不得发送 Content-Length 标头字段 如果这两个长度不同（即，如果传输编码 头字段存在）。如果同时收到一条消息 Transfer-Encoding 头域和一个 Content-Length 头域， 后者必须被忽略。 4.如果消息使用媒体类型“multipart/byteranges”，并且 传输长度没有另外指定，那么这个自 定界媒体类型定义传输长度。这种媒体类型 除非发件人知道收件人可以解析，否则不得使用 它;请求中存在具有多个字节的 Range 标头- 来自 1.1 客户端的范围说明符意味着客户端可以解析 多部分/字节范围响应。 范围标头可能由不支持的 1.0 代理转发 了解多部分/字节范围；在这种情况下，服务器必须 使用第 1,3 或 5 项中定义的方法分隔消息 本节。 5.由服务器关闭连接。 （关闭连接 不能用于指示请求正文的结束，因为 不会让服务器发回响应。） 为了与 HTTP/1.0 应用程序兼容，HTTP/1.1 请求 包含消息体必须包含有效的 Content-Length 标头 字段，除非已知服务器符合 HTTP/1.1。如果一个 请求包含消息体并且没有给出 Content-Length， 如果不能，服务器应该以 400（错误请求）响应 确定消息的长度，或者使用 411（需要长度）如果 它希望坚持接收有效的内容长度。 所有接收实体的 HTTP/1.1 应用程序必须接受 “分块”传输编码（第 3.6 节），因此允许这种机制 用于无法确定消息长度时的消息 提前。 消息不能同时包含 Content-Length 头域和 非身份传输编码。如果消息确实包含非 身份传输编码，内容长度必须被忽略。 当在消息正文中给出 Content-Length 时 允许，其字段值必须与 消息体。 HTTP/1.1 用户代理必须通知用户 接收并检测到无效长度。

Answer 2

我在RFC 2616 中没有看到类似的内容：

响应 = 状态行；第 6.1 节 *(( 通用标题；第 4.5 节 |响应头；第 6.2 节 |实体头）CRLF）；第 7.1 节 CRLF [ 邮件正文 ] ;第 7.2 节

响应中有两个换行符，都在标头的末尾，而不是在消息体的末尾。标头将描述消息体是如何终止的。

Answer 3

发送 HTTP 响应时，我是否应该结束响应正文（ 内容本身）带有换行符（行分隔符）？

RFC 不要求您发送换行符。消息长度不是根据这种换行符的存在来计算的。请参阅描述如何计算消息长度的Message Length 部分。