참고
HTTP 헤더 개요
NOTE
메시지 바디의 내용, 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등이 포함된다.
(좌) REQUET, (우) RESPONSE
HTTP 헤더 분류 - RFC 723x(현재)
HTTP 전송에 필요한 모든 부가정보가 들어간다 생각하면 된다.
HTTP 헤더 RFC2616(과거)
NOTE
•
General 헤더
◦
요청/응답 메시지 전체에 적용되는 정보 (e.g. Connecion: close)
•
Request 헤더
◦
요청 정보
•
Response 헤더
◦
응답 정보
•
Entity 헤더
◦
Entity 바디 정보
HTTP 바디 RFC2616(과거)
NOTE
메시지 본문(message body)을 통해 엔티티 본문(entity body)를 전달
•
엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보 제공
◦
ex) 데이터 유형(html, json), 데이터 길이, 압축 정보 등
HTTP 바디 RFC7230(최신, Entity → Representation)
NOTE
메시지 본문(message body)을 통해 표현 데이터 전달
•
표현
◦
요청이나 응답에서 전달할 실제 데이터(표현 헤더 + 표현 데이터)
•
표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공
표현(Representation)
NOTE
HTTP로 전송할 때, 어떠한 리소스를 html/json 등으로 표현해 전달 함
•
표현 헤더
◦
Content-Type : 표현 데이터의 형식
◦
Content-Encoding : 표현 데이터의 압축 방식
◦
Content-Language : 표현 데이터의 자연 언어
◦
Content-Length : 표현 데이터의 길이
Content-Type
NOTE
표현 데이터의 형식 설명 ( 미디어 타입, 문자 인코딩 )
text/html; charset=uft-8
application/json (json은 기본이 uth-8)
Content-Encoding
NOTE
표현 데이터 압축을 위해 사용한다!
gzip을 이용해서 압축해서 보낸다,
•
인코딩 종류
◦
gzip
◦
deflate
◦
identity - 압축 x
•
데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
•
데이터를 읽는 곳에서 인코딩 헤더의 정보로 압축해제
Content-Language
NOTE
클라이언트에서 언어를 선택하는 부가 작업 (애플 홈페이지 한국어로 보기)
ko (한국어)
en (영어)
Content-Length
NOTE
표현 데이터의 길이
Transfer-Encoding(전송 코딩)을 사용하면 Content-Length 사용X
질문 정리
Q. RFC2616(과거) -> RFC723x(현재)로 HTTP 표준이 변하면서 기존 분류체계의 Entity 헤더가 Representation 헤더로 바뀐 것인가요? 그럼 기존 분류체계에 있던 General, Request, Respone 헤더는 사라진게 아닌가요?
1.
실제로는 더 복잡하지만, 기존 분류체계에서 Entity → Representation으로 바뀐것으로
이해해도 된다. (실제로 Representation은 좀 더 Body 데이터에 맞도록 변경되었다)
2.
General 헤더, Representation 헤더는 공통이고 Request 헤더는 요청시에만, Response 헤더는 응답시에만 사용됨
Q. 표현 헤더에 들어가는 데이터들은 서버/클라이언트에서 전부 직접 값을 지정해줘야하는 건가요? 아니면 프레임워크나 브라우저 단에서 자동으로 처리해주는 건가요?
•
웹 브라우저에서 HTML을 처리하는 경우에는 클라이언트/서버 모두 어느정도 자동화되어 있다. 그/외 API를 호출하는 경우, 최근에 많은 부분이 자동화됨