---

Chapter 15. Entities and Encodings

(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)

---

✏️ 원문 번역

---

Rules for Determining Entity Body Length

The following rules describe how to correctly determine the length and end of an entity body in several different circumstances. The rules should be applied in order; the first match applies.

• 하단의 규칙은 다양한 상황에서 Entity Body의 길이와 종료 지점을 적절하게 결정하기 위한 방법을 설명합니다.

• 규칙은 처음 일치하는 순서대로 적용되어야 합니다.

1. If a particular HTTP message type is not allowed to have a body, ignore the Content-Length header for body calculations. The Content-Length headers are informational in this case and do not describe the actual body length. (Naïve HTTP applications can get in trouble if they assume Content-Length always means there is a body).

• HTTP 메시지가 본문을 허용하지 않는 유형이라면 Body 연산에서 Content-Length 헤더를 무시합니다.

• 이러한 경우 Content-Length 헤더는 정보를 전달하는 역할만 할 뿐 실제 Body Length를 나타내지 않습니다.

• 단순한 HTTP 응용 프로그램은 Content-Length가 있으면 항상 본문이 있다고 가정하여 문제가 발생하기도 합니다.

The most important example is the HEAD response. The HEAD method requests that a server send the headers that would have been returned by an equivalent GET request, but no body. Because a GET response would send back a Content-Length header, so will the HEAD response—but unlike the GET response, the HEAD response will not have a body. 1XX, 204, and 304 responses also can have informational Content-Length headers but no entity body. Messages that forbid entity bodies must terminate at the first empty line after the headers, regardless of which entity header fields are present.

• 가장 중요한 예시는 HEAD 응답입니다.

• HEAD 메서드는 서버가 동일한 GET 요청으로부터 반환되는 헤더를 전송하지만 본문은 포함하지 않도록 요청합니다.

• GET 응답이 Content-Length 헤더를 반환하기 때문에 HEAD 응답 또한 Content-Length를 반환합니다. 그러나 GET 응답과 달리 HEAD 응답은 본문을 포함하고 있지 않습니다.

• 1XX, 204, 304 응답은 정보 제공의 목적으로 Content-Length 헤더를 포함할 수 있지만 Entity Body는 포함하지 않습니다.

• Entity Body를 허용하지 않는 메시지는 헤더 이후에 등장하는 첫 번째 공백 라인 이후로 종료되어야 합니다.

• Entity Header 필드의 존재 여부와는 무관합니다.

2. If a message contains a Transfer-Encoding header (other than the default HTTP “identity” encoding), the entity will be terminated by a special pattern called a “zero-byte chunk,” unless the message is terminated first by closing the connection. We’ll discuss transfer encodings and chunked encodings later in this chapter.

• 메시지가 HTTP의 디폴트 "identity" 인코딩이 아닌 Transfer-Encoding 헤더를 포함하고 있다면, 연결이 종료되기 전에 메시지가 끝나지 않는 한 Entity는 "zero-byte chunk"라고 하는 특수한 패턴에 의해 종료될 것입니다.

• 전송 인코딩과 청크 인코딩에 대해서는 추후 살펴봅니다.

3. If a message has a Content-Length header (and the message type allows entity bodies), the Content-Length value contains the body length, unless there is a non-identity Transfer-Encoding header. If a message is received with both a Content-Length header field and a non-identity Transfer-Encoding header field, you must ignore the Content-Length, because the transfer encoding will change the way entity bodies are represented and transferred (and probably the number of bytes transmitted).

• 메시지가 Content-Length 헤더를 가지고 있고 Entity Body를 허용하는 유형이라면, identity Transfer-Encoding 헤더를 포함하고 있다는 가정하에 Content-Length 값이 본문의 길이를 나타냅니다.

• 메시지가 Content-Length 헤더 필드와 non-identity Transfer-Encoding 헤더 필드를 가지고 있다면 Content-Length 필드를 무시해야 합니다.

• 전송 인코딩은 Entity Body를 표현하고 전송하는 방식을 변경하기 때문입니다.

4. If the message uses the “multipart/byteranges” media type and the entity length is not otherwise specified(in the Content-Length header), each part of the multipart message will specify its own size. This multipart type is the only entity body type that self-delimit sits own size, so this media type must not be sent unless the sender knows the recipient can parse it.

• 메시지가 "multipart/byteranges" 미디어 유형을 사용하고 Content-Length 헤더 내에 엔티티의 길이가 달리 정의되지 않았다면, multipart 메시지의 각 요소가 자체 크기로 지정될 것입니다.

• multipart 타입은 자체적으로 크기를 설정할 수 있는 유일한 Entity Body 타입입니다.

• 따라서 수신자가 파싱할 수 있다는 사실을 알지 못하는 경우 multipart를 전송해서는 안 됩니다.

5. If none of the above rules match, the entity ends when the connection closes. In practice, only servers can use connection close to indicate the end of a message. Clients can’t close the connection to signal the end of client messages, because that would leave no way for the server to send back a response.

• 위의 규칙 중 어느 것에도 해당하지 않는다면, 엔티티는 연결 종료와 함께 종료됩니다.

• 실제로는 서버만이 연결을 종료하여 메시지의 끝을 나타낼 수 있습니다.

• 클라이언트는 클라이언트 메시지의 끝을 알리기 위해 연결을 종료할 수 없습니다.

• 클라이언트가 연결을 닫아버리는 경우 서버가 응답을 전송할 방법이 존재하지 않기 때문입니다.

6. To be compatible with HTTP/1.0 applications, any HTTP/1.1 request that has an entity body also must include a valid Content-Length header field (unless the server is known to be HTTP/1.1-compliant). The HTTP/1.1 specification counsels that if a request contains a body and no Content-Length, the server should send a 400 Bad Request response if it cannot determine the length of the message, or a 411 Length Required response if it wants to insist on receiving a valid Content-Length.

• HTTP/1.0 응용 프로그램과의 호환성을 위해 모든 Entity Body를 포함한HTTP/1.1 요청은 유효한 Content-Length 헤더 필드를 포함해야 합니다.

• HTTP/1.1 명세에서는 요청이 Body를 포함하고 Content-Length를 포함하지 않은 경우, 메시지의 길이를 결정할 수 없다면 서버가 400 Bad Request 응답을 반환해야 한다고 언급합니다.

• 만약 유효한 Content-Length를 수신해야 하는 경우라면 411 Length Required 응답을 반환해야 합니다.

---

Entity Digests

Although HTTP typically is implemented over a reliable transport protocol such as TCP/IP, parts of messages may get modified in transit for a variety of reasons, such as noncompliant transcoding proxies or buggy intermediary proxies. To detect unintended (or undesired) modification of entity body data, the sender can generate a checksum of the data when the initial entity is generated, and the receiver can sanity check the checksum to catch any unintended entity modification.

• 통상 HTTP는 TCP/IP와 같이 신뢰할 수 있는 전송 프로토콜 위에 구현되어 있지만, 전송 과정에서 다양한 이유로 메시지가 변조될 수 있습니다.

• 규정을 준수하지 않는 트랜스코딩 프록시나 버그가 있는 중간 프록시가 있는 경우가 그 예시입니다.

• 의도치않은 Entity Body 데이터의 변조 여부를 확인하기 위해 송신자는 처음 엔티티를 생성할 때 데이터에 대한 체크섬을 함께 생성하여 수신자가 무결성 검사를 수행할 수 있도록 합니다.

The Content-MD5 header is used by servers to send the result of running the MD5 algorithm on the entity body. Only the server where the response originates may compute and send the Content-MD5 header. Intermediate proxies and caches may not modify or add the header—that would violate the whole purpose of verifying end-to-end integrity. The Content-MD5 header contains the MD5 of the content after all content encodings have been applied to the entity body and before any transfer encodings have been applied to it. Clients seeking to verify the integrity of the message must first decode the transfer encodings, then compute the MD5 of the resulting unencoded entity body. As an example, if a document is compressed using the gzip algorithm, then sent with chunked encoding, the MD5 algorithm is run on the full gripped body.

• 서버가 사용하는 Content-MD5 헤더는 Entity Body에 대한 MD5 알고리즘의 수행 결과를 전송합니다.

• 응답이 시작된 서버에서만 Content-MD5 헤더를 연산하고 전송할 수 있습니다.

• Content-MD5 헤더는 Entity Body에 대한 모든 인코딩이 적용된 후, 전송 인코딩이 적용되기 전의 콘텐츠에 관한 MD5를 포함합니다.

• 메시지의 무결성을 검증하려 하는 클라이언트는 전송 인코딩을 먼저 디코딩한 후 아직 복호화 되지 않은 엔티티 본문에 대해 MD5를 연산해야 합니다.

• 예를 들어 문서가 gzip 알고리즘에 의해 압축되어 청크 인코딩으로 전송되었다면, MD5 알고리즘은 전체 본문에 대해 수행되어야 합니다.

In addition to checking message integrity, the MD5 can be used as a key into a hash table to quickly locate documents and reduce duplicate storage of content. Despite these possible uses, the Content-MD5 header is not sent often.

• MD5는 메시지 무결성 검사와 더불어 해시 테이블의 키 값으로 사용되어 문서를 빠르게 조회하고 콘텐츠 저장소의 복제를 줄일 수 있습니다.

• 다양한 쓰임새에도 불구하고 Content-MD5 헤더는 그리 자주 전송되지 않고 있습니다.

Extensions to HTTP have proposed other digest algorithms in IETF drafts. These extensions have proposed a new header, Want-Digest, that allows clients to specify the type of digest they expect with the response. Quality values can be used to suggest multiple digest algorithms and indicate preference.

• HTTP의 확장은 IETF 초안에서 또다른 Digest 알고리즘을 제안합니다.

• 새로운 헤더인 Want-Digest를 사용하여 클라이언트가 응답으로 예상하는 digest의 유형을 명시할 수 있게 합니다.

• 여러 개의 digest 알고리즘을 제안하고 속성을 표현하기 위해 Quality 값이 사용될 수 있습니다.

---

✏️ 요약

---

Entity Body Length를 결정하는 방법

1. HTTP 메시지가 본문을 허용하는 유형인지 확인

• 허용하지 않는 유형이라면 Content-Length 헤더 무시
• 허용하는 유형이라면 2로 분기

2. non-identity Transfer-Encoding 헤더를 포함하는지 확인

• 포함하고 있다면 zero-byte chunk에 의해 종료되고 있는지 확인
• 포함하지 않는다면 3으로 분기

3. Content-Length 헤더 해석

• Content-Length 필드를 Entity Body의 길이로 해석
• Content-Length가 달리 정의되지 않았다면 4로 분기

4. multipart/byteranges 미디어 타입인지 확인

• multipart는 자체적으로 크기 설정 가능
• multipart/byteranges 가 아니라면 5로 분기

5. 연결 종료 시점에 Entity가 종료된다고 해석

---

Entity Digests

: 전송 과정에서 Entity Body의 무결성을 검증하기 위한 요소

• Server : Entity Body 인코딩 적용 > MD5 계산 > 전송 인코딩 적용 > Content-MD5에 digest를 담아서 송신
• Client : 수신 > 전송 인코딩 해제 > MD5 계산 후 digest 확인 > Entity Body 디코딩