내용협상 (Content Negotiation)

가능한 언어: en | + fr | + ja | + ko | + tr

이 문서는 최신판 번역이 아닙니다. + 최근에 변경된 내용은 영어 문서를 참고하세요.

+ + +

아파치는 HTTP/1.1 규약에 기술된 내용협상(content + negotiation)을 지원한다. 내용협상은 media type, 언어, 문자집합, + 인코딩 등에 대해 브라우저가 제공한 선호도에 따라 자원의 + 가장 적합한 표현을 선택한다. 또 불완전한 협상 정보를 보내는 + 브라우저의 요청을 지능적으로 처리하는 기능도 있다.

+ +

기본적으로 컴파일되는 mod_negotiation + 모듈이 내용협상 기능을 제공한다.

내용협상에 대해
아파치의 협상
협상방법
품질계수 조작하기
자연스러운(transparent) 내용협상의 확장
하이퍼링크와 이름규칙에 대하여
캐쉬에 대하여

참고

Comments

내용협상에 대해

+ +

자원은 여러 다른 표현을 가질 수 있다. 예를 들어, 다른 + 언어나 다른 media type 혹은 둘 모두가 다른 표현들이 있을 + 수 있다. 가장 적당한 표현을 선택하는 한가지 방법은 사용자에게 + 목록 페이지를 보여주고 선택하게 하는 것이다. 그러나 서버가 + 자동으로 선택하는 것도 가능하다. 이는 브라우저가 요청의 + 일부로 그들이 선호하는 표현에 대한 정보를 보내기때문에 + 가능하다. 예를 들어, 브라우저는 가능한한 불어로, 그러나 + 없다면 영어로 정보를 보고싶다고 알려줄 수 있다. 브라우저는 + 요청의 헤더로 그들의 기호를 나타낸다. 오직 불어로된 표현만을 + 요청한다면 브라우저는 다음과 같이 보낸다.

+ +

Accept-Language: fr

+ +

이런 기호는 표현이 언어별로 다를 경우에만 고려된다.

+ +

다음은 더 복잡한 요청의 예로 브라우저가 불어와 영어를 + 받을 수 있지만, 불어를 더 선호하고, 여러 media type을 받을 + 수 있지만, 일반 텍스트 보다는 HTML, 다른 media type 보다는 + GIF와 JPEG을 선호한다고 알려준다.

+ +

+ Accept-Language: fr; q=1.0, en; q=0.5 + Accept: 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 +

+ +

아파치는 HTTP/1.1 규약에 정의된 '서버 주도(server driven)' + 내용협상을 지원한다. 아파치는 Accept, + Accept-Language, Accept-Charset, + Accept-Encoding 요청 헤더를 모두 지원한다. + 또, 아파치는 RFC 2295와 RFC 2296에 정의된 실험적인 내용협상인 + '자연스러운(transparent)' 요청 헤더도 지원한다. 그러나 이 + RFC에 정의된 '기능 협상(feature negotiation)'은 지원하지 + 않는다.

+ +

자원(resource)은 (RFC 2396) URI로 구별하는 + 개념적인 존재다. 아파치와 같은 웹서버는 자원의 + 표현(representations)을 제공한다. 표현은 + 지정된 media type, 문자집합, 인코딩 등을 가진 바이트들로 + 되있다. 자원은 여러 표현과 (때로는 없을 수도 있다) 연관된다. + 자원에 여러 표현이 있다면 자원을 + 협상가능하다고(negotiable) 부르며, 이때 + 각 표현을 변형(variant)이라고 한다. + 협상가능한 자원의 변형 종류를 협상의 + 범위(dimension)라고 한다.

아파치의 협상

+ +

자원을 협상하기위해 서버는 각 변형에 대한 정보가 필요하다. + 다음 두가지 방법중 하나로 정보를 얻는다:

+ +

변형을 담은 파일들을 직접 열거한 type map을 (예를 + 들어, *.var 파일) 사용하거나,
직접 지정하지않아도 서버가 파일명에서 규칙을 찾아서 + 결과를 선택하는 'MultiViews'를 사용한다.

+ +

type-map 파일 사용하기

+ +

type map은 type-map이란 핸들러와 연결된 + (혹은 이전 아파치 설정과 호환을 위해 MIME type이 + application/x-type-map인) 문서다. 이 기능을 + 사용하려면 설정에서 type-map 핸들러에 대한 + 파일 확장자를 지정해야 한다. 서버 설정파일에 다음과 같이 + 설정하는 것이 좋다.

+ +

AddHandler type-map .var

+ +

Type map 파일은 해당하는 자원과 이름이 같아야 하고, + 각 변형에 대한 항목이 있어야 한다. 항목은 여러 HTTP형식 + 헤더 줄로 구성된다. 변형에 대한 각각의 항목들은 빈줄로 + 구분한다. 항목안에서 빈줄을 사용할 수 없다. (이렇게 할 + 필요가 없고, 있어도 무시하지만) 여러 항목이 공통으로 가지고 + 있는 내용으로 map 파일을 시작하는 것이 보통이다. 다음은 + map 파일 예다. 이 파일의 이름은 foo.var로, + foo라는 자원을 설명한다.

+ +

+ URI: foo + + URI: foo.en.html + Content-type: text/html + Content-language: en + + URI: foo.fr.de.html + Content-type: text/html;charset=iso-8859-2 + Content-language: fr, de +

typemap 파일이 파일명 확장자 보다, 심지어 Multiviews를 + 사용하여도, 우선권을 가짐을 주의하라. 변형이 서로 다른 품질을 + 가진다면, 다음과 같이 (JPEG, GIF, ASCII-art에 해당하는) + media type에 "qs" 파라미터로 품질(source quality)을 표시할 + 수 있다:

+ +

+ URI: foo + + URI: foo.jpeg + Content-type: image/jpeg; qs=0.8 + + URI: foo.gif + Content-type: image/gif; qs=0.5 + + URI: foo.txt + Content-type: text/plain; qs=0.01 +

+ +

qs 값은 0.000에서 1.000 사이다. qs 값이 0.000인 변형은 + 절대 선택되지 않음을 주의하라. 'qs' 값이 없는 변형은 1.0으로 + 취급된다. qs 값은 클라이언트의 능력과는 관계없이 다른 변형들과 + 비교하여 그 변형의 상대적인 '품질'을 나타낸다. 예를 들어, + 사진을 나타내려는 경우 JPEG 파일이 ASCII 파일보다는 항상 + 높은 품질을 가진다. 그러나 자원이 원래 ASCII art였다면 + ASCII 표현이 JPEG 표현보다 더 높은 품질을 가질 수 있다. + 그러므로 어떤 변형의 qs 값은 표현하려는 자원의 성질에 + 따라 다르다.

+ +

지원하는 모든 헤더 목록은 mod_negotation + typemap 문서를 참고하라.

+ + +

Multiviews

+ +

MultiViews는 디렉토리별 옵션이므로, + httpd.conf의 + <Directory>, + <Location>, + <Files> + 섹션 혹은 (AllowOverride가 + 적절히 설정되었다면) .htaccess 파일의 + Options 지시어에 설정할 + 수 있다. Options All은 MultiViews를 + 포함하지않음을 주의하라. 따로 직접 써줘야 한다.

+ +

MultiViews를 사용하면 다음과 같은 일이 일어난다: + 서버가 /some/dir/foo에 대한 요청을 받고 + /some/dir/foo에 MultiViews가 동작하며 + /some/dir/foo가 존재하지 않을 경우, + 서버는 디렉토리에서 이름이 foo.*인 파일들을 모든 포함하는 + 가상의 type map을 만든다. 클라이언트가 요청한 media type과 + content-encoding을 가지고 이중에 가장 적합한 것을 선택한다.

+ +

MultiViews는 서버가 디렉토리를 참조할때 + 파일을 찾는 DirectoryIndex 지시어에도 + 적용된다. 설정파일이 다음과 같다면,

DirectoryIndex index

index.html과 index.html3이 + 모두 있다면 서버는 이둘 중에 하나를 결정한다. 둘 모두 없고 + index.cgi가 있다면, 서버는 그것을 실행한다.

+ +

디렉토리를 읽을때 파일중 하나가 Charset, Content-Type, + Language, Encoding를 판단하는 mod_mime이 모르는 + 확장자를 가진다면, 결과는 MultiViewsMatch 지시어 설정에 + 달렷다. 이 지시어는 핸들러, 필터, 다른 확장형들이 MultiViews + 협상에 참여할지 여부를 결정한다.

+ +

협상방법

+ +

아파치가 type-map 파일이나 디렉토리에 있는 파일명들로 + 주어진 자원에 대한 변형 목록을 얻게되면 '최적의' 변형을 + 결정하기위해 두 방법중 하나를 사용한다. 아파치 내용협상 + 기능을 사용하기위해 정확히 협상이 어떻게 일어나는지 자세히 + 알 필요는 없다. 그러나 궁금한 사람을 위해 이 방법을 설명한다.

+ +

두가지 협상방법이 있다:

+ +

아파치 알고리즘을 사용하여 서버가 주도하는 + 협상은 일반적인 경우에 사용한다. 아파치 알고리즘은 + 아래서 자세히 설명한다. 이 알고리즘을 사용하면 아파치는 + 더 나은 결과를 얻기위해 종종 특정 범위의 + 품질계수(quality factor)를 '조작한다'. 아파치가 품질계수를 + 조작하는 방법은 아래서 자세히 설명한다.
자연스러운(Transparent) 내용협상은 + 브라우저가 RFC 2295에 정의된 방법으로 요청할 경우에만 + 사용한다. 이 협상방법은 '최적의' 변형을 결정할 권한을 + 브라우저에게 부여한다. 그래서 결과는 브라우저의 알고리즘에 + 달렸다. 자연스러운 협상과정중에 브라우저는 아파치에게 + RFC 2296에 정의된 '원격 변형선택 알고리즘(remote variant + selection algorithm)'을 요청할 수 있다.

+ +

협상의 범위

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

범위	설명
Media Type	브라우저는 `Accept` 헤더로 선호를 나타낸다. + 각 항목은 품질계수를 가질 수 있다. 변형의 설명도 품질계수를 + ("qs" 파라미터) 가질 수 있다.
Language	브라우저는 `Accept-Language` 헤더로 선호를 + 나타낸다. 각 항목은 품질계수를 가질 수 있다. 변형은 + 여러 언어를 가질 (혹은 아무 언어도 없을) 수 있다.
Encoding	브라우저는 `Accept-Encoding` 헤더로 선호를 + 나타낸다. 각 항목은 품질계수를 가질 수 있다.
Charset	브라우저는 `Accept-Charset` 헤더로 선호를 + 나타낸다. 각 항목은 품질계수를 가질 수 있다. 변형은 + media type의 파라미터로 문자집합을 나타낼 수 있다.

+ + +

아파치 협상 알고리즘

+ +

아파치는 브라우저에게 보낼 '최적의' 변형을 (있다면) + 선택하기위해 아래 알고리즘을 사용한다. 이 알고리즘은 변경할 + 수 없다. 다음와 같이 동작한다:

+ +

먼저, 협상의 각 범위에 대해 해당하는 Accept* + 헤더를 검사하고, 각 변형에 품질값을 매긴다. 어떤 범위의 + Accept* 헤더가 받아들이지 않는 변형은 후보에서 + 제외한다. 어떤 변형도 남지않으면 4 단계로 간다.
+ 후보에서 하나씩 제외하여 '최적의' 변형을 찾는다. 다음 + 각 검사는 순서대로 일어난다. 각 검사에서 선택되지않은 + 변형은 제외된다. 각 검사후 한 변형만 남으면 이를 최적의 + 변형으로 선택하고 3 단계로 간다. 여러 변형이 남으면 + 다음 검사를 진행한다. + +
1. Accept 헤더의 품질계수와 변형의 + media type에 대한 품질값을 곱하여 가장 높은 값을 + 가진 변형을 선택한다.
2. 가장 높은 언어(language) 품질계수를 가진 변형을 + 선택한다.
3. Accept-Language 헤더에 (있다면) + 나온 언어의 순서 혹은 LanguagePriority + 지시어에 (있다면) 나온 언어의 순서를 가지고 가장 + 적합한 언어를 가진 변형을 선택한다.
4. 가장 높은 (text/html media type의 버전을 나타내는) + 'level' media 파라미터를 가진 변형을 선택한다.
5. Accept-Charset 헤더를 가지고 가장 + 적합한 charset media 파라미터를 가진 변형을 찾는다. + 헤더가 없다면 ISO-8859-1 문자집합을 가장 선호한다. + text/* media type을 가지지만 명시적으로 + 특정 문자집합과 연결되지않은 변형은 ISO-8859-1로 + 가정한다.
6. ISO-8859-1이 아닌 charset media 파라미터를 + 가진 변형들을 선택한다. 그런 변형이 없다면, 대신 모든 + 변형을 선택한다.
7. 가장 적합한 인코딩을 가진 변형을 선택한다. + user-agent에 적합한 인코딩을 가진 변형이 있다면 그 + 변형만을 선택한다. 그렇지않고 인코딩된 변형과 인코딩안된 + 변형이 같이 있다면 인코딩안됨 변형만을 선택한다. 변형이 + 모두 인코딩되었거나 모두 인코딩안된 경우 모든 변형을 + 선택한다.
8. content length가 가장 적은 변형을 선택한다.
9. 남은 것중 첫번재 변형을 선택한다. 이는 type-map + 파일의 앞에 나왔거나, 디렉토리에서 변형을 읽은 경우 + 파일명을 ASCII 코드 순서로 하여 앞에 나오는 것이다.
+
이제 알고리즘이 '최적의' 변형을 선택했다. 이것을 응답으로 + 보낸다. HTTP 응답 헤더 Vary는 협상의 범위를 + 나타내게 된다. (브라우저와 캐쉬는 자원을 캐쉬할때 이 정보를 + 사용할 수 있다.) 끝.
이 단계에 도달했다면 (모두 브라우저가 받지못하기 때문에) + 어떤 변형도 선택이 안된 경우다. ("No acceptable + representation"를 뜻하는) 상태 406과 내용으로 사용가능한 + 변형의 목록을 담은 HTML 문서를 응답을 보낸다. 또, HTML + Vary 헤더는 변형의 범위를 나타낸다.

+ +

품질계수 조작하기

+ +

아파치는 종종 위의 아파치 협상 알고리즘을 엄격히 지키지않고 + 품질계수를 변경한다. 이유는 완전하고 정확한 정보를 보내지않는 + 브라우저에게 (알고리즘의) 더 나은 결과를 보내기 위해서다. + 널리 쓰이는 브라우저중 일부는 자주 잘못된 변형을 선택하도록 + Accept 헤더를 보낸다. 브라우저가 완전하고 올바른 + 정보를 보낸다면, 조작을 하지않는다.

+ +

Media Type과 와일드카드

+ +

Accept: 요청 헤더는 media type에 대한 선호를 + 나타낸다. 또, *는 어떤 문자열이라도 가능하기때문에 "image/*"나 + "*/*" 같이 '와일드카드' media type을 사용할 수도 있다. 그래서 + 다음과 같은 요청은:

+ +

Accept: image/*, */*

+ +

"image/"로 시작하는 어떤 type과 다른 어떤 type도 가능함을 + 의미한다. 어떤 브라우저는 + 자신이 실제로 다룰 수 있는 type에 추가로 와일드카드를 보낸다. + 예를 들면:

+ +

+ Accept: text/html, text/plain, image/gif, image/jpeg, */* +

이유는 직접 열거한 type을 선호하지만 다른 표현이 있다면 + 그것도 괜찮음을 나타내기 위해서다. 브라우저가 실제로 원한 + 것은 다음과 같이 명시적으로 품질값을 사용한 것이다.

+ Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01 +

직접 열거한 type은 품질계수가 없어서 기본값인 (가장 높은) + 1.0을 가진다. 와일드카드 */*는 낮은 선호도 0.01을 가지므로 + 직접 열거한 type에 맞는 변형이 없는 경우에만 다른 type들이 + 사용된다.

+ +

Accept: 헤더에 q 계수가 전혀 없고 + "*/*"가 있다면, 아파치는 바람직한 행동을 위해 q 값으로 0.01을 + 지정한다. 또, "type/*" 형태의 와일드카드에는 ("*/*"보다는 + 더 선호하도록) 0.02를 지정한다. Accept: 헤더에서 + q 계수를 가지는 media type이 있다면 이런 특별한 값을 추가하지 + 않는다. 그래서 명시적인 정보를 보내는 브라우저의 + 요청은 요청한데로 처리한다.

+ + +

언어(language) 협상의 예외

+ +

아파치 2.0은 언어 협상이 실패한 경우 부드럽게 복구하기위해 + 협상 알고리즘에 새로 예외를 몇개 추가했다.

+ +

클라이언트가 서버에 페이지를 요청했을때 서버가 브라우저가 + 보낸 Accept-language에 맞는 페이지를 단 한개만 + 찾으면 문제가 없지만, 그러지 않은 경우 서버는 클라이언트에게 + "No Acceptable Variant"나 "Multiple Choices" 응답을 보낸다. + 이런 오류문을 피하기위해 이 경우 Accept-language를 + 무시하고 클라이언트의 요청에 명확히 맞지는 않지만 문서를 + 보내도록 아파치를 설정할 수 있다. ForceLanguagePriority + 지시어는 서버가 이런 오류문중 하나 혹은 둘다를 무시하고 + LanguagePriority + 지시어로 판단하도록 한다.

+ +

또, 서버는 맞는 언어를 못찾은 경우 부모언어를 찾을 수도 + 있다. 예를 들어 클라이언트가 영국영어를 뜻하는 + en-GB 언어로 문서를 요청한 경우, HTTP/1.1 표준에 + 따르면 서버는 en으로만 표시된 문서를 일반적으로 + 선택하지 못한다. (그래서 영국영어를 이해하는 독자가 일반적인 + 영어도 이해할 수 있으므로 Accept-Language 헤더에 + en-GB만 포함하고 en을 포함하지않으면 + 거의 확실히 잘못된 설정임을 유의하라. 불행히도 현재 많은 + 클라이언트들은 이런 식으로 기본설정되있다.) 다른 언어를 + 찾지 못하여 서버가 "No Acceptable Variants" 오류를 보내거나 + LanguagePriority로 + 돌아가야 한다면, 서버는 하위언어 규약을 무시하고 + en-GB를 en 문서에 대응한다. + 암묵적으로 아파치는 부모언어를 매우 낮은 품질값으로 + 클라이언트의 허용언어 목록에 추가한다. 그러나 클라이언트가 + "en-GB; q=0.9, fr; q=0.8"을 요청하고 서버에 "en"과 "fr" + 문서가 있다면, "fr" 문서가 선택됨을 주의하라. 이는 HTTP/1.1 + 표준을 지키고, 올바로 설정된 클라이언트와 효율적으로 + 동작하기위함이다.

+ +

사용자가 선호하는 언어를 알아내기위한 (쿠키나 특별한 + URL-경로 같은) 고급 기법을 지원하기위해 아파치 2.0.47부터 + mod_negotiation은 prefer-language라는 + 환경변수를 인식한다. 이 환경변수가 + 존재하고 적절한 언어태그를 포함한다면, + mod_negotiation은 해당하는 변형을 선택하려고 + 시도한다. 그런 변형이 없다면 일반적인 협상과정을 시작한다.

+ +

예제

+ SetEnvIf Cookie "language=(.+)" prefer-language=$1 +

+ +

자연스러운(transparent) 내용협상의 확장

+ +

아파치는 다음과 같이 자연스러운 내용확장 프로토콜을 (RFC 2295) +확장한다. 변형 목록의 새로운 {encoding ..}는 특정 +content-encoding을 가진 변형만을 지칭한다. RVSA/1.0 알고리즘은 +(RFC 2296) 목록에서 인코딩된 변형을 인식할 수 있고, 인코딩이 +Accept-Encoding 요청 헤더에 맞는 경우 인코딩된 +변형들도 후보로 사용하도록 확장되었다. RVSA/1.0 구현은 최적의 +변형을 찾기 전에 계산된 품질계수를 소수점 5자리에서 반올림하지 +않는다.

하이퍼링크와 이름규칙에 대하여

+ +

언어(language) 협상을 사용한다면 파일은 여러 확장자를 + 가지고 확장자의 순서는 보통 관계없으므로 파일명에 여러 다른 + 이름규칙을 사용할 수 있다. (자세한 내용은 mod_mime 문서를 + 참고하라.)

+ +

전형적인 파일은 MIME-type 확장자 (예를 들어, + html), 경우에 따라 encoding 확장자 (예를 + 들어, gz), 파일에 여러 언어 변형이 있는 + 경우 물론 언어 확장자를 (예를 들어, en) + 가진다.

+ +

예제:

+ +

foo.en.html
foo.html.en
foo.en.html.gz

+ +

다음은 몇몇 파일명과 그 파일에 대한 유효하고 유효하지않은 + 하이퍼링크를 보인다:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

파일명	유효한 하이퍼링크	유효하지않은 하이퍼링크
foo.html.en	foo + foo.html	-
foo.en.html	foo	foo.html
foo.html.en.gz	foo + foo.html	foo.gz + foo.html.gz
foo.en.html.gz	foo	foo.html + foo.html.gz + foo.gz
foo.gz.html.en	foo + foo.gz + foo.gz.html	foo.html
foo.html.gz.en	foo + foo.html + foo.html.gz	foo.gz

+ +

위 표를 보면 하이퍼링크에 어떤 확장자도 없는 이름을 + (예를 들어, foo) 항상 사용할 수 있음을 + 알 수 있다. 이 경우 장점은 문서의 실제 종류를 숨길 수 있어서, + 예를 들어 하이러링크 참조를 수정하않고 + html 파일을 shtml이나 + cgi로 변경할 수 있다는 점이다.

+ +

계속 하이퍼링크에 MIME-type을 (예를 들어, + foo.html) 사용하고 싶다면 (encoding 확장자가 + 있다면 이것도 포함하여) 언어 확장자를 MIME-type 확장자보다 + 오른쪽에 (예를 들어, foo.html.en) + 두어야한다.

캐쉬에 대하여

+ +

캐쉬가 표현을 저장하면 표현과 요청 URL을 연관시킨다. + 다음번 그 URL을 요청하면 캐쉬는 저장된 표현을 사용한다. + 그러나 서버와 협상이 가능한 자원인 경우 첫번째 요청한 변형만 + 캐쉬되어 이후 요청은 캐쉬된 잘못된 응답을 얻을 수 있다. + 이를 막기위해 아파치는 보통 내용협상후 반환되는 모든 요청에 + HTTP/1.0 클라이언트가 캐쉬를 못하도록 표시를 한다. 또, 아파치는 + 협상한 응답의 캐쉬를 허용하는 HTTP/1.1 프로토콜의 기능을 + 지원한다.

+ +

CacheNegotiatedDocs + 지시어는 HTTP/1.0 호환 클라이언트(브라우저 혹은 캐쉬)가 + 보낸 요청에 대해 협상한 응답을 캐쉬할 수 있게 한다. 이 지시어는 + 서버나 가상호스트 설정에 사용하며, 아규먼트를 받지않는다. + 이 지시어는 HTTP/1.1 클라이언트의 요청과는 관계가 없다.

+ +

HTTP/1.1 클라이언트에게 아파치는 응답의 협상 범위를 + 알려주는 Vary HTTP 응답헤더를 보낸다. 이 정보를 + 사용하여 다음 요청을 캐쉬된 복사본으로 대체할 수 있는지 + 판단할 수 있다. 헙상의 범위와 관계없이 캐쉬된 복사본을 + 권한다면 force-no-vary 환경변수를 설정한다.

+ +