네트워크 (6) HTTP 헤더 - 1 - 종류와 사용

 

 

HTTP 헤더와 바디의 역할?

 

 

HTTP 헤더는 클라이언트와 서버가 요청 혹은 응답으로 부가적인 정보를 전송할 수 있도록 해준다.

예시 ) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 ...

 

기존 RFC 2616에서 헤더와 바디의 역할은 다음과 같이 분류됐었다.

1. General header : 요청과 응답 모두에 적용되지만 바디에서 최종적으로 전송되는 데이터와는 관련이 없는 헤더.

2. Request header : 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더.

3. Response header : 위치 또는 서버 자체에 대한 정보와 같이 응답에 대한 부가적 정보를 갖는 헤더.(버전, 이름 등)

4. Entity header : 컨텐츠 길이나 MIME 타입 등 엔티티 바디에 대한 정보를 포함하는 헤더.

5. HTTP body

: 메시지 본문은 엔티티 본문을 전달하는 것에 사용.

엔티티 본문은 요청이나 응답에서 전달할 실제 데이터.

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

 

그러나.. HTTP RFC723x의 시대가 도래했다.

 

엔티티(Entity) 헤더는 표현(Representation) 헤더라는 기묘한 이름으로 바뀌었다.

Representation은 representation Metadata와 Represntation Data가 합쳐진 것이다. (표현 메타데이터 + 표현 데이터)

그런데 사실 용어가 바뀌었을 뿐 그외에 변경점은 크게 없다. 심지어 MDN에서는 여전히 표현 헤더 항목은 만들기만 하고 텅 비워놨다. 대단한 변경점처럼 볼드체까지 사용했지만 그냥 어그로였다.

HTTP body도 기존 문장에서 "엔티티"를 "표현"으로 바꾸면 그대로다.

 

기왕 어그로 끌어본 거 표현 헤더의 속성에 대해 먼저 자세히 알아보자.

 

 

 

표현 헤더 (Representation header)

 

표현 헤더는 전송, 응답 모두 사용한다.

표현 헤더에 입력될 수 있는 정보는 다음과 같다.

 

(1) Content-Type

> 리소스의 미디어 타입 혹은 문자 인코딩을 나타낸다.

예시) text/html;, charset=utf-8, application/json, image/jpg

 

(2) Content-Encoding

> 압축 알고리즘을 명시하는데 사용된다.

> 전달하는 곳에서 압축 후 해당 정보를 추가하고, 읽는 쪽에서는 Content-Encoding의 정보를 바탕으로 압축해제한다.

dPtl) gzip, defalate, identify

* 압축 전송 시 해당 정보가 반드시 필요하다.

 

(3) Content-Language

> 사용자를 위한 언어를 설명하여 사용자가 선호하는 언어에 따라 구분할 수 있게 해준다.

예시) ko, en, en-us

 

(4) Content-Length

> 수신자에게 전송된 표현 바디의 크기를 10진수 바이트 단위로 나타낸다.

* TransferEncoding을 사용할 경우 Content-Length를 함께 사용하면 안된다.

* TransferEncoding 헤더는 데이터가 클 경우 분할해서 보내는 것인데 이 때 헤더는 Content-Length를 미리 알 수 없기 때문.

 

 

 

 

컨텐츠 협상(Content negotiation)

 

컨텐츠 협상은 동일한 URI에서 리소스의 다른 버전의 전달을 위해 사용되는 메커니즘이다.

표현 헤더의 정보를 바탕으로 클라이언트가 선호하는 표현을 요청한다. 참고로 Request header의 요청을 제외하더라도 여러가지 방법이 존재한다.

 

(1) Accept : 클라이언트가 선호하는 미디어 타입 전달.

(2) Accept-Charset : 클라이언트가 선호하는 문자 인코딩.

(3) Accept-Encoding : 클라이언트가 선호하는 압축 인코딩.

(4) Accept-Language : 클라이언트가 선호하는 자연 언어.

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

 

예시 ) 기본 언어 설정이 영어인 웹 사이트에 접속할 때 우리의 표현 헤더에는 Content-Language에 ko-kr값이 들어있기 때문에 요청 헤더가 자동으로 한국어 설정을 요청한다. (당연하게도 한국어를 지원하는 서버여야 한다.)

 

 

 

 

일반 정보성 헤더

 

1. Form

> 유저 에이전트의 인터넷 이메일 정보

> 크롤러 같은 것으로 서버 상에 문제를 일으킬 가능성이 있는 경우 연락처 용도로 사용한다

> 접근 제어, 혹은 인증을 위해 Form 헤더를 사용해서는 안된다.

2. Referer

> 현재 요청된 사이트의 이전 주소를 포함한다.

> 유입 경로 분석 등에 사용 가능하다.

> Referer 헤더는 URL 프래그먼트 또는 username : password 정보를 포함할 수 없다.

TMI : Referer은 referrer의 오타인데 뒤늦게 발견하는 바람에 아직까지 사용되고 있다.

3. UserAgent

> 클라이언트의 애플리케이션 정보, 운영체제, 공급업체, 버전을 식별할 수 있도록 한다.

> 어떤 상황에서 오류가 발생하는지 분석하기에 좋다.

> 사용자 감지 헤더를 사용하는 것은 생각보다 어렵다고 한다.(https://developer.mozilla.org/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent)

4. Server

> 원본 서버, 즉 응답을 생성한 서버의 소프트웨어 정보를 응답한다.

> 해커가 보안 취약점을 악용할 수 있는 정보를 노출할 수 있으므로 지나치게 자세한 값은 피해야 한다.

5. Date

> 메세지가 만들어진 날짜와 시간을 포함한다.

 

 

 

 

 

특별 정보성 헤더

 

1. Host (필수값)

> 서버의 도메인명과 서버가 리스닝하는 TCP 포트를 특정한다.

> 헤더 필드가 없다면 400 Bad Request 상태 코드가 전송된다.

> 하나의 서버가 여러 도메인을 처리해야할 경우 Host header로 구별할 수 있다.

2. Location

> 300대 상태 응답 결과에 Location 헤더가 있다면 해당 URL로 리다이렉션한다.

> 201 (Created)일 때 Location 값은 요청에 의해 생성된 리소스 URI로 리다이렉션한다.

3. Allow

> 405 (Method Not Allowed)에서 응답에 포함해야하는 헤더이다.

> 어떤 메서드를 지원하지 않는지 알려주는 역할.

4. Retry-After

> 다음에 올 요청이 이루어지기 전에 사용자가 대기해야 하는 시간을 응답한다.

예시 ) 503 Service Unvailable 응답이 전송된 경우, 얼마나 오래 이용 불가한지를 응답한다.

 

 

 

 

 

인증 헤더

 

1. Authorization

> 보통 서버에서 401 상태를 알려준 이후에 나오며 서버의 사용자 에이전트임을 증명하는 자격을 포함한다.

2. WWW-Authenticate

> 특정 리소스에 접근시 필요한 접근 방법을 정의하며 401 Unauthorize와 함께 사용된다.

예시 ) 클라이언트의 요청 -> 서버에서 401 응답과 함께 WWW-Authenticate에 필요한 정보 보냄 -> 클라이언트에서 Authorization 헤더를 포함하여 재요청 -> 정상 응답

 

 

 

 

 

>>분량 초과로 인해 쿠키 헤더와 캐시 헤더는 네트워크 (7)편으로