應該在http響應內容長度中包含換行符嗎？

Question

發送HTTP響應時，我應該用換行符（行分隔符）結束響應主體（內容本身）嗎？

如果是這樣，我應該在Content-Length中包含行分隔符的大小（我猜如果發送\ r \ n增加2的計數）？

Answer 1

我沒有看到這樣的事情在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 

有一個響應兩個新行，都是在頭文件的末尾，而不是在消息體的結束。標題將描述消息體如何終止。

Answer 2

發送HTTP響應時，我應該用換行符（行分隔符）結束響應主體（ 內容本身）嗎？

RFC不要求您發送換行符。消息長度不是基於這種換行符的存在計算的。請參閱Message Length部分，其中描述瞭如何計算消息長度。

Answer 3

發送HTTP響應時，應該用換行符（行分隔符）結束響應主體（內容本身）嗎？如果是這樣，我應該在內容長度中包含行分隔符的大小（我猜如果發送\ r \ n增加2的計數）？

NO！

在HTTP響應的消息體中發送的資源數據可能包含自己的換行符（正如文本文件中常見的那樣），但就HTTP本身而言，它是任意數據。消息數據內的換行符不是HTTP響應本身的一部分。除非使用Transfer-Encoding（在這種情況下Content-Length被忽略，並且使用chunked編碼，該編碼被自我終止），否則HTTP響應終止達到Content-Length（這是資源數據的字節大小），或者連接是在迴應結束時關閉。這在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.