콘텐츠 협상

콘텐츠 협상이란 사용자 에이전트가 자신의 능력에 가장 적합한 버전을 지정할 수 있도록 동일한 URI에서 서로 다른 버전의 문서(또는 보다 일반적으로 자원의 표현)를 제공할 수 있도록 HTTP의 일부로 정의한 메커니즘을 말한다. 이 메커니즘의 한 가지 일반적인 용도는 이미지를 GIF 또는 PNG 형식으로 제공하는 것이다. 따라서 PNG 이미지를 표시할 수 없는 브라우저(예: MS Internet Explorer 4)가 GIF 버전을 제공한다.

자원은 여러 가지 다른 표현으로 사용할 수 있다. 예를 들어, 다른 언어 또는 다른 미디어 유형으로 사용할 수 있다. 가장 적절한 선택을 선택하는 한 가지 방법은 사용자에게 인덱스 페이지를 부여하고 가장 적절한 선택을 하도록 하는 것이지만, 종종 일부 선택 기준에 따라 선택을 자동화하는 것이 가능하다.

메커니즘

HTTP는 서버 기반(또는 사전 예방), 에이전트 기반(또는 사후 대응), 투명 및/또는 하이브리드 결합을 포함한 몇 가지 다른 콘텐츠 협상 메커니즘을 제공한다.

서버 중심

서버 중심 또는 사전 예방적 콘텐츠 협상은 가능한 변형 표현 중 하나를 선택하는 서버의 알고리즘에 의해 수행된다. 이는 일반적으로 사용자 에이전트가 제공한 허용 기준에 기초하여 수행된다.

이것이 어떻게 작동하는지 요약하자면, 사용자 에이전트가 서버에 요청을 제출할 때, 사용자 에이전트는 서버에 미디어의 종류나 내용을 얼마나 잘 이해하는지에 대한 등급으로 자신이 이해하고 있는 콘텐츠 표시의 다른 측면을 알려준다. 보다 정확히 말하면, 사용자 에이전트는 자원의 허용 가능한 측면과 그 질적 요인을 나열하는 HTTP 헤더를 제공한다. 그러면 서버는 사용자 에이전트의 요구에 가장 적합한 리소스 버전을 제공할 수 있다.

예를 들어, 브라우저는 독일어로 정보를 원한다는 것을 나타낼 수 있다. Accept-Language 다음과 같은 경우:

Accept-Language: de

브라우저는 가능하다면 독일어를 선호한다고 대신 말할 수 있지만, 영어 또한 다음을 설정함으로써 허용된다.

Accept-Language: de; q=1.0, en; q=0.5

독일어의 'q' - quality - factor가 영어의 q' - quality - factor보다 높은 경우.

여러 HTTP 헤더는 종종 콘텐츠 형식 또는 특히 미디어 유형, 언어 및 리소스의 몇 가지 다른 측면을 위해 함께 제공된다. 일반적으로 사용되는 것 외에 Accept 미디어 유형에 대한 헤더, Accept-Language 언어 협상을 위한 헤더, RFC 7231은 또한 다음과 같이 설명한다. Accept-Charset & Accept-Encodings 각각 문자 인코딩 및 내용 코드(코딩)의 경우.

보다 복잡한 요청의 예로는 위에서와 같이 독일어가 선호되지만 영어가 허용된다는 것을 나타내는 언어와 형식에 관한 HTML에 관한 헤더를 브라우저가 보내는 경우를 들 수 있다.text/html)는 다른 텍스트 유형보다 선호된다(text/*) , GIF (image/gif) 또는 JPEG(image/jpg) 이미지는 다른 이미지 형식보다 선호된다(image/*그러나 다른 미디어 유형(*/*)는 최후의 수단으로 받아들여진다.

수락 언어: de; q=1.0, en; q=0.5 수락: text/html, q=1.0, text/*, q=0.8, image/gif, q=0.6, image/jpeg, q=0.6, image/*, q=0.5, */*; q=0.1 

RFC 7231에 명시된 컨텐츠 유형별, 언어별 서버 주도 컨텐츠 협상 측면 외에도, 컨텐츠 교섭의 다른 측면을 정의하는 확장도 있다. Accept-Datetime 특정 시점의^[1] 리소스 표현 버전과 IETF/W3C의 프로파일별^[2] 컨텐츠 협상을 검색하는 헤더 Accept-Profile 데이터 프로파일에 적합한 리소스 표현을 검색하는 헤더.

RFC 7231이나 프로파일별 컨텐츠^[2] 협상과 같은 최신 관련 규격은 상이한 헤더가 상충되는 요구사항을 지정하는 경우, 예를 들어, 영어로 된 HTML 페이지와 독일어로 된 GIF 이미지 중 하나를 선택하는 경우, 트레이드오프를 해결하는 방법을 명시하지 않는다.

에이전트 주도

에이전트 주도형 또는 대응형 콘텐츠 협상은 가능한 변형 표현 중 하나를 선택하는 사용자-에이전트의 알고리즘에 의해 수행된다. 이것은 일반적으로 서버가 제공한 표현 목록과 그것에 대한 메타데이터에 기초하여 수행된다.

이를 요약하면, 사용자 에이전트가 서버에 요청을 제출할 때, 서버는 각 표현(예: 콘텐츠 유형, 품질, 언어 등)에 대해 가지고 있는 메타데이터뿐만 아니라 자신이 사용할 수 있는 표현을 사용자 에이전트에게 알려준다. 그런 다음 사용자 에이전트는 선택한 표현을 위해 특정 URL에 요청을 다시 제출한다. 이것은 사용자-에이전트에 의해 자동으로 선택되거나 사용자-에이전트가 사용자에게 선택사항을 제공할 수 있으며 사용자가 직접 선택할 수 있다. 더 정확히 말하면, 서버는 300 Multiple Choice 또는 406 Not Acceptable로 응답한다(서버 구동, 사용자 에이전트 제공 허용 기준이 제공되지만 서버가 자동으로 선택할 수 없는 경우). 불행히도 HTTP는 선택 메커니즘과 함께 표현 및 메타데이터 목록 형식을 지정하지 않은 채로 남겨둔다.

참조

외부 링크

• RFC 7231 - 하이퍼텍스트 전송 프로토콜(HTTP/1.1): 의미론 및 내용 – (제5.3절: 내용 협상)
• RFC 2295 — HTTP의 투명 콘텐츠 협상
• RFC 2296 - HTTP 원격 변종 선택 알고리즘 - RVSA/1.0
• 아파치 콘텐츠 협상
• 오픈 소스 PHP 콘텐츠 협상 라이브러리(와일드카드 및 q 값 지원)
• XHTML이 컨텐츠 협상과 관련된 문제 및 이를 요구하는 브라우저 문제에 대한 논의

이 기사는 아파치 재단이 저작권을 갖고 있지만 무료 라이선스 하에 발매되는 이 페이지에 부분적으로 기반을 두고 있다.