[HTTP] HTTP Header 정리

HTTP Header 아무 생각 없이 복붙하지 말고, 이제 알고 사용하자!

학습목표

• HTTP Header에 대해 설명할 수 있다.
• 자주 사용되는 항목에 대해 설명할 수 있다.

 

HTTP Header

HTTP Header는 클라이언트 요청 또는 서버 응답 시 부가적인 정보를 전송할 수 있도록 한다.

HTTP 메시지를 뜯어보면, 다음과 같은 메시지가 클라이언트, 서버 사이에서 전송된다.

 

HTTP Message는 보통 Header + Body 구조로 아래와 같이 되어있다. 요청(Request)과 응답(Response) 헤더로 나눠지고, 서로 다른 HTTP 헤더를 가지고 있으며, 종류가 많기 때문에 자주 사용되는 것들을 천천히 정리하고자 한다.

 

 

헤더는 흔히 컨텍스트에 따라 그룹핑될 수 있는데, 크게 4가지로 분류된다.

• General Header(공통 헤더)
• Request Header(요청 헤더)
• Response Header(응답 헤더)
• Entity Header(엔티티 헤더)

 

공통 헤더(General Header)

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

가장 흔히 사용되는 공통 헤더는 Date, Cache-Control 및 Connection이다.

Date

요청과 응답시에 자동으로 만들어지는 헤더다.

Date 일반 HTTP 헤더는 메시지가 만들어진 날짜와 시간을 포함한다.

# HTTP 메시지를 생성한 일시 (RFC 1123에서 규정)
Date: Tue, 29 Jun 2021 13:46:12 GMT​

Cache-Control (쿠키/캐시 관련)

요청과 응답 내의 캐싱 메커니즘을 위한 디렉티브를 정하기 위해 사용된다. 캐시 디렉티브는 단반향성이며, 이는 요청 내에 주어진 디렉티브가 응답 내에 주어진 디렉티브와 동일하다는 것을 뜻하지는 않는다는 의미이다. (무슨 소리일까?)

Connection

현재의 전송이 완료된 후 네트워크 접속을 유지할지 말지를 제어한다.
만약 keep-alive면, 연결은 끊기지 않고 지속되며, 동일한 서버에 대한 후속 요청을 수행할 수 있다.

# 기본값: HTTP 요청 후 연결 닫음
Connection: close
# 명시값: HTTP 요청 후 연결 유지
Connection: keep-alive​

 

엔티티 헤더(Entity Header)

컨텐츠의 길이나 MIME 타입과 같이 엔티티 바디(콘텐츠, 본문, 리소스 등)에 대한 자세한 정보를 포함하는 헤더다.

• HTTP 메시지 내 포함된 선택적인 개체에 대한 구체적인 미디어 타입 등의 명시할 수 있다.
• HTTP 메시지는 이미지, 비디오, 오디오, HTML 문서, 전자메일 등의 개체들을 운반할 수 있다.

Content-Type

개체의 미디어 타입(MIME)과 문자열 인코딩을 지정하기 위해 사용한다.
이는 Accept 헤더와 대응된다.

// 메시지 내용: text/html 타입의 utf-8 문자열이다
Content-Type: text/html; charset=utf-8

Content-Language

사용자들에게 언어를 설명하기 위해 사용된다. 사용자가 선호하는 언어에 따라 사용자를 구분할 수 있게 한다.
예를 들어서 Content-Language: en-US로 설정된다면, 미국에서 만들어졌지만, 일부분이 영어가 아닐 수도 있다.

만약 Content-Language가 지정되지 않으면 모든 사람들에게 공개된 정보라고 간주한다.

Content-Language는 Text 뿐만 아니라 미디어 타입에도 적용됨.

Content-Language: de-DE
Content-Language: en-US
Content-Language: de-DE, en-CA

HTML 문서에도 다음과 같이 사용할 수 있지만, 사용하지 않는 것을 MDN에서 권고한다.

<!-- Anti-pattern -->
<meta http-equiv="content-language" content="de">

Content-Encoding

미디어 타입을 압축하기 위해서 사용된다.
이 헤더가 존재한다면 그 값은 어떤 방식으로 인코딩 되는지 알 수 있다.
우리가 gzip등의 알고리즘을 통해 encoding 해서 보낸다면 브라우저가 알아서 해제해서 사용한다.

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: identity
Content-Encoding: br

Content-Length

Header + Body의 크기(바이트 단위)를 나타낸다.

메시지 크기에 따라 자동으로 생성된다.

 

요청 헤더(Request Header)

요청 헤더는 HTTP 요청에서 사용되지만 메시지의 컨텐츠와는 관련이 없다.

GET /home.html HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/testpage.html
Connection: keep-alive
Upgrade-Insecure-Requests: 1
If-Modified-Since: Mon, 18 Jul 2016 02:36:04 GMT
If-None-Match: "c561c68d0ba92bbeb8b0fff2a9199f722e3a621a"
Cache-Control: max-age=0

요청에 나타나는 모든 헤더가 요청 헤더는 아니다. 예를 들어, POST 요청시 나타나는 Content-Length는 실제로 요청 메시지 바디의 크기를 참조하기 때문에 엔티티 헤더임을 유의하자.

 

응답 헤더(Response Header)

HTTP 응답에서 사용될 수 있는 헤더이며, 메시지의 컨텐츠와 관련이 없다. Age, Set-Cookie, x-frame-options와 같은 응답 헤더는 더 상세한 응답 컨텍스트를 제공하기 위해 사용된다.

200 OK
Access-Control-Allow-Origin: *
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Mon, 18 Jul 2016 16:06:00 GMT
Etag: "c561c68d0ba92bbeb8b0f612a9199f722e3a621a"
Keep-Alive: timeout=5, max=997
Last-Modified: Mon, 18 Jul 2016 02:36:04 GMT
Server: Apache
Set-Cookie: mykey=myvalue; expires=Mon, 17-Jul-2017 16:06:00 GMT; Max-Age=31449600; Path=/; secure
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding
X-Backend-Server: developer2.webapp.scl3.mozilla.com
X-Cache-Info: not cacheable; meta data too large
X-kuma-revision: 1085259
x-frame-options: DENY

응답에 나타나는 모든 헤더가 응답 헤더인 것은 주의해야 한다. 예를 들어, Content-Length 헤더는 응답 메시지 바디의 크기를 참조하므로 엔티티 헤더이며, Content-Encoding과 Content-Type도 동일하게 엔티티 헤더임을 유의하자.

 

---

부록

Content-Type와 Accept Header의 차이점

Content-Type 헤더

HTTP 메시지(요청과 응답 모두)에 담겨 보내는 데이터의 형식을 알려주는 헤더. HTTP 표준 스펙을 따르는 브라우저와 웹 서버는 Content-Type을 기준으로 HTTP 메시지에 담긴 데이터를 분석하고 파싱한다.

만약, Content-Type 헤더가 없다면?

데이터를 요청측(브라우저나 웹서버)에서는 특정한 형식의 데이터일지라도 수신측에서는 단순 텍스트 데이터라고 인식하게 된다. 텍스트를 분석하는 추가적인 코딩을 하기 싫다면, Content-Type 명시는 필수적이다.

그렇다면, GET 방식의 쿼리스트링의 경우는?

GET 요청의 경우, URL 끝에 쿼리스트링(form: key=value)으로 요청하기 때문에 Content-Type가 필요 없다.

수신측(웹서버)도 요청 방식이 GET이라면, key=value 데이터 포맷임을 알고 있기 때문이다.

그럼, 언제 주로 사용할까?

Content-Type은 POST나 PUT과 같이 메시지 BODY에 데이터를 실어 보낼 때 사용한다.

1. 예) AJAX를 통해 JSON 형식의 데이터를 전송하는 경우.
   :: Content-Type: application/json으로 지정하여 보내야 한다.
2. 예) <form>을 통해 첨부파일 등을 전송하는 경우.
   :: Content-Type: multipart/form-data로 브라우저가 알아서 설정하여 요청 메시지를 보낸다.

Accept 헤더

이 헤더는 자신에게 이러한 데이터 타입만 허용하겠다는 뜻이다.

즉, 요청 메시지의 Accept 헤더를 application/json이라고 설정했다면, 웹서버에게 '나는 JSON 데이터만 처리할 수 있으니, JSON 데이터 형식으로 응답을 돌려줘'라고 알려주는 것이다. 물론, 웹서버가 해당 타입을 지원해야 의미가 있음을 알아두자.

 

 

다른 것들도 간략하게 정리해보자.

인증(Authentication)

• Authorization
  서버와 함께 유저 에이전트를 인증하기 위한 자격 증명을 포함한다.

내용 협의(Content negotiation)

• Accept: 돌려줄 데이터 타입에 대해 서버에 알림.
  

  Accept: text/html
  Accept: application/json
  Accept: image/*
  Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8

• Accept-Charset: 클라이언트가 이해할 수 있는 문자 집합을 서버에 알림.
• Accept-Encoding: 인코딩 알고리즘을 서버에 알림. 대게, 돌려줄 리소스에 사용되는 압축 알고리즘이다.
• Accept-Language: 서버가 돌려줬으면 하는 언어에 대해 서버에 알림.

캐싱(Caching)

• Expires: 응답이 만료되었다고 고려되는 날짜/시간.
• Cache-Control: 요청과 응답 모두에서의 캐싱 메커니즘을 명시하는 지시문.
• Pragma: 요청-응답 체인을 따라 어디든 다양한 영향을 줄 수 있는 구현-관련 헤더. Cache-Control 헤더가 존재하지 않는 HTTP/1.0 캐시와의 하위 호환성을 위해 사용됨.

쿠키(Cookie)

• Set-Cookie 헤더와 함께 서버로부터 이전에 전송됐던 저장된 HTTP 쿠키를 포함합니다.
• Set-Cookie 서버에서 유저 에이전트로 쿠키를 전송합니다.

CORS(link)

• Access-Control-Allow-Origin: 응답이 공유될 수 있는지를 나타냄.
• Access-Control-Allow-Credentials: credentials 플래그가 true일 때 요청에 대한 응답이 노출될 수 있는지를 나타냄.
• Access-Control-Allow-Headers: 실제 요청을 만들 때 사용될 수 있는 HTTP 헤더를 나타내는 preflight 요청에 대한 응답으로 사용됨.

다운로드(link)

• Content-Disposition 전송된 리소스가 한 줄로 표시되어야 하거나(헤더가 존재하지 않을 때는 기본 동작), 다운로드처럼 처리되어야 하고 브라우저가 '다른 이름으로 저장' 창을 표시해야 할 때에 대한 응답 헤더입니다.

Proxy(프록시)

• Forwarded 프록시가 요청의 경로에 포함될 때 변경되거나 손실되는 프록시 서버의 클라이언트 측면에 대한 정보를 포함합니다.
• X-Forwarded-For HTTP 프록시나 로드 밸런서를 통해 웹 서버로 연결하는 클라이언트의 시작 IP 주소를 확인합니다.
• X-Forwarded-Host 클라이언트가 여러분의 프록시나 로드 밸런서에 접속하기 위해 사용하도록 요청됐던 원본 호스트를 확인합니다.
• X-Forwarded-Proto 클라이언트가 여러분의 프록시나 로드 밸런서에 접속하기 위해 사용했던 프로토콜(HTTP 또는 HTTPS)을 확인합니다.

 

대부분 언제 사용해야 된다는 건지 모르겠다...
정리하면서도 어렵다. 그 때 그 떄 찾아보도록 하자!

[출처] HTTP 헤더, "MDN"
[출처] Content-Type와 Accept HTTP Header의 용도와 차이점, "코끼리를 냉장고에 넣는 방법"

[참고] HTTP 헤더란? 그리고 Header의 종류, "Wonit"

 

Updated 2021. 6. 30