HTTP 메시지
1. HTTP 엔티티 바디의 역할은 리퀘스트와 리스폰스에 관한 메시지 바디를 운반하는 것이다?
땡때래땡!!! HTTP 메시지 바디의 역할은 리퀘스트와 리스폰스에 관한 엔티티 바디를 운반하는 일입니다.
메시지 바디와 엔티티 바디의 차이는 뭘까요?
메시지와 엔티티의 정의는 다음과 같습니다.
메시지: HTTP 기본 단위로 8비트 시퀀스(Octet sequence)로 구성되어 전송됨
엔티티: HTTP 리퀘스트와 리스폰스의 페이로드(부가물)로 전송되는 정보로 엔티티 헤어 필드와 엔티티 바디로 구성
기본적으로 둘은 같지만 전송 코딩(압축, 청크 등)에 의해 엔티티 바디의 내용이 변화할 수 있기 때문에 메시지 바디와 차이가 생깁니다. 즉, 인코딩 된 메시지 바디를 디코딩할 경우 비로소 엔티티 바디인 것이죠.
W3.org
2. HTTP 메시지는 복수 행(개행 문자는 LF)의 데이터로 구성된 텍스트 문자열이다?
땡땡!!! HTTP 메시지의 개행 문자는 CRLF이죠!!! 그러면 LF와 CRLF의 차이는 무엇일까요?
CR(Carriage return): 줄의 맨 앞으로 이동
LF(Line Feed): 다음 줄로 이동
추가로 HTTP의 메시지는 메시지 헤더와 메시지 바디로 구성되어 있고, 최초에 나타나는 개행 문자(CRLF)로 둘을 구분합니다.
3. HTTP 버전은 상태 라인과 리퀘스트 라인에 나타난다?🤔
맞습니다!!! HTTP 버전은 리퀘스트에서는 리퀘스트 라인에, 리스폰스에서는 상태 라인에 포함되죠!!!
4. 콘텐츠 코딩은 엔티티 정보를 유지한 채로 압축한다?
맞습니다!! 콘텐츠 코딩은 엔티티에 적용하는 인코딩을 가리키며 엔티티 정보를 유지한 채로 압축합니다.
주요 콘텐츠 압축에는 다음과 같은 것이 있습니다.
gzip(GNU zip)
compress(UNIX의 표준 압축)
deflate(zlib)
identity(인코딩 없음)
5. HTTP 전송 코딩(Transfer coding)에는 압축과 청크 전송이 정의되어 있다.
땡때래댕땡땡😭!!! HTTP/1.1에 의하면 전송 코딩(Transfer Codings)에는 청크 전송 코딩만 정의되어 있습니다. 이렇게 간단하기 때문에 널리 퍼질 수 있었던 거겠죠!!!
청크 전송 코딩은 엔티티 바디를 분할하여 전송하는 기능입니다. 엔티티 바디를 청크(덩어리)로 분해하여 다음 청크 사이즈를 16진수로 사용해서 단락을 표시하고 엔티티 바디 끝에는 0(CRLF)를 기록해둡니다.
이렇게 전송된 엔티티 바디는 수신한 클라이언트 측에서 원래의 엔티티 바디로 디코딩합니다.
6. 하나의 메시지 바디에는 하나의 엔티티만 담을 수 있다?
땡!!! HTTP의 멀티 파트는 하나의 메시지 바디 내부에 엔티티를 여러 개 포함시켜 보낼 수 있습니다. 멀티파트의 종류는 다음과 같습니다.
- multipart/form-data: 파일 업로드에 사용
- multipart/byteranges: 상태 코드 206(Partial Content) 리스폰스 메시지가 복수 범위의 내용을 포함할 때 사용
7. 레인지 리퀘스트에 대한 리스폰스는 상태 코드 200 OK이다.
땡땡땡!!! 레인지 리퀘스트에 대한 리스폰스는 상태 코드 206 Partial Content죠🕺!!!
또한, 복수 범위의 레인지 리퀘스트에 대한 리스폰스는 multipart/byteranges가 돌아옵니다.
서버가 레인지 리퀘스트에 지원하지 않는 경우에는 상태 코드 200 OK로 완전한 엔티티가 되돌아옵니다.
8. Content Negotiation 에서 각 리소스는 정렬된 순서로 중요도를 가진다?
땡땡!!! 각 리소스의 순서는 상관이 없으며 q 값(Quality Value)d에 따른 중요도를 가집니다. q 값은 0 ~ 1의 범위를 가집니다.
참고
우에노 센, 이병억 역, 그림으로 배우는 HTTP Network Basic, 영진 닷컴