주제
Q 1 : “HTTP 헤더 용도?“
Q 2 : “과거의 HTTP 헤더와 HTTP 바디?“
Q 3 : “현재의 HTTP 표준의 변화?”
Q 4 : “HTTP 표준의 표현(Representation)?”
Q 5 : “콘텐츠 협상(클라이언트가 선호하는 표현 요청)?“
Q 6 : “전송방식(단순 전송, 압축 전송, 분할 전송, 범위 전송)?“
HTTP 헤더 | 용도 |
---|---|
HTTP 헤더 용도 | Start-Line을 제외한 HTTP 전송에 필요한 모든 부가 정보를 담는다. |
예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등 | |
표준 헤더가 많다. | |
필요시 임의의 헤더 추가 가능하다. |
과거의 HTTP 헤더 | 설명 |
---|---|
General 헤더 | 메시지 전체에 적용되는 정보 |
예) Connection: close | |
Request 헤더 | 요청 정보 |
예) User-Agent: Mozilla/5.0 | |
Response 헤더 | 응답 정보 |
예) Server: Apache | |
Entity 헤더 | 엔티티 바디 정보 |
예) Content-Type: text/html | |
예) Content-Length: 3423 |
과거의 HTTP 바디 | 설명 |
---|---|
메시지 본문(message body) | 엔티티 본문(entity body)을 전달하는데 사용 |
엔티티 본문 | 요청이나 응답에서 전달할 실제 데이터 |
엔티티 헤더 | 엔티티 본문의 데이터를 해석할 수 있는 정보 제공 |
데이터 유형(html, json), 데이터 길이, 압축 정보 등등 |
HTTP 표준의 변화 | 설명 |
---|---|
HTTP 표준의 변화 | 1999년 : RFC2616(폐기 됨) |
2014년 : RFC7230 ~ 7235 등장 | |
RFC723x 변화 | 엔티티(Entity) → 표현(Representation) |
Representation = representation Metadata + Representation Data | |
표현 = 표현 메타데이터 + 표현 데이터 | |
HTTP HEADER RFC7230(최신) | 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다. |
HTTP BODY RFC7230(최신) | 메시지 본문을 통해 표현 데이터 전달한다. |
메시지 본분 = 페이로드(Payload) | |
표현은 요청이나 응답에서 전달할 실제 데이터 |
*표현 헤더는 표현 메타데이터와 페이로드 메시지를 구분해야 하지만 여기서는 생략한다.
HTTP 표준의 표현(Representaation) : 표현 헤더는 전송과 응답 둘다 사용이 가능하다.
HTTP 표준의 표현(Representaation) | 설명 |
---|---|
Content-Type 표현 데이터의 형식(그림5) | 미디어 타입 & 문자 인코딩 |
1) text/html; 2) charset=utf-8 | |
3) application/json 4) image/png | |
Content-Encoding 표현 데이터의 압축 방식(그림6) | 표현 데이터를 압축하기 위해 사용 |
데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가 | |
데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제 | |
1) gizp, 2) deflate, 3) identity(압축 안함) | |
Content-Language 표현 데이터의 자연 언어(그림7) | 표현 데이터의 자연 언어를 표현 |
1) ko, 2) en, 3) en-US | |
Content-Length 표현 데이터의 길이(그림8) | 바이트 단위 |
Transfer-Encoding(전송 코딩)을 사용하면 Content-Length를 사용하면 안 됨. |
콘텐츠 협상(Content Negotiation) : 협상 헤더는 요청시에만 사용한다.
콘텐츠 협상(Content Negotiation) | 설명 |
---|---|
Accept | 클라이언트가 선호하는 미디어 타입 전달 |
Accept-Charset | 클라이언트가 선호하는 문자 인코딩 |
Accept-Encoding | 클라이언트가 선호하는 압축 인코딩 |
Accept-Language | 클라이언트가 선호하는 자연 언어 |
<그림10>처럼 클라이언트의 요청은 한국어지만 ‘다중 언어 지원 서버’의 응답 헤더는 기본이 독일어고 영어를 지원한다면? 이때 바로 협상과 우선순위가 필요하다.
클라이언트가 선호하는 자연 언어 | 설명 |
---|---|
협상과 우선순위(Quality Values(q) | Quality Values(q) 값을 사용한다. |
0~1, 클수록 높은 우선순위 | |
생략하면 1 | |
Accept-Language | ko-KR,ko;q=0.9, en-US;q=0.8,en;q=0.7(그림11) |
ko-KR;q=1 (q생략) | |
ko;q=0.9 | |
en-US;q=0.8 | |
en:q=0.7 |
클라이언트가 선호하는 미디어 타입 | 설명 |
---|---|
Accept | text/, text/plain, text/plain;format=flowed, /* |
1) text/plain;format=flowed 2) text/plain | |
3) text/ 4) / * |
참고 자료
김영한 인프런 강의 : 모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의