HTTP 헤더 개요 

HTTP 헤더는 양이 많다. 크게 '일반 헤더'와 '캐시와 조건부 요청 관련 헤더'로 분류했다. 

이번 시간은 헤더의 모양, 용도, 스펙에 따른 변화를 알아보자. 

HTTP 헤더의 모양 

헤더필드 

필드이름:필드값 

필드 이름은 대소문자 구분이 없다. 필드값은 띄어 쓰기를 허용한다. 

HTTP 메시지 

스타트 라인 다음에 헤더 내용이 오고, 다음에 메시지 바디가 온다. 

헤더의 용도

HTTP 전송에 필요한 모든 부가정보. 

표준 헤더 내용이 매우 많다. 필요 시 임의의 헤더 필드를 추가할 수 있다. 

 

RFC 2616 과거의 헤더와 메시지 바디

과거의 헤더 분류는 아래와 같이 4가지다. 

General 헤더, Request 헤더, Response 헤더, Entity 헤더 

 

과거의 메시지 바디란? 

메시지 본문은 Entity 본문을 전달하는데 사용한다. 

Entity 본문은 요청이나 응답에서 전달할 실제 데이터를 의미한다. 

Entity 헤더는 Entity 본문의 데이터를 해석할 수 있는 정보를 제공한다. 

Entity 를 안쓰고, 표현(Representation) 이라는 용어를 쓰기 시작 

표현 = 표현 메타데이터 + 표현 데이터 

1991년 RFC 2616이 폐기되고, 2015년 RFC7230~7235가 나오면서 많이 변경됬다. 

RFC 7280(최신) 메시지 본문 

메시지 본문(== payload)을 통해 표현 데이터를 전달한다. 

표현은 요청이나 응답에서 잔달할 실제 데이터를 의미한다. 

표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다. 

 

회원 이라는 리소스를 html 형태로 전달할 수 있고, json 형태로 전달할 수도 있다. 

그래서 실제 전달하는 형태를 '표현'이라는 용어로 정의했다. 

 


1. 표현과 관련된 헤더 

표현 헤더는 요청, 응답 두 경우 모두 사용한다.

표현 헤더 종류 4가지

1. Content-Type 표현 데이터의 형식 

ex) text/html, application/json, image/png, etc.. 

 

2. Content-Encoding 표현 데이터의 압축 방식 

ex) gzip, deflate, identity(압축 안함)

데이터를 보내는 쪽에서 압축 후 인코딩 헤더를 추가한다. 데이터를 읽는 쪽에서 인코딩 정보를 기반으로 압축을 해제한다. 

 

3. Content-Language 표현 데이터의 자연 언어 

ex) ko, en, en-us

한국어, 중국어, 영어 모두 제공하는 웹페이지를 떠올려보자. 

 

4. Content-Length 표현 데이터의 길이(byte 단위)

참고) Transfer-Encoding(전송 인코딩)을 사용하면 Content-Length를 쓰면 안된다.

전송 코딩은 chunk로 나뉘기 때문에 전체 길이가 아니라  chunk 마다의 길이를 포함하기 때문이다. (아래에서 배움)


2. 협상 헤더 ( == 콘텐츠 네고시에이션)

클라이언트가 원하는 표현 우선순위를 서버에 요청한다.  서버는 이것에 가능한 맞춰서 응답을 준다. 

협상 헤더는 요청 시에 만 사용한다. 

 

1. Accept: 클라이언트가 선호하는 미디어 타입 전달 
2. Accept-Charset: 클라이언트가 선호하는 문자 인코딩 
3. Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
4. Accept-Language: 클라이언트가 선호하는 자연 언어 

Accept-Language 적용 전 시나리오 

클라이언트가 한국에서 브라우저를 이용하는데 외국 사이트에 접속했다. 

다중 언어를 지원하는 서버는 응답을 줄 때 기본으로 영어를 선택한다. 

Accept-Language 적용 후 시나리오 

클라이언트가 Accept-Lanuage: ko 협상 헤더를 담아서 요청한다. 

서버가 한국어를 지원할 수 있다면 한국어를 선택하여 응답을 준다.

협상과 우선순위 (Quality Values) 

협상 헤더의 우선순위 시나리오 예시 

클라이언트가 Accept-Language: ko 협상 헤더를 실어서 요청했다. 
서버는 ko를 지원하지 않는 상황이다. 그리고 서버의 1순위(기본)독일어이고 2순위 영어 를 지원한다. 
클라이언트는 1순위 한국어 2순위 영어 로 응답 받고 싶다. 

 

1. Quality Values(q)를 사용한다.

Quality Values(q)는 0에서 1까지의 값을 갖는다. 생략하면 1이다. 

클라이언트의 협상 헤더 Accept-Lanuage:ko-KR, ko; 1=0.9, en-US; 1=0.8, en;q=0.7

-> 한국어 1순위로 선호. 2순위로 영어를 선호. 

따라서 서버는 2순위 영어 페이지를 응답해준다. 

 

2. 구체적인 것이 우선한다.

아래 중에 어떤 것이 우선 적용될까? 우선순위대로 나열해보자. 

text/* , text/plain , text/plain;format=flowed, */* 

 

[ 우선순위 대로 나열 ]

1순위 text/plain;format=flowed 

2순위 text/plain

3순위 text/* 

4순위 */*


3. 전송 방식 헤더 4가지 

1. 단순 전송 

contents 의 길이를 알고 있을 때 사용한다. 

 

2. 압축 전송 

content-Encoding: gzip

서버에서 gzip으로 압축했을 때, content-Encoding: gzip 전송 헤더 필드를 넣어서 gzip임을 클라이언트에 알려야한다. 

 

3. 분할 전송 

Transfer-Encoding: chunked 

큰 데이터를 "길이와 데이터'로 구성된 덩어리(chunk)들로 분할해서 보낸다.

이 때는 content-length 헤더를 넣으면 안된다. 덩어리가 여러개라서 content-length를 모르기 때문이다. 

 

4. 범위 전송

Range, Content-Range 

클라이언트: "1001부터 2000까지 주세요" 라고 요청 

서버 : "1002부터 2000까지 보냅니다" 라고 응답 


김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 공부하고 요약했습니다. 

728x90

'프로그래밍 > HTTP' 카테고리의 다른 글

HTTP 헤더 - 일반 헤더(2)  (0) 2021.12.14
HTTP 4xx 클라이언트 오류 5xx 서버 오류  (0) 2021.12.14
HTTP 리다이렉션  (0) 2021.12.14

+ Recent posts