HTTP 헤더

HTTP 헤더는 HTTP 전송에 필요한 부가정보를 포함하고 있습니다. 본문의 내용이 어떤 타입으로 되어있는지, 사용자가 선호하는 언어는 무엇인지부터 시작해서 직접 임의의 헤더를 추가할 수도 있습니다.

Representation

RFC7230 표준 이후부터 등장한 개념으로 HTTP의 Body부분에 있는 리소스, 즉 메세지 페이로드를 의미합니다. 리소스의 타입이 JSON일수도, XML일수도 있는 등 다양한 형태의 리소스가 존재합니다. 메세지 페이로드가 어떤 형태로 작성된 것인지 수신측에 이해시키기 위해 Representation 헤더를 사용합니다.(출처:MDN)

아래에서는 Representation 헤더에 대해 소개하고자 합니다.

• Content-Type
  본문의 형태를 정의한 부분입니다. MDN에서 준 예시를 보면 바로 이해가 됩니다.

-HTTP Body에 작성된 HTML 코드-
<form action="/" method="post" enctype="multipart/form-data">
  <input type="text" name="description" value="some text">
  <input type="file" name="myFile">
  <button type="submit">Submit</button>
</form>

-HTTP 헤더-
POST /foo HTTP/1.1
Content-Type: multipart/form-data; boundary=~~
...

• Content-Encoding
  Representation 데이터가 인코딩된 경우 인코딩 타입을 알려줍니다.

-예시-
Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: br

• Content-Language
  이 문서가 어떤 사용자를 타겟으로 작성되었는지 알려줍니다. 조심해야 할 점은 문서를 작성하는데 사용된 언어와 타겟의 언어는 다를 수 있다는 것입니다. 독일어 사용자를 위한 문서였을지라도 문서 자체는 영어일 수도 있습니다.

-예시-
Content-Language: de-DE, en-CA

여기서 en-CA와 같이 - 표시는 영어를 사용하는 여러 국가 중 Canada를 위한 문서임을 의미합니다.

• Content-Location
  컨텐츠 협상의 결과로 나온 리소스를 어떤 URL로 보낼지 정의해줍니다. 컨텐츠 협상에 대해서는 아래에서 좀 더 자세히 다룰 예정입니다.

-예시-
Content-Location: /my-first-blog-post

Negotiation

협상이라는 단어를 곰곰히 생각해보면 상호 합의라는 의미를 가집니다. 클라이언트와 서버 사이에 어떠한 협상이 이루어지는 것을 컨텐츠 협상이라고 합니다.
Negotiation은 요청에서만 등장하는데, 클라이언트는 Negotiation Header를 통해 자신이 선호하는 Representation 형태를 알려줍니다.

-예시-
Accept-Language: de

위의 예시에서 클라이언트는 독일어를 선호한다고 요청 헤더에 정보를 담아 서버쪽으로 전송합니다. 해당 페이지가 독일어를 지원한다면 서버는 독일어 사용자를 위한 응답을 보낼 것입니다.

가중치(weighting factor)

하지만, 해당 페이지가 독일어를 지원하지 않고, 한국어와 영어만 지원한다면 어떻게 될까요? 보통의 경우라면 영어를 더 선호할 것입니다. 하지만 서버는 위의 예시만으로는 이를 알 수 있는 방법이 없고, 웹페이지의 주 언어가 한국어라면 한국어 사용자를 위한 응답을 보낼 것입니다.
이러한 경우에는 우선순위를 줄 수 있습니다. ;q=는 가중치를 의미하는데 아래의 예시를 보면

Accept-Language: de-CH, de;q=0.9, en;q=0.8, fr;q=0.7

요청에서 독일어의 가중치를 0.9, 영어를 0.8, 불어를 0.7로 주었습니다. 가중치는 0~1 사이의 숫자로 1에 가까울 수록 선호도가 높음을 의미합니다.

물론 서버 자체가 클라이언트의 요청을 완벽히 받아들일수는 없습니다. 지원을 하지 않는다면 제아무리 클라이언트가 원하는 것이 있다고 해도 제공할 수 없기 때문입니다.

전송 방식에 따른 헤더의 차이

• 단순 전송 시
  한번에, 압축없이 전송하는 방식으로 컨텐츠의 길이만 헤더에 작성합니다.

Content-Length: 3000

• 압축 전송 시
  컨텐츠를 압축하여 용량을 크게 줄였을 때는 압축 방식도 작성해서 알려주어야 합니다.

Content-Encoding: gzip
Content-Length: 500

• 분할 전송 시
  컨텐츠를 chunk로 쪼개어 전송하는 방식입니다. 이때는 Content-Length 헤더가 있으면 안되는데, 쪼갠 청크마다 바이트 크기가 기록이 되어있기도 하고, 전체 컨텐츠의 길이를 예측할 수 없기 때문입니다.

Content-Encoding: chunk

• 범위 전송 시
  이미 앞부분의 동영상 데이터를 받았다는 등 일부분의 전송을 원하는 데이터의 범위가 일부인 경우 범위를 지정하여 전송할 수 있습니다.

Content-Range: bytes 1001-2000/2000

중요 헤더

Host

요청 헤더에 필수적으로 존재해야 하는 헤더로, 요청한 호스트에 대한 정보를 가지고 있습니다.

Location

300번대의 상태코드인 리다이렉션에서 리다이렉션 위치를 알려줍니다.

Allow

기타 헤더

referer

요청된 페이지의 이전 웹페이지를 알려주는 헤더로, 이를 통해 유입 경로 등을 분석할 수 있습니다.

user-agent

유저 에이전트 어플리케이션 정보를 알려주는 헤더로, 어떤 종류의 웹 브라우저에서 장애가 발생하였는지 분석할 수 있습니다.

server

요청의 최종 목적지, 응답 메세지를 만들어주는 Origin 서버를 알려주는 헤더입니다.

참고자료
https://developer.mozilla.org/en-US/docs/Glossary/Representation_header
https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/unit/61378?tab=curriculum