Content Negotiation

Content Negotiation

• 통신 방법을 최적화하고자 하나의 요청 안에서 서버와 클라이언트가 서로 최고의 설정을 공유한느 시스템을 의미
• 헤더를 이용

협상 대상과 헤더

요청 헤더	응답	협상 대상
Accept	Content-Type 헤더	MIME 타입
Accept-Language	Content-Language 헤더/HTML태그	표시 언어
Accept-Charset	Content-Type 헤더	문자의 문자셋
Accept-Encoding	Content-Encoding 헤더	바디 압축

1) 파일의 종류 결정

구글 크롬의 요청 헤더 중 일부
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/web,*/*;q=0.8

• image/web
• */*l;q=0.8
• q는 품질 계수라는 것으로 0~1까지의 수치로 설정
  • 기본은 1.0이고 이때는 q가 생략됨
  • 우선 순위를 나타냄 (웹 서버가 WebP를 지원하면 WebP를, 그렇지 않으면 PNG 등 다른 포맷(우선순위0.8)을 서버에 보낼 것을 요구하고 있음)
  • 서버는 요청한 형식 중에서 파일을 반환
  • 우선 순위를 해석해 위에서부터 차례로 지원하는 포맷을 찾고, 일치하면 그 포맷을 변환
  • 만약 일치하는 형식이 없으면 서버가 406 Not Acceptible 오류를 반환

2) 표시 언어 결정

• 클라이언트가 지원하는 언어 종류를 나타냄

  구글 크롬의 요청 헤더 중 일부
  Accept-Language: en-US;en;q=0.8,ko;q=0.6

• en-US는 q가 1.0 (생략)

• en은 q가 0.8

• ko는 q가 0.6

• q값은 클수록 우선순위가 높음

3) 문자셋 결정

구글 크롬의 요청 헤더 중 일부
Accept-Charset: windows-949,utf-8;q=0.7,*;q=0.3

• 어느 모던 브라우저도 Accept-Chartset을 송신하지 않음
• 아마도 브라우저가 모든 문자셋 인코더를 내장하고 있어, 미리 협상할 필요가 없어졌기 때문으로 여겨짐
• 문자셋은 MIME 타입과 세트로 Content-Type 헤더에 실려 통지됨
  Content-Type: text/html; charset=UTF-8
• HTML의 경우, 문서 안에도 쓸 수 있음 (RFC 1866의 HTML/2.0으로 이미 이용할 수 있음)
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"
• HTML5에서는 다음과 같이 표기하 수 도 있음 (meta http-equiv 태그는 http 헤더와 똑같은 지시를 문서 내부에 삽입해서 반환)
  <meta charset="UTF-8">
• 사용할 수 있는 문자셋은 IANA에서 관리

4) 압축

• 통신에 걸리는 시간보다 압축/해제가 짧은 시간에 이루어지므로, 압출을 함으로써 웹페이지를 표시할 때 걸리는 전체적인 처리 시간을 줄일 수 있음
• 콘텐츠 압축 협상은 모두 HTTP의 헤더 안에서 완료한다
• 우선 클라이언트가 수용가능한 압축 방식을 헤더에 지정
  Accept-Encoding: deflate, gzip
• 서버는 전송바은 목록 중 지원하는 방식이 있으면, 응답할 때 그 방식으로 압축하거나, 미리 압축된 콘텐츠를 반환 (gzip인 경우의 예: Content-Encoding: gzip, Content-Length 헤더는 압축된 파일의 크기)
• Content-Encoding으로 콘텐츠 크기를 줄이는 방법 말고도, Transfer-Encoding 헤더로 통신 경로를 압축하는 방법도 규격에 있지만, 그다지 사용되지 않음

Reference

• 책/리얼월드HTTP/ http://www.yes24.com/Product/Goods/71849916