HTTP를 배워보자 7일차 - HTTP 헤더

 

1. 개요

대망의 계획했던 HTTP 마지막..! 챕터이지만 이 부분, 내용이 상당히 많다.

기본적인 헤더 정보에서 시작해, 캐시와 조건부 헤더, 상태 코드에 따른 리다이렉션 location이나 Allow 등도 헤더와 관계되어 있고,

심지어 우선순위도 헤더 정보에 들어가 있어 전부 설명할 수 있을지 모르겠다.

선뜻 글을 시작하기 두렵지만 일단 차근차근 함께 알아가보자.

 

 

2. HTTP 헤더 개요

 

2.1 HTTP 직접 확인하기

 

HTTP 헤더를 직접 확인하는 방법은 다음과 같다.

 

1. 아무 웹 페이지나 들어간 후 [마우스 오른쪽 클릭] - [검사]를 누른다.

 

 

 

보통 이런 화면이 오른쪽에 뜰 텐데, 여기서 빨간 네모 박스 "Network"를 누른다.

 

 

그럼 이런 화면이 뜨는데, 여기 내용물들 중 아무거나 클릭하면

 

 

이런 화면이 뜨는데, 맨 위 "Headers"에 해당 파일의 모든 헤더 정보가 담겨있다. 

 

 

2.2 HTTP 헤더의 형식

 

위 헤더 내용을 잘 살펴보면 어느 정도 규약이 있는데, 우선 내용물의 형식은 이러하다.

field-name ":" OWS field-value OWS (OWS: 띄어쓰기 허용)



"Accept: application/json" 등등 모두 이런 모양으로 이루어져 있다. 쉽게 key:value 맵 형식이라 봐도 될 듯하다.

추가로 "field-name" 부분은 대, 소문자 구분이 없다. (accept, Accept 모두 똑같다.)

 

 

2.3 HTTP 헤더의 용도

 

HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보를 담고 있다. 예를 들면, 메시지 바디의 내용과 크기, 인증 상태, 서버 정보 등인데, 이 부분에 관해선 아래 분석에서 살펴볼 예정이다.

 

또한 필요시 임의의 헤더를 추가할 수 있다. 예를 들면 "blog: suhwanc"라는 헤더는 없는 헤더지만 내가 만든 헤더인 셈이다.

 

 

2.4 RFC 7230

 

하지만 HTTP/1.1 표준이 RFC 7230으로 바뀌면서 위에서 언급한 헤더, 메시지 데이터의 개념이 "표현"이라는 형식으로 변했는데,

"표현" = "표현 헤더" + "표현 데이터" 정도로 변했다고 보면 될 것 같다. (사실 표현 헤더는 또 메타데이터와 페이로드 메시지로 구분된다.)

 

따라서 앞으로 HTTP 헤더는 표현 헤더로, 메시지 바디는 표현 데이터로 칭하겠다.

 

 

3. 헤더 설명

 

3.1 컨텐츠 부분

 

 

• Content-Type : 표현 데이터의 형식으로 미디어 타입, 문자 인코딩 등이다. ex) text/html, application/json, image/png..
• Content-Length : 표현 데이터의 길이로 바이트 단위를 사용한다.
• Content-Encoding : 표현 데이터를 압축하기 위해 사용한다. ex) gzip, deflate, identity
• Content-Language : 표현 데이터의 자연 연어를 표현한다. ex) ko, en, en-US

 

하지만 이상한 점은, 위에서 인코딩과 언어는 Accept로 되어있다는 점인데.. 바로 아래 설명한다.

 

 

3.2 협상(Content Negotiation)

 

때때로 우리는 이상하리만큼 외국 사이트가 우리말로 번역되어 보일 때가 있다. 우리는 그렇게 하려고 무언가를 한 적이 없는데 말이다.

그런 부분은 웹 사이트가 자동으로 우리 위치를 알고, 협상 요청을 보내 받은 결과인데
협상은 클라이언트가 선호하는 표현 요청을 Request Header에 보낸다.

 

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

 

3.3 협상 우선순위

 

위에 살짝만 올려 사진 속의 "Accept-Language"를 보고 오자.

 

 

보면 언어만 있는 게 아니라, q=0.9 이런 식으로 숫자가 매겨져 있는데, 이를 우선순위(Quality Values)라고 한다.

우선순위는 0~1로 구성되며 클수록 높은 우선순위를 갖는다. 만약 이 숫자가 생략되면 가장 큰 1을 부여받는데, 위에서 ko-KR이 그런 경우이다.

그다음으로는 ko, en-US, en 순으로 우선순위가 지정된 것을 볼 수 있다.

 

그래서 만약 우리가 이런 요청을 Accept-Language에 보내게 되면, 한국말로 받을 수 있는 페이지라면 무조건 한국말로 오고,

그렇지 안다면 en-US, en 순으로 요청을 보낸다. 만약 모두 없다면 거기 언어로 받게 될 것이다. (보통 영어로는 대부분 되어있다.)

 

 

이번엔 다시 위로 올려 사진 속의 "Accept" 부분을 보고 오자.

 

 

사실 위에 안 봤겠지만 이런 게 있다.

아까 우선순위 부여와 다른 또 다른 순위 부여 방법인데, 이 방법은 구체적인 것이 우선시 된다.

(참고로  애스터리스크(*)는 전체를 포괄하는 단위로 구체성이 떨어진다.)

 

아마 여기선 image/svg+xml 이 가장 높고, image/*, */* 이 가장 낮은 우선순위를 담당할 것이다.

 

 

3.4 일반 정보들

 

1) Referer

 

현재 요청된 페이지의 이전 웹 페이지 주소를 담고 있다.

만약 내가 네이버 메인에서 스포츠 메인으로 이동하면, 그때 Referer는 naver.com 이 될 것이다.

이를 바탕으로 유입 경로를 분석 가능한데, 예를 들면 블로그의 유입 경로 분석을 할 때 쓸 수 있겠다.

 

 

2) User-Agent

 

클라이언트의 애플리케이션 정보이다.

나는 현재 이러한 정보를 담고 있다는데, 일단 노트북의 사양, 웹 브라우저의 정보 등인 것 같다.

이를 통해 어떤 종류의 브라우저에서 장애가 발생하는지 파악이 가능하다고 한다.

 

 

3) Host

 

요청한 호스트 정보(도메인) 값을 갖고 있으며 필수이다.

몇 개 확인해보니 티스토리 블로그는 대부분 이런 호스트를 가지고 있다.

 

 

4) Location

 

저번 챕터에서 언급한 3xx 리다이렉트 응답의 결과로 사용되는 헤더이다.

만약 응답 코드가 3xx이고, Location 헤더가 있다면, 여기 Location이 가리키는 위치로 자동 이동하게 된다.

 

 

5) Allow

 

이것 또한 상태 코드 405 (Method Not Allowed) 의 응답에 포함되어야 하는 헤더이며

보통 Allow: (GET, HEAD, PUT) 등이 쓰인다.

 

 

6) Retry-After

 

상태코드 503 (Service Unavailable)에 쓰이는데, 이 상태 코드는 참고로 서비스가 언제까지 불능인지 알려주는 서버 측 상태 코드이다.

ex) Retry-After: 120 (초 단위),  Retry-After: Tue, 27 July 2021 10:17:42 GMT (날짜 표기) 

 

 

사실 더 있는데, 쿠키를 좀 더 공부하고 쓰려고 한다. 😅