기본 포멧
header-field = field-name":"OWS field-value
OWS : 띄어쓰기 허용
- field-name 은 대소문자 구분 없다.
ex)
Host: www.google.com
Content-Type: text/html;charset=UTF-8
Content-Length: 333
용도
- HTTP 전송에 필요한 모든 부가 정보
- 메세지 바디의 내용, 바디의 크기, 압축, 인증 등 내용이 엄청 많음
분류 - RFC(2616) : 과거
- General 헤더 : 메세지 전체에 적용되는 정보를 나타냄
- Request 헤더 : 요청 정보를 나타냄
- Response 헤더 : 응답 정보 ex) Server: Apache
- Entity 헤더 : 엔티티 바디 정보 ex) Content-Type: text/html, Content-Length: 333
- HTTP BODY
- 메시지 본문은 엔티티 본문을 전달하는데 사용
- 메시지 본문 안에 엔티티 본문을 담은 것이다.
- 엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보를 제공하는 역할을 한다.
- ex) 데이터 유형(html, json), 데이터 길이, 압축 정보 등등
2014 년 RFC 7230 ~ 7235 등장
- 엔티티가 표현으로 바뀜(Representation)
- 왜 표현이라고 할까 ? 회원이라는 리소스를 html 로 표현한거 , 또는 회원이라는 리소스를 실제 데이터로 전송할 때에는 html 이나 json 으로 표현해서 전달할 수도 있으니까 전달하는 것 자체를 표현이라고 정의를 하게 됨.
- 표현 = 표현의 메타데이터 + 표현 데이터
최신 스펙
- 메시지 본문을 통해 표현 데이터 전달
- 메세지 본문 = 페이로드(payload)
- 표현은 요청이나 응답에서 전달할 실제 데이터
- 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공
- 참고 : 표현 헤더는 표현 메타데이터와 페이로드 메세지를 구분해야 하지만, 별도로 하진 않음.
표현과 관련된 헤더들
- 회원이라는 리소스를 html , json 형태의 표현으로 전달할 거야. 라는 정보를 담고 있다.
- Content-Type : 표현 데이터의 형식
- 미디어 타입, 문자 인코딩
- ex)
- text/html; charset=utf-8
- application/json (default : utf-8)
- image/png
- Content-Encoding : 표현 데이터의 압축 방식
- 표현 데이터를 압축하기 위해 사용
- 데이터를 전달하는 곳에서 압축 후 인코딩 헤더를 추가함.
- 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제
- ex)
- gzip
- deflate
- identity ( 압축 안한다, 동일하다 )
- Content-Language : 표현 데이터의 자연 언어
본문에는 한국어가, 영어가 들어있구나. 이런걸 알 수 있음.
- Content-Length : 표현 데이터의 길이
- 바이트 단위 이다.
- Transfer-Encoding(전송 코딩) 이라는 게 있는데, 이걸 사용하면 Content-Length 를 사용하면 안된다. 전송 코딩 안에 정보가 다 포함되어 있기 때문.
- 표현 헤더는 요청과 응답 둘다 사용이 가능하다.
협상
... TODO