<?xml version="1.0" encoding="iso-2022-jp"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Apache Content Negotiation</title>
  </head>
  <!-- English revision: 1.29 -->
  <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  <body bgcolor="#ffffff" text="#000000" link="#0000ff"
  vlink="#000080" alink="#ff0000">
        <div align="CENTER">
      <img src="images/sub.gif" alt="[APACHE DOCUMENTATION]" /> 

      <h3>Apache HTTP Server</h3>
    </div>


    <h1 align="center">コンテントネゴシエーション</h1>

    <p>Apache のコンテントネゴシエーションのサポートは HTTP/1.1
    の規格に合うように
    更新されました。それにより、ブラウザにより提供されたメディアタイプ、
    言語、キャラクタセットと、エンコーディングの優先順位を用いてリソースの
    一番良い表現方法を選択できます。また、不完全なネゴシエーション用の情報を
    送ってくるブラウザからのリクエストをより優雅に扱うための機能を
    いくつか実装しています。</p>

    <p>コンテントネゴシエーションは <a
    href="mod/mod_negotiation.html">mod_negotiation</a>
    モジュールにより
    提供されていて、デフォルトで組み込まれています。</p>
    <hr />

    <h2>コンテントネゴシエーションについて</h2>

    <p>リソースは、幾つか異なった表現で利用できる場合があります。
    たとえば、異なる言語や異なるメディアタイプ、またはそれらの組み合わせで
    利用できるかも知れません。もっとも適した選択をする方法の一つには、
    インデックスページをユーザに見せて、ユーザに選んでもらう方法があります。
    しかし、サーバが自動的に選ぶことができる場合が多くあります。
    これは、ブラウザがリクエスト情報毎の情報の一部に、
    どの表現を嗜好するかを送ることで動作しています。
    たとえばブラウザは、可能ならフランス語で情報を見たい、
    不可能ならその代わりに英語でもよいと、自分の嗜好を知らせることができます。
    ブラウザはリクエストのヘッダで自分の優先傾向を知らせます。
    フランス語の表現だけを要求する場合は、ブラウザは以下を送ります。</p>
<pre>
  Accept-Language: fr
</pre>

    <p>この優先傾向は、選択可能な表現が存在して、
    言語によって様々な表現がある場合にのみ適用される
    ということに注意してください。</p>

    <p>もっと複雑なリクエストの例を挙げましょう。
    このブラウザはフランス語と英語を受け付ける、
    しかしフランス語を好む、そして様々なメディアタイプを受け付けるが、
    プレインテキストや他のタイプよりは HTML を好む、
    他のメディアタイプよりは GIF や JPEG を好む、しかし最終手段として
    他のメディアタイプも受け付ける、というように設定されています。
    </p>
<pre>
  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
</pre>

    <p>Apache 1.2 は HTTP/1.1 の規格で定義されている 'server driven'
    コンテントネゴシエーションをサポートしています。
    Accept, Accept-Language, Accept-Charset, Accept-Encoding
    リクエストヘッダを完全にサポートしています。Apache 1.3.4 は
    RFC 2295 と RFC 2296
    で定義されている実験的なネゴシエーションプロトコルである、
    'transparent' もサポートしています。それらの RFC で定義されている
    'feature negotiation' はサポートしていません。</p>

    <p><strong>リソース</strong>とは URI
    で特定される概念上のもののことです (RFC 2396)。 Apache
    のような HTTP サーバは、その名前空間の中での
    リソースの<strong>表現</strong>へのアクセスを提供します。
    それぞれの表現は定義されたメディアタイプ、文字セット、
    エンコーディング等の付属した、バイト列の形式です。
    それぞれのリソースはある時点で 0 個、1 個、それ以上の表現と
    関連付けられる可能性があります。複数の表現が利用できる場合は、
    リソースは<strong>ネゴシエーション可能である</strong>とされ、
    個々の表現は <strong>variant</strong> と呼ばれます。
    ネゴシエーション可能なリソースの variant が異なる、その状態を指して、
    ネゴシエーションの<strong>次元</strong>と呼びます。</p>

    <h2>Apache におけるネゴシエーション</h2>

    <p>リソースをネゴシエーションするためには、サーバはそれぞれの
    variant についての情報を知っておく必要があります。
    これは以下の二つの方法のどちらかで行われます。</p>

    <ul>
    <li>タイプマップ (<em>すなわち</em>、<code>*.var</code> ファイル)
    を使う方法。これは、variant
    を明示的に挙げているファイルを指定します。</li>

    <li>'Multiviews' を使って、
    サーバが暗黙の内にファイル名にパターン照合を
    行なってその結果から選択する方法。</li>
    </ul>

    <h3>type-map ファイルを使う</h3>

    <p>タイプマップは <code>type-map</code> ハンドラ (もしくは、古い
    Apache の設定に上位互換となるために維持されている mime タイプ
    <code>application/x-type-map</code>)
    に関連付けられたドキュメントです。
    この機能を使うためには、あるファイルの拡張子を
    <code>type-map</code>
    として定義するハンドラを設定ファイルで設定する
    必要があることに注意してください。これは</p>
<pre>
  AddHandler type-map .var
</pre>
    <p>
    をサーバの設定に書くことが一番良い方法です。
    詳細はサンプルの設定ファイルのコメントを参照してください。</p>

    <p>タイプマップファイルにはそれぞれの variant
    についてのエントリがあります。これらのエントリは連続した HTTP
    のヘッダ行から成ります。別の variant のエントリとは空行で
    分けられています。エントリ中に空行があってはいけません。
    マップファイルは全体のエンティティをくっつけた形で始めるのが
    習慣となっています
    (これは要求されているわけではなく、もしあった場合は無視されます)。
    たとえば、マップファイルはこのようになります:</p>
<pre>
  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
</pre>

    <p>variant の品質が違うときは、この画像のように (JPEG, GIF, ASCII
    アートがあります) メディアタイプの "qs"
    パラメータとして指定されます。</p>
<pre>
  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
</pre>

    <p>qs 値の範囲は 0.000 から 1.000 です。qs 値が 0.000 の variant
    は決して選択されないことに注意してください。'qs' 値のない
    variant は qs 値 1.0 を 与えられます。qs
    パラメータはクライアントの能力に関係無く、他の variant 
    と比較したときの variant の相対的な「品質」を示します。たとえば、
    写真を表現しようとしているときは JPEG ファイルの方が普通は
    ASCII ファイルよりも高い品質になります。 しかし、リソースが元々
    ASCII アートで表現されているときは、ascii ファイルの方が
    JPEG ファイルよりも高い品質になります。このように、qs
    は表現されるリソースの性質によって variant
    毎に特有の値を取ります。</p>

    <p>認識されるヘッダの完全な一覧は以下のようになります:</p>

    <dl>
    <dt><code>URI:</code></dt>

    <dd>(与えられたメディアタイプのもので、与えられた content
    encoding でエンコードされた) variant のファイルの URI
    。マップファイルからの相対 URL として解釈されます。
    同じサーバ上にある必要があり、
    直接要求されたときにクライアントがアクセスを
    認められているファイルを参照していなければなりません。</dd>

    <dt><code>Content-Type:</code></dt>

    <dd>メディアタイプ --- charset, level, "qs"
    パラメータを指定することができます。これらはしばしば MIME
    タイプと呼ばれます。典型的なメディアタイプは
    <code>image/gif</code>, <code>text/plain</code>,
    <code>text/html;&nbsp;level=3</code> です。</dd>

    <dt><code>Content-Language:</code></dt>

    <dd>RFC 1766 のインターネット標準言語タグで指定された、variant
    の言語。 (<em>たとえば</em>、英語は
    <code>en</code>、 韓国語は <code>kr</code>,
    <em>等</em>)。</dd>

    <dt><code>Content-Encoding:</code></dt>

    <dd>生のデータではなく、ファイルが圧縮されていたり、
    エンコードされたりしているときに、
    どのようにそれがなされているかを指定します。
    Apache は <a href="mod/mod_mime.html#addencoding">AddEncoding</a>
    ディレクティブで定義されたエンコーディングのみを認識します。通常は
    compress されたファイルのための <code>x-compress</code> や
    gzip されたファイルのための <code>x-gzip</code>
    のようなエンコーディングを含みます。
    エンコーディングの比較時には接頭辞 <code>x-</code>
    は無視されます。</dd>

    <dt><code>Content-Length:</code></dt>

    <dd>ファイルのサイズ。タイプマップで content length を指定すると、
    サーバが実際のファイルを調べずに
    ファイルのサイズを比較することができます。</dd>

    <dt><code>Description:</code></dt>

    <dd>人間が読める variant を説明した文章。Apache が適切な variant
    を見つけられなかった場合は、すべての可能な variant
    の一覧を挙げるエラー応答を返します。その variant
    一覧は人間が読める variant の 説明を含みます。</dd>
    </dl>

    <h3>Multiviews</h3>

    <p><code>MultiViews</code> はディレクトリ毎のオプションで、
    <code>&lt;Directory&gt;</code>, <code>&lt;Location&gt;</code>,
    <code>&lt;Files&gt;</code> や、(<code>AllowOverride</code>
    が適切な値に設定されていると) <code>.htaccess</code>
    ファイルで <code>Options</code>
    ディレクティブによって設定することができます。<code>Options
    All</code> は <code>MultiViews</code>
    を設定しないことに注意してください。
    明示的にその名前を書く必要があります。</p>

    <p><code>MultiViews</code> の効果は以下のようになります:
    サーバが <code>/some/dir/foo</code> へのリクエストを受け取り、
    <code>/some/dir/foo</code> が存在<em>しない</em>場合、
    サーバはディレクトリを読んで、<code>foo.*</code>
    にあてはまるすべてのファイルを探し、
    事実上それらのファイルをマップするタイプマップを作ります。
    そのとき、メディアタイプとコンテントエンコーディングは、
    そのファイル名を直接指定したときと同じものが割り当てられます。
    それからクライアントの要求にもっとも合うものを選び、
    そのドキュメントを返します。</p>

    <p>サーバがディレクトリの索引を作ろうとしていると、
    <code>MultiViews</code> は <code>DirectoryIndex</code>
    ディレクティブで指定された名前の探索にも適用されます。
    設定ファイルに</p>

<pre>
  DirectoryIndex index
</pre>

    <p>が書かれていて、<code>index.html</code> と
    <code>index.html3</code> が両方存在していると、
    サーバはその中から毎回どちらかを適当に選びます。
    もしその両方が存在せずに <code>index.cgi</code>
    が存在していると、サーバはそれを実行します。</p>

    <p>ディレクトリを読んでいるときに見つかったファイルに CGI
    スクリプトがあった場合は、何が起こるべきかは自明ではありません。
    そのような場合はコードは特別な扱いをしています。リクエストが
    POST か QUERY_ARGS や PATH_INFO のある GET
    の場合は、スクリプトに非常に高い品質が与えられ、
    通常それが起動されます。その他のリクエストのときは、スクリプトには
    非常に低い品質が与えられ、他のものが(もしあれば)取得されます。</p>

    <h2>ネゴシエーション方法</h2>

    <p>Apache がタイプマップファイルかディレクトリのファイル名から
    リソースの variant の一覧を取得したら、「最善」の variant
    を選ぶために 二つの方法のどちらかを起動します。Apache
    のコンテントネゴシエーションの機能を使うために、
    どのようにネゴシエーションが行なわれるかの詳細を知る必要は
    ありません。
    しかし、これ以降では関心のある人のためにその方法を説明します。</p>

    <p>ネゴシエーション方法は二つあります。</p>

    <ol>
    <li>通常は <strong>Apache のアルゴリズムを用いた Server
    driven negotiation</strong> が使用されます。Apache
    のアルゴリズムは後で詳細に説明されています。
    このアルゴリズムが使用された場合、Apache
    はより良い結果になるように、特定の次元において品質の値を
    「変える」ことができます。Apache
    が品質の値を変える方法は後で詳細に説明されています。</li>

    <li>RFC 2295
    で定義されている機構を用いてブラウザが特に指定した場合、
    <strong>transparent content negotiation</strong>
    が使用されます。このネゴシエーション方法では、ブラウザが「最善」の
    variant の決定を完全に制御することができます。
    ですから、結果はブラウザが使用しているアルゴリズムに依存します。
    Transparent negotiation の処理の過程で、ブラウザは RFC 2296
    で定義されている 'remote variant selection algorithm'
    を実行するように頼むことができます。</li>
    </ol>

    <h3>ネゴシエーションの次元</h3>

    <table>
      <tr valign="top">
        <th>Dimension</th>

        <th>Notes</th>
      </tr>

      <tr valign="top">
        <td>メディアタイプ</td>

        <td>Accept ヘッダフィールドでブラウザにより示される。
        それぞれの項目は品質係数を持つことが出来ます。
        variant の説明にも品質係数 ("qs"
        要素)を持つことができます</td>
      </tr>

      <tr valign="top">
        <td>言語</td>

        <td>Accept-Language ヘッダフィールドでブラウザにより示される。
        それぞれの項目は品質係数を持つことが出来ます。
        variants は 0, 1, またはそれ以上の言語と関連づけることができます。
        </td>
      </tr>

      <tr valign="top">
        <td>エンコーディング</td>

        <td>Accept-Encoding ヘッダフィールドでブラウザにより示される。
        それぞれの項目は品質係数を持つことが出来ます。</td>
      </tr>

      <tr valign="top">
        <td>キャラクタセット</td>

        <td>Accept-Charset ヘッダフィールドでブラウザにより示される。
        それぞれの項目は品質係数を持つことが出来ます。Variants
        でもメディアタイプの要素としてキャラクタセットを示すことが出来ます。
        </td>
      </tr>
    </table>

    <h3>Apache のネゴシエーションアルゴリズム</h3>

    <p>ブラウザに返す「最適な」variant を（もしあれば）選択するように Apache
    は次のアルゴリズムを使うことができます。このアルゴリズムは
    未だ設定可能なものではありません。次のように動作します:</p>

    <ol>
      <li>まずはじめに、ネゴシエーションの次元それぞれについて適切な
      <em>Accept*</em> ヘッダフィールドをチェックして、variant
      それぞれに品質を割り当てます。もしある次元の <em>Accept*</em>
      ヘッダでその variant が許容できないと暗示されていれば、それを削除します。
      variants が一つも残っていなければ、ステップ 4 に行きます。</li>

      <li>消去法で「最適な」 variant を選びます。
      次のテストが順番に適応されます。テストで選択されなかった
      variant は削除されていきます。テスト後 variant
      が唯一残っていれば、それを最適なものとしてステップ 3 に進みます。
      variant が複数残っていれば、次のテストに進みます。

      <ol>
        <li>variant のメディアタイプの品質数値と Accept
        ヘッダの品質数値との積を計算して、最高値の variant
        を選びます。</li>

        <li>言語品質数値が最高の variant を選びます。</li>

        <li>(もしあれば) Accept-Language ヘッダの言語順か、
        (もしあれば) <code>LanguagePriority</code> 
        ディレクティブの言語順で最適な言語の variant を選びます。
        </li>

        <li>最高「レベル」のメディアパラメータ (text/html
        メディアタイプのバージョンを与えるために使われます)を持つ
        variant を選びます。</li>

        <li>Accept-Charset ヘッダ行で与えられている最高の文字セット
        メディアパラメータを持つ variant を選びます。明示的に除外
        されていない限り、ISO-8859-1 が許容されるようになっています。
        <code>text/*</code> メディアタイプであるけれども
        特定の文字セットに明示的に関連づけられているわけではない
        variant は ISO-8859-1 であると仮定されます。</li>

        <li>ISO-8859-1 <em>ではない</em>文字セットメディアパラメータと
        関連づけられている variant を選びます。そのような variant
        がない場合は、代わりにすべての variant を選びます。</li>

        <li>最適なエンコーディングの variant を選びます。もし user-agent
        が許容するエンコーディングがあれば、その variant のみを選びます。
        そうではなく、もしエンコードされたものとそうでない
        variant が混ざって存在していたらエンコードされていない variant
        のみを選びます。 variant がすべてエンコードされているか variant
        がどれもエンコードされていないという場合は、すべての variant
        を選びます。</li>

        <li>内容の最も短い variant を選びます。</li>

        <li>残っている variant の最初のものを選びます。
        タイプマップファイルの最初にリストされているか、
        variant がディレクトリから最初に読み込まれる時に ASCII
        順でソートしてファイル名が先頭になったか、のどちらかです。</li>
      </ol>
      </li>

      <li>アルゴリズムを使って一つの「最適な」variant
      を選びましたので、それを応答として返します。
      ネゴシエーションの次元を指定するために HTTP レスポンスヘッダ
      Vary が設定されます (リソースのキャッシュをする時に、
      ブラウザやキャッシュはこの情報を使うことができます)。
      以上で終わり。</li>

      <li><p>ここに来たということは、variant が一つも選択されなかった
      (ブラウザが許容するものがなかったため) ということです。406 ステータス
      ("No Acceptable representation" を意味する) が、利用可能な variant
      のリストのついた HTML ドキュメントとともに返されます。
      変化の次元を示す HTTP Vary ヘッダも設定されます。</p>

      <p>Apacheにより返されるエラーメッセージが必要以上に簡明で、
      (同等の内容を提示しているけれども、)
      ユーザが混乱する原因になることに留意すべきです。
      もしユーザがこのエラーページを見ることを避けたい場合は、
      標準の言語の(また、標準のエンコーディング等を添えた)
      文書を置いておくことで、もしブラウザから要求された言語や
      エンコーディング等が使えなかった場合は常にそれが返されます。</p>

      <p>ブラウザから要求された言語の文書がどれも得られない時に
      デフォルト言語の文書を返したい場合は、
      言語属性セットなしの文書を作成してください。詳細は後の
      <a href="#nolanguage">Variants with no Language</a>
      参照。</p></li>
    </ol>

    <h2><a id="better" name="better">品質の値を変える</a></h2>
    <!-- 訳注：betterは修正予定？英語版に追従すべし -->

    <p>上記の Apache
    ネゴシエーションアルゴリズムの厳格な解釈で得られるであろう値から、
    Apache は品質数値を時々変えます。完全ではない、
    あるいは正確でない情報を送るブラウザ向けのアルゴリズムで、
    よりよい結果を得るために行われます。かなりポピュラーなブラウザで、
    もしないと間違った variant を選択する結果になってしまうような
    Accept ヘッダ情報を送るものもあります。
    ブラウザが完全で正しい情報を送っていれば、
    この数値変化は適用されません。</p>

    <h3>メディアタイプとワイルドカード</h3>

    <p>Accept: リクエストヘッダはメディアタイプの優先傾向を指定します。
    これはまた、"image/*" や "*/*"
    といった「ワイルドカード」メディアタイプを含むことができます。
    ここで * は任意の文字列にマッチします。ですから、次の:</p>
<pre>
  Accept: image/*, */*
</pre>
    を含むリクエストは、"image/" ではじまるタイプすべてが許容できる、
    そして他のどんなタイプも許容できる (この場合はじめの "image/*"
    は冗長になります) ことを示します。
    扱うことのできる明示的なタイプに加えて、
    ルーチンのようにワイルドカードを送るブラウザもあります。たとえば:
<pre>
  Accept: text/html, text/plain, image/gif, image/jpeg, */*
</pre>
    こうすることの狙いは、明示的にリストしているタイプが優先されるけれども、
    異なる表現が利用可能であればそれでも良い、ということです。
    しかしながら基本的なアルゴリズムでは、上に示したように、*/*
    ワイルドカードが他のすべてのタイプと全く同等なので優先されません。
    ブラウザは */* にもっと低い品質 (優先) 
    値を付けてリクエストを送るべきなのです。たとえば:
<pre>
  Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01
</pre>
    明示的なタイプには品質数値が付けられていませんので、デフォルトの
    1.0 (最高値) の優先になります。ワイルドカード */* は低い優先度
    0.01 を与えられているので、明示的にリストされているタイプに合致する
    variant がない場合にのみ、他のタイプが返されます。

    <p>もし Accept: ヘッダが q 値を全く含んで<em>いなければ</em>、
    望みの挙動をするために、Apache は "*/*" があれば 0.01 の q
    値を設定します。また、"type/*" の形のワイルドカードには 0.02 の q
    値を設定します (ですからこれらは "*/*" のマッチよりも優先されます)。
    もし Accept: ヘッダ中のメディアタイプのどれかが q 値を含んでいれば、
    これらの特殊な値は適用<em>されず</em>、正しい情報を送るブラウザからの
    リクエストは期待通りに動作しはじめます。</p>

    <h3><a id="nolanguage" name="nolanguage">言語属性のない variant</a></h3>

    <p>もし特定のリソースの variant のうちのいくつかが言語属性を持っていて
    いくつかは持っていない場合は、それらの言語属性を持たない variant
    には 0.001 という非常に低い品質係数が与えられます</p>

    <p>この言語属性を持たない variant に 0.001
    という非常に低い品質係数が与えられるという設定の理由は 
    ブラウザの言語設定に合う variant が一つもなかったときに標準の
    variant を適用することを可能にするためです。これにより、
    リクエストされたリソースに対して、用意していない言語だけを accept
    するように設定されたブラウザのユーザが "406"
    エラーページを見るのを避けることが可能になります。</p>
 
    <p>たとえば Multiviews が有効で variants
    が三つある状況を考えます。</p>

    <ul>
    <li>foo.en.html, language en</li>

    <li>foo.fr.html, language en</li>

    <li>foo.html, no language</li>
    </ul>

    <p>言語属性のない variant の意味は常にブラウザに適応することです。
    リクエストが <code>foo</code> で Accept-Language ヘッダに en
    または fr (またはその両方) が含まれる場合、foo.en.html か
    foo.fr.html のどちらかが返されます。ブラウザが許容するものとして
    en と fr のどちらも挙げられていない場合は代わりに foo.html 
    が返されます。クライアントが <code>foo.html</code>
    をリクエストした場合は完全に一致するのでネゴシエーションは発生せず、
    それ自体が返されます。この問題を避けるには、「言語のない」 variant
    として <code>foo.html.html</code> という名前を付けることが Multiviews
    そして言語ネゴシエーションが動作するための保険として
    役立つことが時々あります。</p>

    <h2>Transparent Content Negotiation の拡張</h2>
    Apache は transparent content negotiation プロトコル (RFC 2295)
    を次のように拡張しています。特定のコンテントエンコーディング
    のみが利用可能である variant に印を付けるために、新たに
    <code>{encoding ..}</code> 要素を variant リスト中に使うことができます。
    リスト中のエンコードされた variant を認識できて、Accept-Encoding
    リクエストヘッダに従って許容されるエンコードをもった variant
    は、どれでも候補 variant として使用できるようにするために、
    RVSA/1.0 アルゴリズム (RFC 2296) の実装が拡張されました。
    RVSA/1.0 の実装では、最適な variant が見つかるまで、
    計算した品質数値は小数点以下 5 桁まで丸めません。

    <h2>リンクと名前の変換に関する注意点</h2>

    <p>言語ネゴシエーションを使っている場合は、ファイルが一つ以上の拡張子を持てて、
    拡張子の順番には関連性が通常はない (詳細は
    <a href="mod/mod_mime.html#multipleext">mod_mime</a> を参照)
    ので、幾つかの異なる名前の変換を選べることになります。</p>

    <p>典型的なファイルでは、MIME タイプ拡張子 (<em>たとえば</em>
    <samp>html</samp>) を持っていて、エンコーディング拡張子
    (<em>たとえば</em> <samp>gz</samp>) を持っているかもしれないし、
    このファイルに異なる言語 variant を用意していれば、もちろん言語拡張子
    (<em>たとえば</em> <samp>en</samp>) を持っているでしょう。</p>

    <p>例:</p>

    <ul>
    <li>foo.en.html</li>

    <li>foo.html.en</li>

    <li>foo.en.html.gz</li>
    </ul>

    <p>正しいリンク、不正なリンクの両方のファイル名の例を挙げます:</p>

    <table border="1" cellpadding="8" cellspacing="0">
      <tr>
        <th>ファイル名</th>

        <th>正解のリンク</th>

        <th>不正解のリンク</th>
      </tr>

      <tr>
        <td><em>foo.html.en</em></td>

        <td>foo<br />
         foo.html</td>

        <td>-</td>
      </tr>

      <tr>
        <td><em>foo.en.html</em></td>

        <td>foo</td>

        <td>foo.html</td>
      </tr>

      <tr>
        <td><em>foo.html.en.gz</em></td>

        <td>foo<br />
         foo.html</td>

        <td>foo.gz<br />
         foo.html.gz</td>
      </tr>

      <tr>
        <td><em>foo.en.html.gz</em></td>

        <td>foo</td>

        <td>foo.html<br />
         foo.html.gz<br />
         foo.gz</td>
      </tr>

      <tr>
        <td><em>foo.gz.html.en</em></td>

        <td>foo<br />
         foo.gz<br />
         foo.gz.html</td>

        <td>foo.html</td>
      </tr>

      <tr>
        <td><em>foo.html.gz.en</em></td>

        <td>foo<br />
         foo.html<br />
         foo.html.gz</td>

        <td>foo.gz</td>
      </tr>
    </table>

    <p>上の表を見て、拡張子なしのリンク (<em>たとえば</em> <samp>foo</samp>) 
    がいつでも使えることに気が付くでしょう。この利点は、
    ドキュメントとして応答するファイルの実際のファイルタイプを隠蔽して、
    リンクの参照を変更することなく後からファイルを変更できる、
    <em>たとえば</em> <samp>html</samp> から <samp>shtml</samp>
    に、あるいは <samp>cgi</samp> に変更できる点です。</p>

    <p>リンクに MIME タイプを使い続けたい (<em>たとえば</em>
    <samp>foo.html</samp>)時は、言語拡張子は
    (エンコーディング拡張子もあればそれも含めて)
    MIME タイプ拡張子の右側になければなりません
    (<em>たとえば</em> <samp>foo.html.en</samp>)。</p>

    <h2>キャッシュに関する注意事項</h2>

    <p>キャッシュがある表現を保存しているときは、リクエスト URL
    と関連づけられています。次にその URL がリクエストされた時に、
    キャッシュは保存されている表現を使用できます。しかし、リソースが
    サーバでネゴシエーション可能であれば、最初のリクエストでキャッシュされて続く
    キャッシュヒットでは間違った応答を返してしまうということになりかねません。
    これを防ぐために、Apache はコンテントネゴシエーションの
    後に返された応答すべてに、HTTP/1.0 クライアントでの
    non-cacheable とマークします。また、ネゴシエーションされた応答のキャッシュ
    を可能にする HTTP/1.1 プロトコルの機能も Apache はサポートします。</p>

    <p>HTTP/1.0 準拠のクライアントからのリクエストに対しては、
    (ブラウザであろうとキャッシュであろうと) ネゴシエーション
    を受けた応答のキャッシュを許すために、<code>CacheNegotiatedDocs</code>
    ディレクティブを使用できます。このディレクティブは、
    主サーバ設定やバーチャルホストで与えられて、引数をとりません。
    HTTP/1.1 クライアントからのリクエストには効力を持ちません。</p>
        <hr />

    <h3 align="CENTER">Apache HTTP Server</h3>
    <a href="./"><img src="images/index.gif" alt="Index" /></a>

  </body>
</html>

