18. Entity & Encoding

2022 우아한스터디 "HTTP 완벽가이드"를 진행하면서

'HTTP 완벽 가이드' 책을 읽고, 글쓴이의 생각을 정리하는 글 입니다.

https://book.naver.com/bookdb/book_detail.nhn?bid=8509980 

HTTP 완벽 가이드

1. Entity와 HTTP

HTTP Message는, 크게 나누면 Message Header와 Engity로 나뉘게 됩니다.

 

아래 HTTP Message 예시로 보시죠

HTTP/1.0 200 OK                          <---- HTTP의 버전, 상태, 상태코드 
Server : Netscape-Enterprise/3.6         <-+-- HTTP Message Header
Date: Sun, 17 Sep 2000 00:01:05 GMT      <-┛
Content-type : text/plain                <-+-- Entity Header <----+-- Entity
content-length : 18                      <-┛                     |
                                                                  |
Hi! Hello HTTP                           <---- Entity Data   <----┛

기존에는 Header와 본문으로 HTTP Message를 나눴지만, Header 내에서도 HTTP Message에 대한 Header와

 

Entity에 대한 Header를 별도로 나눈것을 볼 수 있습니다.

 

이때, HTTP Message는 Entity를 나르는 포장박스 역할을 하고, Entity가 사실상 본체라고 보시면 되겠습니다.

 

2. Entity

Entity는 Entity Header와 Entity Data 부분으로 나뉘게 됩니다.

 

Entity Header들의 Content-** 형태 이거나, Last-Modified, Expires, Allow, ETag, Cache-Contorol과 같은 데이터 캐싱과 관련있는 Header가 대상입니다.

 

Entity Data의 경우 다양한 Data가 Content-type에 맞게 HTTP Message에 추가됩니다. 이때, 별도의 압축이 없다면 UTF-8 Encoding 후에 TCP/IP로 전송되게 되죠.

 

2_1. Entity Header : Content-Length

이때, Entity Header인 Content-Length를 반드시 포함해야 합니다.(Chunk Encoding은 제외)

 

잘 생각해 봅시다. 예전 포스팅에서, HTTP는 핸드쉐이크 과정의 지연을 방지하기 위해서

keep-alive/지속커넥션 을 사용한다고 하였습니다

5. 커넥션 관리(2편) (tistory.com)

5. 커넥션 관리(2편)

이때, 지속 커넥션 도중에는 계속해서 HTTP Message가 들어오고, Server는 이 메세지간를 나누어서 처리해야 합니다.

 

하지만 Content-Length가 없다?--> 메세지를 나누지 못하게 됩니다.

 

이러한 Content-Length는 압축 유무에 따라 값을 정해줘야 합니다.

압축이 된 경우 : 압축(Encoding) 후의 본문의 크기를 기반으로 설정
압축이 안된 경우 : Entity Body를 기반으로 설정

 

2_2. Entity Digest

Entity를 TCP/IP 로 보낸다 하더라도, 전송한 데이터가 중간에 문제가 발생할 수 있습니다.

 

이를 방지하기 위해서 Entity를 Digest한 Check Sum을 Entity Header에 추가해서 보냅니다.

 

Content-MD5와 같은 형식이며, Digect한 결과의 Check Sum을 값으로 갖게 됩니다.

 

그러면, HTTP Message를 수신한 쪽에서 수신한 Entity의 Check Sum과, Content-MD5의 값을 비교하여

 

정상적으로 Data가 수신 되었는지를 체크할 수 있게 됩니다.

 

2_3. 미디어 타입 과 Charset

Content-Type헤더에 해당하는 내용 입니다.

 

결국, HTTP Message를 통해서 보낸 Entity는 Binary 형태로 전송이 되고, 이 전송된 Data를 어떤 식으로 활용해야하는지를 나타내는 header입니다.

 

이 Header가 MIME Type을 나타낸다고 할 수 있습니다.

MIME 타입 - HTTP | MDN (mozilla.org)

MIME 타입 - HTTP | MDN

 

결국, Reponse로 받은 결과를 Client쪽에 어떻게 활용할 지를 알려주기 위한 Header라고 이해하면 편합니다

 

Application을 MIME Type으로 설정할 경우, 인터넷 브라우저에서는 해당 Response의 결과를 Local File로 다운로드 하게 된다고 보시면 됩니다.(=MIME Type에 따라 인터넷 브라우저가 적절한 처리를 합니다)

 

2_4. Multipart 요청

form를 한개 이상 보낼 때, 각 form을 서로다른 HTTP Message로 보내는 것이 아니라, Content-Type을 Multipart로 설정하고, Part를 나누는 구분자를 설정해서 보내게 됩니다.

 

아래 예시를 보시면 이해가 빠를 것 같습니다.

<form action="http://server.com/cgi/handle"
enctypes = "multipart/form-data"
method = "post">
name : <inpu type = "text" name = "sub_name">
file : <inpu type = "file" name = "sub_file">
<input type = "sumit" value = "Send">
</form>
↓
|
|
↓
/*HTTP Message*/
Content-Type : multipart/form-data ; boundary = AaB03x
--AaB03x
Content-Disposition : form-data ; name = "sub_name"
Sally
--AaB03x
Content-Disposition : form-data ; name = "sub_file"; filename = "sample.txt"
content-Type : text/plain
...content of sample.txt
--AaB03x--

위 예시처럼, 두가지 이상의 내용이 하나의 HTTP Message에 전달되기 위해서, boundary를 나타낼 문자열을 명시하고, 이 문자열 기준으로 내용을 나눠서 요청을 보내게 됩니다.