发送HTTP响应时，是否应该使用换行符（行分隔符）结束响应正文（内容本身）？
如果是这样的话，我应该在内容长度中包含行分隔符的大小（我想在发送\ r \ n时增加2的计数）吗？
答案 0 :(得分：5)
发送HTTP响应时，是否应该使用换行符（行分隔符）结束响应正文（内容本身）？如果是这样的话，我应该在内容长度中包含行分隔符的大小（我想在发送\ r \ n时增加2的计数）吗？
否！
在HTTP响应的 message-body 中发送的资源数据可能包含自己的换行符（在文本文件中很常见等），但就HTTP本身而言，这是任意数据被关注到。消息数据中的换行符不是HTTP响应本身的一部分。除非使用Content-Length（在这种情况下忽略Transfer-Encoding，并且Content-Length，否则通过达到chunked（资源数据的字节大小）来终止HTTP响应使用编码，它是自终止的），或者在响应结束时关闭连接。这在RFC 2616 Section 4.4：
4.4 Message Length
The transfer-length of a message is the length of the message-body as
it appears in the message; that is, after any transfer-codings have
been applied. When a message-body is included with a message, the
transfer-length of that body is determined by one of the following
(in order of precedence):
1.Any response message which "MUST NOT" include a message-body (such
as the 1xx, 204, and 304 responses and any response to a HEAD
request) is always terminated by the first empty line after the
header fields, regardless of the entity-header fields present in
the message.
2.If a Transfer-Encoding header field (section 14.41) is present and
has any value other than "identity", then the transfer-length is
defined by use of the "chunked" transfer-coding (section 3.6),
unless the message is terminated by closing the connection.
3.If a Content-Length header field (section 14.13) is present, its
decimal value in OCTETs represents both the entity-length and the
transfer-length. The Content-Length header field MUST NOT be sent
if these two lengths are different (i.e., if a Transfer-Encoding
header field is present). If a message is received with both a
Transfer-Encoding header field and a Content-Length header field,
the latter MUST be ignored.
4.If the message uses the media type "multipart/byteranges", and the
transfer-length is not otherwise specified, then this self-
delimiting media type defines the transfer-length. This media type
MUST NOT be used unless the sender knows that the recipient can parse
it; the presence in a request of a Range header with multiple byte-
range specifiers from a 1.1 client implies that the client can parse
multipart/byteranges responses.
A range header might be forwarded by a 1.0 proxy that does not
understand multipart/byteranges; in this case the server MUST
delimit the message using methods defined in items 1,3 or 5 of
this section.
5.By the server closing the connection. (Closing the connection
cannot be used to indicate the end of a request body, since that
would leave no possibility for the server to send back a response.)
For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
containing a message-body MUST include a valid Content-Length header
field unless the server is known to be HTTP/1.1 compliant. If a
request contains a message-body and a Content-Length is not given,
the server SHOULD respond with 400 (bad request) if it cannot
determine the length of the message, or with 411 (length required) if
it wishes to insist on receiving a valid Content-Length.
All HTTP/1.1 applications that receive entities MUST accept the
"chunked" transfer-coding (section 3.6), thus allowing this mechanism
to be used for messages when the message length cannot be determined
in advance.
Messages MUST NOT include both a Content-Length header field and a
non-identity transfer-coding. If the message does include a non-
identity transfer-coding, the Content-Length MUST be ignored.
When a Content-Length is given in a message where a message-body is
allowed, its field value MUST exactly match the number of OCTETs in
the message-body. HTTP/1.1 user agents MUST notify the user when an
invalid length is received and detected.
答案 1 :(得分：2)
我在RFC 2616中看不到这样的内容：
Response = Status-Line ; Section 6.1
*(( general-header ; Section 4.5
| response-header ; Section 6.2
| entity-header ) CRLF) ; Section 7.1
CRLF
[ message-body ] ; Section 7.2
响应中有两个换行符，都位于标题的末尾，而不是在消息正文的末尾。标题将描述邮件正文的终止方式。
答案 2 :(得分：0)
发送HTTP响应时，我应该结束响应主体（ 内容本身）换行（行分隔符）？
RFC不要求您发送换行符。不基于这种换行的存在来计算消息长度。请参阅Message Length部分，其中介绍了如何计算邮件长度。