✅ HTTP 헤더란?
HTTP 헤더는 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있게 해준다. HTTP 헤더는 대소문자를 구분하지 않는 이름과 콜론(:)다음에 오는 값으로 이루어져 있다.
☑️ 헤더 필드는 header-field = field-name : OWS field-value OWS의 형식으로 이루어져 있다. field-name은 대소문자 구분이 없다. (OWS는 띄어쓰기 허용을 의미한다.)
[요청과 응답 헤더]
✅ HTTP 헤더의 용도
☑️ HTTP 전송에 필요한 모든 부가정보를 담고있다.
예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등
☑️ 표준 헤더가 아주 많다.
헤더 필드 목록
☑️ 필요시 임의의 헤더를 추가할 수 있다.
예) helloworld: hihi
✅ HTTP 헤더의 변화
HTTP 헤더는 1994년 RFC2616이 등장하고 계속 사용되었으나 2014년 RFC7230~7235의 등장으로 개편되었다.
[RFC2616의 메세지 헤더를 RFC 7230, 7231 기준으로 분류]
위 표에서 확인할 수 있듯이 여러 헤더들이 제거되기도하고 분류가 변경된 헤더들도 있었는데, 엔티티 헤더가 표현 헤더로 새롭게 명명하는것이 주요 변화중 하나였다.
엔티티 헤더가 표현 헤더로 용어를 새롭게 정의된 이유는 리소스가 여러 방식으로 표현되어 전달될 수 있기 때문이다.
예를 들면, 회원 조회 내역을 응답할 때 이를 HTML로 전달할 수도 있고 JSON으로 전달할 수도 있다.
표현 헤더는 표현 표현 메타데이터와 표현 데이터를 합쳐서 나온 개념이다.
✅ HTTP Body
[HTTP 메시지 헤더와 본문 (RFC2616) - 과거]
☑️ 메시지 본문은 엔티티 본문을 전달하는데 사용된다.
☑️ 엔티티 본문은 요청이나 응답에서 실제 전달할 데이터를 의미한다.
☑️ 엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보를 제공한다.
예) 데이터 유형(html, json), 데이터 길이, 압축 정보 등
[HTTP 메시지 헤더와 본문 (RFC7230) - 현재]
☑️ 메시지 본문(payload)을 통해 표현 데이터(요청이나 응답에서 전달할 실제 데이터)를 전달한다.
☑️ 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다.
예) 데이터 유형(html, json), 데이터 길이, 압축 정보 등
✅ 표현 헤더
표현 헤더는 클라이언트와 서버간에 리소스가 어떻게 표현되어 전달되는지 나타내는 역할을 한다. 요청(Request)과 응답(Response) 둘 다 사용한다.
☑️ Content-type : 표현 데이터의 형식
☑️ Content-Encoding : 표현 데이터의 압축 방식
☑️ Content-Language : 표현 데이터의 자연 언어
☑️ Content-Length : 표현 데이터의 길이
☑️ Transfer-Encoding : 분할 전송시 사용
☑️ Content-Range : 특정 범위 전송시 사용
☑️ Content-Location : 반환될 데이터에 대한 대체 위치를 가리킨다.
☑️ Content-type
서버와 클라이언트가 데이터를 주고 받을때는 데이터를 변환해서 주고받는데 이때 리소스를 변환하는 기준이
Content-type이다. 미디어 타입, 문자 인코딩 등 표현 데이터의 형식, 즉 메시지 바디에 어떤 데이터가 들어가는지 설명한다.
- 미디어 타입, 문자 인코딩
text/html;charset=utf-8
application/json(기본이 utf-8)
image/png
☑️ Content-Encoding
표현 데이터를 압축할 때 사용한다. 데이터를 전달하는 곳에서 메시지 바디를 압축하고 그 압축 정보를 인코딩 헤더에 추가해 보낸다. 그럼 데이터를 읽는 쪽에서 이 정보로 압축을 해제하게 된다.
- 표현 데이터 인코딩
gzip
deflate
identity(압축을 안한다는 의미)
☑️ Content-Language
표현 데이터의 자연 언어를 표현한다. 글로벌 서비스에서 언어를 선택할 때 사용된다.
- 표현 언어
ko
en
en-US
☑️ Content-Length
표현 데이터의 길이를 바이트 단위로 나타낸다. Transfer-Encoding(전송 코딩)을 사용할 때는 전송 코딩 안에 정보가 다 들어있기 때문에 사용하면 안된다.
✅ 콘텐츠 협상
클라이언트가 선호하는 표현 요청을 서버에 요청하는 것. 서버는 클라이언트가 원하는 우선순위에 최대한 맞춰서 표현 데이터를 만들어준다. 이 협상 헤더는 요청시에만 사용된다.
☑️ Accept : 클라이언트가 선호하는 미디어타입 전달
☑️ Accept-Charset : 클라이언트가 선호하는 문자 인코딩
☑️ Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
☑️ Accept-Language : 클라이언트가 선호하는 자연언어
콘텐츠 협상 예시 (Accept-Language)
클라이언트가 서버에서 지원하는 언어중 하나로 리소스에 대한 요청을 보낼경우 메시지 바디를 해당언어로 응답받을 수 있다.
만약, 클라이언트가 언어 타입에 대한 요청을 따로 헤더에 담아 보내지 않으면 서버에서 지원하는 기본타입으로 응답을 받게된다.
단, 지원하지 않는 언어를 요청할 경우 서버에서 지원하는 언어 중 기본언어로 응답받는다.
[Accept-Language 적용 전]
한국어 브라우저에서 특정 웹사이트에 접속했을 때 콘텐츠 협상(Accept-Language)에 대한 요청이 없으면 서버에서 기본언어로 설정된 영어로 응답한다.
[Accept-Language 적용 후]
클라이언트에서 콘텐츠 협상에 대한 요청으로 ko를 작성해 요청하면 서버에서는 해당 언어를 우선순위로 지원할 수 있기 때문에 한국어로 작성된 응답을 반환해준다.
[Accept-Language 복잡한 예시]
만약, 서버에서 지원하는 언어가 여러개인데 내가 최우선으로 선호하는 언어가 서버에서 지원하지 않는다면 우선순위를 사용해야 한다.
✅ 협상과 우선순위 - 우선순위 값
우선순위 값이 높은 순서의 값을 사용한다.
[Accept-Language 우선순위]
Quality Value(q)를 사용한다.
0~1의 범위내의 소수를 사용하고1에 가까울수록(클수록) 높은 우선순위를 갖는다.
만약,q값을 생략한다면1을 나타낸다.
[우선 순위 적용 후]
- 1순위 언어인 한국어를 서버에서 지원하지 않는다.
- 2순위 언어인 영어를 서버에서 지원한다.
- 서버에서는 우선순위에 있는 영어를 독일어보다 선호하기 때문에 영어로 응답한다.
✅ 협상과 우선순위 - 구체적인 내용
구체적인 것이 우선시 되며 구체적인 것을 기준으로 미디어타입을 맞춘다.
[미디어 타입 구체적 명시에 따른 우선순위]
- 내용이 구체적일 수록 우선시한다.
1.text/plain;format=flowed
2.text/plain
3.text/*
4.*/*
[미디어 타입]
예) Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5
➡️ text/plain에 직접적으로 매칭되는것은 없지만 text/* 과는 매칭되기 때문에 우선순위가 0.3이라고 볼 수 있다.
[Reference]
gparkkii.log
Catsbi's Dlog
김영한 - HTTP 웹 기본지식 강의
Mozilla
kyun2da.dev
개발왕 도던
