http 응답 내용 길이에 개행을 포함해야합니까?

Question

HTTP 응답을 보내는 경우 줄 바꿈 (줄 구분 기호)을 사용하여 응답 본문 (내용 자체)을 결론 지어야합니까?

그렇다면 내용 길이에 줄 구분 기호의 크기를 포함시켜야합니까? (예 : \ 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

응답 본문 ( 내용 자체)을 개행 (줄 구분 기호)으로 결론 짓어야합니까?

RFC에는 개행 문자를 보내지 않아도됩니다. 메시지 길이는 이러한 개행 문자의 존재 여부에 따라 계산되지 않습니다. 메시지 길이 계산 방법을 설명하는 Message Length 섹션을 참조하십시오.

Answer 3

HTTP 응답을 보낼 때 줄 바꿈 문자 (줄 구분 기호)로 응답 본문 (내용 자체)을 결론 짓어야합니까? 그리고 만약 그렇다면, 필자는 Content-Length에서 줄 구분 기호 (\ 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.