新行应该包含在http响应内容长度中吗？ [英] Should newline be included in http response content length?

问题描述

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

When sending a HTTP Response, should I conclude the response body (the content itself) with a newline (line separator)?

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

And if so, should I include the size of the line separator (I guess increase the count with 2 if sending \r\n) in the Content-Length?

推荐答案

发送HTTP响应时，是否应该使用换行符（行分隔符）结束响应正文（内容本身）？如果是这样的话，我应该在内容长度中包括行分隔符的大小（我想在发送\\\ n时增加2来计算）？

When sending a HTTP Response, should I conclude the response body (the content itself) with a newline (line separator)? And if so, should I include the size of the line separator (I guess increase the count with 2 if sending \r\n) in the Content-Length?

否！

HTTP响应的消息正文中发送的资源数据可能包含自己的换行符（如文本文件中常见的那样），但就HTTP本身而言，这是任意数据。消息数据中的换行符不是HTTP响应本身的一部分。通过达到 Content-Length （这是资源数据的字节大小）来终止HTTP响应，除非 Transfer-Encoding （在这种情况下忽略 Content-Length ，并使用 chunked 编码，这是自我 - 终止），或者在响应结束时关闭连接。 RFC 2616第4.4节中对此进行了描述：

The resource data that is being sent in the HTTP response's message-body may include its own newlines (as is common in text files, etc), but that is arbitrary data as far as HTTP itself is concerned. Newlines inside the message-data are NOT part of the HTTP response itself. The HTTP response is terminated by reaching the Content-Length (which is the byte size of the resource data) unless Transfer-Encoding is used (in which case Content-Length is ignored, and the chunked encoding is used, which is self-terminating), or the connection is closed at the end of the response. This is described in 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.

这篇关于新行应该包含在http响应内容长度中吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！