コンテントネゴシエーション、より正確にはコンテンツの選択機能は、 複数用意されているドキュメントから、クライアントの能力に一番合った ドキュメントを選択する機能です。この実装は二つあります。
type-map
ハンドラで扱われるファイル)。これは variants
を含んでいるファイルを明示的に指定します。MultiViews タイプマップは RFC 822 のメールヘッダに類似した書式です。 ドキュメントの記述が空行で分離されて書かれていて、ハッシュ文字 ('#') で始まる行はコメントとして扱われます。 ドキュメントの説明は複数のヘッダレコードから構成されます。 レコードは、続きの行が空白で始まっていると複数の行にまたがります。 最初の空白が消去されて、前の行とつなげて 1 行として扱われます。 ヘッダレコードはキーワード名の後に値が続くという形式で、 キーワード名は常にコロンで終わります。空白はヘッダ名と値の間、 値のトークンの間に入れることができます。 使用可能なヘッダは以下のとおりです:
Content-Encoding:x-compress と gzip
されたファイルのための x-gzip を含みます。
エンコーディングの比較をするときは、接頭辞 x-
は無視されます。Content-Language:en
は英語を表します。
複数の言語が格納される場合はコンマで区切られます。Content-Length:Content-Type:name=value
で、メディアタイプや他のパラメータとはセミコロンで分離されます。
共通のパラメータは以下のとおり:
leveltext/html では 2 がデフォルトで、その他の場合は
0 がデフォルトです。qsqs
はリソース毎に特有の値を取ります。
URI:Body:MultiViews 探索は、Multiviews /some/dir/foo
へのリクエストを受け取り、/some/dir/foo が存在
しない場合、サーバはディレクトリを読んで、
foo.* にあてはまる全てのファイルを探し、
事実上それらのファイルをマップするタイプマップを作ります。
そのとき、メディアタイプとコンテントエンコーディングは、
そのファイル名を直接指定したときと同じものが割り当てられます。
それからクライアントの要求に一番合うものを選び、
そのドキュメントを返します。
ファイルを選択する際に、関連するコンテントネゴシエーションの
メタ情報を持たないファイルについて、判定を行うかどうかを
このディレクティブが設定されていると、コンテントネゴシエーション をした結果のドキュメントのキャッシュを許可します。 これは、プロキシの後ろにいるクライアントが能力に一番合った ドキュメントではなく、 キャッシュをより効果的にするものを得る可能性があるということです。
このディレクティブは HTTP/1.0 ブラウザからのリクエスト のみに適用されます。HTTP/1.1 は、 交渉されたドキュメントのキャッシュに対してずっとよい制御が可能なので、 このディレクティブは HTTP/1.1 のリクエストには影響しません。
2.0 より前のバージョンでは、
ForceLanguagePriority Prefer は、同等の選択肢が
いくつかあるときに、HTTP の 300 (MULTIPLE CHOICES) を返す代わりに、
LanguagePriority を使って一つだけドキュメントを返すように
します。以下のディレクティブが指定されていて、ユーザの Accept-Language
ヘッダでは en と de の品質が共に
.500 (同じくらい許容) であるときは、
最初にマッチする variant の en が送られます。
ForceLanguagePriority Fallback では、HTTP 406
(NOT ACCEPTABLE) を送信する代わりに、
Accept-Language
が es 言語のみを許可していて、さらにそのような variant がないときには、
以下の
Prefer と Fallback の両方のオプションを
同時に指定することができます。
ですから、複数の variant があるときは
foo.html がリクエストされ、foo.html.fr
と foo.html.de が両方存在し、
ブラウザが言語の優先順位を提供してない場合は
foo.html.fr が返されます。
このディレクティブは他の方法で「最善」
の言語が決定できないときか、None 以外のときにのみ効果があることに注意してください。
一般的には、サーバ側ではなくクライアント側で好みの言語を決定します。