🌐 HTTP 콘텐츠 협상(Content Negotiation) 이해하기

HTTP 콘텐츠 협상 이란?

해외에서 서비스 되는 사이트 인데도, 한국에서 접속하면 컨텐츠를 한국어로 보여주고, 일본에서 접속하면 일본어로 자동으로 보여주는 것을 한번 쯤은 겪어봤을 것이다. 특별히 직접 사이트의 언어 지원 메뉴를 통해 설정하지 않았는데도 서버에서 스스로 파악하고 어떻게 해당되는 언어 페이지를 골라 표시해주는 것일까?

이것이 바로 클라이언트와 서버 간의 HTTP 콘텐츠 협상(Contents Negotiation)을 통해 이루어 지는 것이다.

콘텐츠 협상이란, 웹브라우저(user-agent)가 이용자에게 알맞는 형태의 리소스를 받을 수 있도록, 리소스를 어떤 형태로 받을지 정하는 메커니즘을 일컫는다. 이때 리소스의 형태는 문서의 언어나 이미지 포맷, 인코딩 등을 말한다.

콘텐츠 협상에는 대표적으로 두가지 방법이 있다.

• 서버 주도적 협상(server-driven/proactive negotiation) :
  • 콘텐츠 협상의 주도권이 서버에 있음.
  • 브라우저는 선호하는 설정값이 담긴 HTTP 협상 헤더를 서버에 보내고, 서버는 사용자에게 어떤 형태의 콘텐츠가 적절한지 헤더에 담긴 내용과 내부적인 알고리즘을 이용해 골라 응답한다.
• 에이전트 주도적 협상(agent-driven/reactive negotiation) :
  • 콘텐츠 협상의 주도권이 클라이언트에 있음.
  • 브라우저가 서버에 요청을 보내면, 서버는 사용자가 받고자 하는 리소스의 형태(representation)와 메타데이터(content-type, quality, language)에는 어떤 것이 있는지 알리고, 클라이언트는 여기서 알맞은 형태를 고르고 다시 서버에 재요청한다.

복잡하게 설명해놓았지만, 간단히 말하자면 리소스의 선택권이 서버냐 클라이언트냐 차이일 뿐이다. 이중 대체로 첫번째 방법이 통상적으로 사용된다고 보면 된다.

서버 주도적 협상은 HTTP 헤더의 Accept 헤더에 담긴 값을 통해 이루어진다. 지금부터 그 통신 흐름을 알아보자.

---

콘텐츠 협상 헤더

HTTP 헤더에는 서버 주도적 협상을 일으키게 하는 특정 헤더들이 있다. 이들을 협상 헤더라고 부른다.

협상 헤더는 클라이언트가 선호하거나 우선되는 표현 정보를 요청 시 함께 서버에게 전달하기 위해 사용한다. 예를 들어 클라이언트가 한국어로 된 리소스를 요구한다면, 서버에서 협상 헤더를 받고 파악하여 정보를 응답하는 식으로 이루어 진다. 또한 '선호' 표현 뿐만 아니라 '지원 유무' 로서도 활용될 수 있는데, 이로인해 서버는 클라이언트가 사용할 수 없는 것들을 전송하는 트래픽 낭비를 줄일수도 있는 특징이 있다.

협상 헤더	설명
Accept	클라이언트가 선호하는 미디어 타입 Accept: text/* : text 미디어타입은 모두 보내도 괜찮다는 의미
Accept-Charset	클라이언트가 선호하는 문자 인코딩
Accept-Encoding	클라이언트가 선호하는 압축 인코딩 gzip , compress , deflate , br , identity
Accept-Language	클라이언트가 선호하는 자연 언어 Accept-Language: en :영어로 된 컨텐츠를 받길 선호한다는 의미

 

콘텐츠 협상 예시

 

1. 협상 헤더 미적용

1. 한국에서 클라이언트가 이벤트 웹페이지에 대한 조회를 하였다.
2. 서버는 컨텐츠 표현 헤더 Content-Languages 를 통해 자신의 기본 언어인 '영어' 로 페이지를 전송한다. (miss)

 

2. 협상 헤더 적용

1. 한국에서 클라이언트가 이벤트 웹페이지에 대한 조회를 하였다. 이떄 Accept-Language 협상 헤더로 'ko'를 지정하여 요청 하였다.
2. 서버는 협상 헤더를 해석하고, 서버에서 '한국어'를 지원하기 때문에 컨텐츠 표현 헤더 Content-Languages 를 통해 '한국어' 페이지를 우선적으로 전송한다.

---

콘텐츠 우선순위

위처럼 서버가 빵빵하게 여러 언어를 지원할 경우, 단순하게 서버에서 지원하는 언어를 요청하면 되기 때문에 왠만한 경우는 문제가 없을 것이다. 하지만 서버에서 지원하지 않는 언어일 경우 그 다음 선호하는 최우선 언어로 설정할 필요가 있을 것이다. 예를 들어 독일어가 기본인 홈페이지에서 한국어 페이지를 요청했는데 한국어를 지원안하면 독일어가 나오는 것이 아닌 영어가 나오도록 우선순위를 지정하는 것을 들 수 있다.

 

콘텐츠 우선순위 예시

 

1. 협상 우선순위 미적용

1. 클라이언트가 이벤트 페이지에 대한 조회 요청과 함께 Accept-Language 협상 헤더로 '한국어' 를 지정하였다.
2. 기본 언어가 '독일어'로 된 서버는 '한국어'를 지원하지 않기 때문에 기본 언어인 '독일어' 로 페이지를 전송한다.

 

2. 협상 우선순위 적용

1. 클라이언트가 이벤트 페이지에 대한 조회 요청과 함께 Accept-Language 협상 헤더로 우선순위를 지정하였다. 지정된 우선순위는 `한국어' , '영어' 순이다.
2. 서버는 '한국어'를 지원하지 않기 때문에 '한국어' 페이지를 전송해줄 수 없다. 하지만 차순위인 '영어'를 지원하기 때문에 '영어' 페이지를 전송한다.

 

협상 헤더 우선순위 직접 지정

이처럼 협상 헤더들의 특징으로는 파라미터 값을 여러개 주어 서버에서 해당 타입을 지원 안할경우를 대비한 우선순위를 지정할 수 있다. 위의 예시에선 Accept-Language 협상 헤더에 여러 값들을 콤마(,)로 열거함으로써 우선순위를 지정할 수 있다는 알수 있다.

다만 협상 헤더의 우선순위 지정에 몇가지 문법과 규칙이 존재한다. 우선 언어 지정(ko) 옆에 있는 q 는 Quality Values의 약자로서 0 ~ 1 사이의 값을 가지며 클 수록 높은 우선순위를 뜻한다. (만일 생략하면 1 가장 높음이 된다)

따라서 위의 헤더를 해석하자면 콘텐츠 언어의 우선순위는 다음과 같이 된다.

1. ko-KR;q=1 (q생략)
2. ko;q=0.9
3. en-US;q=0.8
4. en:q=0.7

Accept-Language 뿐만 아니라 다른 협상 헤더도 적용이 가능하다.

 

협상 헤더 우선순위 자동 지정

추가적으로 협상 헤더의 값들의 우선순위에는 구체적인 값들이 우선된다는 특징이 있다. 예를들어 Accept 헤더에 미디어 타입들의 우선순의를 아래와 같이 지정해주었다고 하면, 이들의 우선순위를 다음과 같이 된다.

1. text/plain;format=flowed
2. text/plain
3. text/*
4. */*

 

물론 q 파라미터와도 함께 조합하여 사용이 가능하다. 응용하자면 아래와 같다.

1. text/html;level=1
2. text/html;q=0.7
3. */*;q=0.5
4. text/html;level2;q=0.4
5. text/*;q=0.3

---

# 참고자료

모든 개발자를 위한 HTTP 웹 기본 지식 - 김영한

https://www.w3.org/blog/2006/02/content-negotiation/