From: Yoshiki Hayashi Apache は HTTP/1.1 の規格に記述されているコンテントネゴシエーションを
+ Apache は HTTP/1.1 の規格に記述されているコンテントネゴシエーションを
サポートしています。
- ブラウザにより提供されたメディアタイプ、
- 言語、文字セット、エンコーディングの優先傾向に基づいて、
+ ブラウザにより提供されたメディアタイプ、
+ 言語、文字セット、エンコーディングの優先傾向に基づいて、
最適なリソースの表現を選択できます。
また、不完全なネゴシエーション情報を送ってくるブラウザからのリクエストを
もっと賢く取り扱えるよう、いくつか機能も実装してあります。 コンテントネゴシエーションは mod_negotiation
- モジュールにより
+ コンテントネゴシエーションは
+ リソースは、幾つか異なった表現で利用できる場合があります。
- 例えば、異なる言語や異なるメディアタイプ、
+ 例えば、異なる言語や異なるメディアタイプ、
またはそれらの組み合わせで利用できるかも知れません。
もっとも適した選択をする方法の一つには、インデックスページを
ユーザに見せて、ユーザに選んでもらう方法があります。
- しかし、サーバが自動的に選ぶことができる場合が多くあります。
+ しかし、サーバが自動的に選ぶことができる場合が多くあります。
これは、ブラウザがリクエスト情報毎の情報の一部に、
どの表現を嗜好するかを送ることで動作しています。
例えばブラウザは、可能ならフランス語で情報を見たい、
@@ -45,9 +32,8 @@
自分の嗜好を知らせることができます。
ブラウザはリクエストのヘッダで自分の優先傾向を知らせます。
フランス語のみの表現を要求する場合は、ブラウザは次を送ります。 この優先傾向は、選択可能な表現が存在して、
言語によって様々な表現がある場合にのみ適用される
@@ -58,23 +44,24 @@
そして様々なメディアタイプを受け付けるが、
プレインテキストや他のタイプよりは HTML を好む、
他のメディアタイプよりは GIF や JPEG を好む、しかし最終手段として
- 他のメディアタイプも受け付ける、と設定されています。Apache HTTP Server Version 2.0
コンテントネゴシエーション
-
-
-
- コンテントネゴシエーション
-
- mod_negotiation
+ モジュールによって
提供されていて、デフォルトで組み込まれています。
-
- コンテントネゴシエーションについて
+コンテントネゴシエーションについて
- Accept-Language: fr
-
+
+Accept-Language: fr
- 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
-
- Apache は HTTP/1.1 規格で定義されている 'server
+ 他のメディアタイプも受け付ける、と設定されています。
+ +
+ 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 +
Apache は HTTP/1.1 規格で定義されている 'server driven' コンテントネゴシエーションをサポートしています。 Accept, Accept-Language, Accept-Charset, Accept-Encoding リクエストヘッダを完全にサポートしています。Apache は 'transparent' コンテントネゴシエーションもサポートしていますが、 - これは RFC 2295 と RFC 2296 で定義されている実験的な + これは RFC 2295 と RFC 2296 で定義されている試験的な ネゴシエーションプロトコルです。 これらの RFCで定義されている 'feature negotiation' - はサポートしていません。 + はサポートしていません。
-リソースとは URI +
リソースとは URI で特定される概念上のもののことです (RFC 2396)。 Apache のような HTTP サーバは、その名前空間の中での リソースの表現へのアクセスを提供します。 @@ -88,8 +75,7 @@ ネゴシエーション可能なリソースの variant が異なる、 その状態を指して、 ネゴシエーションの次元と呼びます。
- -リソースをネゴシエーションするためには、 サーバは variant それぞれについての情報を知っておく必要があります。 @@ -106,7 +92,7 @@ 行なってその結果から選択する方法。 -
タイプマップは type-map
ハンドラ
(もしくは、古い Apache
@@ -118,10 +104,8 @@
として定義するようなハンドラを、
設定ファイル中に置く必要があることに注意してください。
これは
- AddHandler type-map .var -- をサーバ設定ファイル中に書くことが一番良い方法です。 +
+
AddHandler type-map .var
をサーバ設定ファイル中に書くことが一番良い方法です。
タイプマップファイルは記述するリソースと同じ名前を持っていて、
利用可能な variant それぞれのエントリを持っている必要があります。
@@ -132,35 +116,37 @@
(しかしこれは必須ではなく、あったとしても無視されるものです)。
次に例を示します。このファイルはリソース foo
を記述しているので、foo.var
という名前になります。
- 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 -- たとえ MultiViews を使用するようになっていたとしても、 + +
+
+ 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
+
たとえ MultiViews を使用するようになっていたとしても、 ファイル名の拡張子よりタイプマップの方が優先権を持つということにも 注意してください。 variant の品質が違うときは、この画像のように (JPEG, GIF, ASCII アートがあります) メディアタイプの "qs" - パラメータで指定されます。 -
- 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 -+ パラメータで指定されます。 + +
+ 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 の variant は決して @@ -182,15 +168,18 @@ ドキュメントにあります。
-MultiViews
はディレクトリ毎のオプションで、
- <Directory>
, <Location>
,
- <Files>
や、(AllowOverride
+ <Directory>
,
+ <Location>
,
+ <Files>
+ や、(AllowOverride
が適切な値に 設定されていると) .htaccess
- ファイルで Options
- ディレクティブによって設定することができます。Options
- All
は MultiViews
+ ファイルで Options
+ ディレクティブによって設定することができます。
+ Options All
は
+ MultiViews
をセットしないことに注意してください。明示的に
その名前を書く必要があります。
サーバがディレクトリの索引を作ろうとしていると、 +
サーバがディレクトリの索引を作ろうとしている場合、
MultiViews
- は DirectoryIndex
+ は DirectoryIndex
ディレクティブで指定されたファイルを探す過程にも
適用されます。設定ファイルに
- DirectoryIndex index -- が書かれていて、
index.html
と
++
DirectoryIndex index
が書かれていて、index.html
と
index.html3
が
- 両方存在していると、サーバはその中から毎回どちらかを適当に選びます。
+ 両方存在していると、サーバはその中からどちらかを適当に選びます。
もしその両方が存在せずに index.cgi
- が存在していると、 サーバはそれを実行します。
+ が存在していると、 サーバはそれを実行します。
もしディレクトリを読んでいる際に、
文字セット、コンテントタイプ、言語、エンコーディングを
指定するための mod_mime
で認識できる拡張子を持たないファイルが見つかると、結果は
- MultiViewsMatch
+ MultiViewsMatch
ディレクティブの設定に依存します。このディレクティブは
ハンドラ、フィルタ、他のファイル拡張子タイプのどれが
MultiViews ネゴシエーションで使用できるかを決定します。
Apache はリソースの variant の一覧を、タイプマップファイルか ディレクトリ内のファイル名からかで取得した後、 「最適な」 variant を決定するために二つの方法の どちらかを起動します。 Apache のコンテントネゴシエーションの機能を使うために、 どのようにしてこの調停が行われるか詳細を知る必要はありません。 しかしながら、この文書の残りでは関心のある人のために、 - 使用されている方法について説明しています。 + 使用されている方法について説明しています。
ネゴシエーション方法は二つあります。
@@ -246,8 +234,8 @@ driven negotiation が使用されます。Apache のアルゴリズムは後に詳細に説明されています。 このアルゴリズムが使用された場合、Apache - はより良い結果になるように、特定の次元において品質の値を - 「変える」ことができます。Apache + はより良い結果になるように、特定の次元において品質の値を + 「変える」ことができます。Apache が品質の値を変える方法は後で詳細に説明されています。メディアタイプ | +メディアタイプ | ブラウザは Accept ヘッダフィールドで優先傾向を指定します。 @@ -281,7 +269,7 @@ |
言語 | +言語 | ブラウザは Accept-Language ヘッダフィールドで優先傾向を指定します。 @@ -291,7 +279,7 @@ |
エンコーディング | +エンコーディング | ブラウザは Accept-Encoding ヘッダフィールドで優先傾向を指定します。 @@ -299,7 +287,7 @@ |
文字セット | +文字セット | ブラウザは Accept-Charset ヘッダフィールドで優先傾向を指定します。 @@ -309,7 +297,8 @@ |
ブラウザに返す「最適な」variant を (もしあれば) 選択するように Apache は次のアルゴリズムを使うことができます。 @@ -340,7 +329,8 @@
LanguagePriority
+ (もしあれば)
+ LanguagePriority
ディレクティブの言語順で最適な言語の variant を選びます。上記の Apaceh ネゴシエーションアルゴリズムの厳格な解釈で 得られるであろう値から、Apache は品質数値を時々変えます。 @@ -407,39 +396,40 @@ ブラウザが完全で正しい情報を送っていれば、 この数値変化は適用されません。
-Accept: リクエストヘッダはメディアタイプの優先傾向を指定します。 これはまた、"image/*" や "*/*" といった「ワイルドカード」メディアタイプを含むことができます。 ここで * は任意の文字列にマッチします。 ですから、次の:
-- Accept: image/*, */* -- を含むリクエストは、"image/" ではじまるタイプ全てが許容できる、 + +
+ +
Accept: image/*, */*
を含むリクエストは、"image/" ではじまるタイプ全てが許容できる、 そして他のどんなタイプも許容できる (この場合はじめの "image/*" は冗長になります) ことを示します。 扱うことのできる明示的なタイプに加えて、機械的に - ワイルドカードを送るブラウザもあります。例えば: -
+ ワイルドカードを送るブラウザもあります。例えば: + ++
Accept: text/html, text/plain, image/gif, image/jpeg, */* - - こうすることの狙いは、明示的にリストしているタイプが優先されるけれども、 +
こうすることの狙いは、明示的にリストしているタイプが優先されるけれども、 異なる表現が利用可能であればそれでも良い、ということです。 しかしながら、上の基本的なアルゴリズムでは、 */* ワイルドカードは他の全てのタイプと全く同等なので優先されません。 ブラウザは */* にもっと低い品質 (優先) - 値を付けてリクエストを送るべきなのです。例えば: -
+ 値を付けてリクエストを送るべきなのです。例えば: ++
Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01 - - 明示的なタイプには品質数値が付けられていませんので、 +
明示的なタイプには品質数値が付けられていませんので、 デフォルトの 1.0 (最高値) の優先になります。 ワイルドカード */* は低い優先度 0.01 を与えられているので、 明示的にリストされているタイプに合致する variant がない場合にのみ、 - 他のタイプが返されます。 + 他のタイプが返されます。
もし Accept: ヘッダが q 値を全く含んでいなければ、 望みの挙動をするために、 @@ -451,7 +441,8 @@ 正しい情報を送るブラウザからのリクエストは期待通りに 動作するようになります。
-言語ネゴシエーションの例外処理
+ +言語ネゴシエーションの例外処理
Apache 2.0 では新たに、言語ネゴシエーションが適合するものを 見つけるのに失敗した時に、優雅にフォールバックできるような @@ -465,10 +456,10 @@ このような場合には Apache が Accept-Language を無視して、 クライアントのリクエストに明示的には合致しないドキュメントを 提供するように設定できます。 - ForceLanguagePriority +
ForceLanguagePriority
ディレクティブは、これらのエラーの一つか両方をオーバーライドするために 使用できて、 - LanguagePriority +LanguagePriority
ディレクティブの内容を使ってサーバの判断を代行するようにできます。サーバは他に適合するものが見つからなければ、 @@ -484,8 +475,9 @@ ですが不幸なことに、多くのクライアントではデフォルトで このような設定になっています。) しかしながら、他の言語にはマッチせず、"No Acceptable Variants" - エラーを返したり、
- -LanguagePriority
にフォールバック - しようとしているときは、 + エラーを返したり、 +LanguagePriority
+ にフォールバックしようとしているときは、 サブセット指定を無視して、en-GB
をen
にマッチします。 Apache はクライアントの許容言語リストに暗黙に @@ -497,22 +489,22 @@ 適切に設定されたクライアントともきちんと動作するために 必要です。Transparent Content Negotiation の拡張
- Apache は transparent content negotiation プロトコル - (RFC 2295) を次のように拡張しています。 - 特定のコンテントエンコーディングのみが利用可能である variant - に印を付けるために、新たに{encoding ..}
- 要素を variant リスト中に使っています。 - リスト中のエンコードされた variant を認識し、 - Accept-Encoding リクエストヘッダに従って許容される - エンコードをもった variant は、どれでも候補 variant - として使用するように、 - RVSA/1.0 アルゴリズム (RFC 2296) の実装が拡張されました。 - RVSA/1.0 の実装では、最適な variant が見つかるまで、 - 計算した品質数値は小数点以下 5 桁まで丸めません。 - -リンクと名前の変換に関する注意点
+Transparent Content Negotiation +の拡張
+ +Apache は transparent content negotiation プロトコル +(RFC 2295) を次のように拡張しています。 +特定のコンテントエンコーディングのみが利用可能である variant +に印を付けるために、新たに
+{encoding ..}
+要素を variant リスト中に使っています。 +リスト中のエンコードされた variant を認識し、 +Accept-Encoding リクエストヘッダに従って許容される +エンコードをもった variant は、どれでも候補 variant +として使用するように、 +RVSA/1.0 アルゴリズム (RFC 2296) の実装が拡張されました。 +RVSA/1.0 の実装では、最適な variant が見つかるまで、 +計算した品質数値は小数点以下 5 桁まで丸めません。リンクと名前の変換に関する注意点
言語ネゴシエーションを使っている場合は、 ファイルが一つ以上の拡張子を持てて、 @@ -522,10 +514,10 @@ 幾つかの異なる名前の変換を選べることになります。
典型的なファイルでは、MIME タイプ拡張子 (例えば - html) を持っていて、エンコーディング拡張子 - (例えば gz) を持っているかもしれなくて、 +
html
) を持っていて、エンコーディング拡張子 + (例えばgz
) を持っているかもしれなくて、 このファイルに異なる言語 variant を用意していれば、 - もちろん言語拡張子 (例えば en) + もちろん言語拡張子 (例えばen
) を持っているでしょう。例:
@@ -552,7 +544,7 @@foo.html.en -foo
+foo
foo.html- @@ -569,10 +561,10 @@@@ -581,16 +573,16 @@ foo.html.en.gz -foo
+foo -
foo.htmlfoo.gz
+foo.gz
foo.html.gzfoo -foo.html
- foo.html.gz
+foo.html
+ foo.html.gz
foo.gzfoo.gz.html.en -foo
- foo.gz
+foo
+ foo.gz
foo.gz.htmlfoo.html @@ -599,29 +591,28 @@- foo.html.gz.en -foo
- foo.html
+foo
+ foo.html
foo.html.gzfoo.gz 上の表を見て、拡張子なしのリンク (例えば foo) +
上の表を見て、拡張子なしのリンク (例えば
+ 例えばfoo
) がいつでも使えることに気が付くでしょう。 この利点は、ドキュメントとして応答するファイルの 実際のファイルタイプを隠蔽して、リンクの参照を変更することなく 後からファイルを変更できる、 - 例えば html から shtml - に、あるいは cgi に変更できる点です。html
からshtml
+ に、あるいはcgi
に変更できる点です。リンクに MIME タイプを使い続けたい (例えば - foo.html)時は、言語拡張子は +
- -foo.html
)時は、言語拡張子は (エンコーディング拡張子もあればそれも含めて) MIME タイプ拡張子の右側になければなりません - (例えば foo.html.en)。キャッシュに関する注意事項
+ (例えばfoo.html.en
)。 +キャッシュに関する注意事項
キャッシュが一つの表現を保存しているときは、 リクエスト URL と関連づけられています。 @@ -639,21 +630,16 @@
HTTP/1.0 準拠のクライアントからのリクエストに対しては、 (ブラウザであろうとキャッシュであろうと) ネゴシエーションを受けた応答のキャッシュを許すために、 -
- -CacheNegotiatedDocs
ディレクティブを使用できます。 +CacheNegotiatedDocs
+ ディレクティブを使用できます。 このディレクティブは、サーバ設定ファイルやバーチャルホストに書くことができ、 引数をとりません。 HTTP/1.1 クライアントからのリクエストには効力を持ちません。追加情報
+追加情報
コンテントネゴシエーションに関する追加情報は、 - Alan J. Flavell さんのLanguage + Alan J. Flavell さんのLanguage Negotiation Notes をご覧下さい。ですが、 Apache 2.0 での変更点を含むためには更新されていないかもしれない ということに注意してください。
- - - - - +Apache HTTP Server Version 2.0
\ No newline at end of file diff --git a/docs/manual/filter.html.ja.jis b/docs/manual/filter.html.ja.jis index d7ef281c12..8d7734cb75 100644 --- a/docs/manual/filter.html.ja.jis +++ b/docs/manual/filter.html.ja.jis @@ -1,79 +1,43 @@ - - - - - - -フィルタ - Apache HTTPD - - - - - - - -フィルタ
- -
関連モジュール - - mod_deflate - mod_ext_filter - mod_include - |
-
- 関連ディレクティブ - - AddInputFilter - AddOutputFilter - ExtFilterDefine - ExtFilterOptions - SetInputFilter - SetOutputFilter - |
-
Apache HTTP Server Version 2.0
フィルタ
+Apache でのフィルタの使い方について記述しています。
+フィルタ
+ ++
関連モジュール mod_deflate
mod_ext_filter
mod_include
関連ディレクティブ AddInputFilter
AddOutputFilter
ExtFilterDefine
ExtFilterOptions
SetInputFilter
SetOutputFilter
フィルタ とは、サーバが送受信したデータに 適用される処理プロセスのことをいいます。クライアントからサーバに - 送られたデータは 入力フィルタ によって、サーバから + 送られたデータは 入力フィルタ によって、サーバから クライアントに送られるデータは出力フィルタによって 処理されます。複数のフィルタを適用することができ、 その順番を厳密に指定することもできます。
-Apache 内部では、チャンク (データのぶつ切り) を行ったり、 +
Apache 内部では、チャンク (データのぶつ切り) を行ったり、 バイト範囲の指定されたリクエストを扱ったりといった機能を 行う際に、フィルタが使われています。それに加えて、 実行時の設定ディレクティブで選択が可能なフィルタを モジュールが提供できます。 - データに適応されるフィルタのセットは、
+ データに適応されるフィルタのセットは、 +SetInputFilter
, -SetOutputFilter
,AddInputFilter
, -AddOutputFilter
ディレクティブで制御できます。SetInputFilter
, +SetOutputFilter
, +AddInputFilter
, +AddOutputFilter
+ ディレクティブで制御できます。現行の Apache HTTP サーバの配布では、 次のユーザ選択可能なフィルタが提供されています。
--
- -- INCLUDES
- mod_includeで Server-Side Include をします。
-- DEFLATE
- mod_deflate を使って、 -クライアントに送信する前に出力を圧縮します。
-また、mod_ext_filter モジュールで - 外部プログラムをフィルタとして指定することができます。
- - - - - ++
+ +- INCLUDES
+- +
mod_include
で Server-Side Include をします。- DEFLATE
+- +
mod_deflate
+ を使って、クライアントに送信する前に出力を圧縮します。また、
+mod_ext_filter
モジュールで + 外部プログラムをフィルタとして指定することができます。
Windows 上では、Apache は通常は - Windows NT ではサービスとして、Windows 95 - ではコンソールアプリケーションとして実行されます。 +
Apache HTTP Server Version 2.0
Apache の起動
+Windows 上では、Apache は通常は + Windows NT ではサービスとして、Windows 95 + ではコンソールアプリケーションとして実行されます。 詳細に関しては、「 Windows で Apache を実行する」をご覧下さい。
-Unix - での Apache の起動
-Unixでは、httpd - プログラムが、リクエスト処理をバックグラウンドで常に動作する - デーモンとして実行されます。
+ プログラムが、バックグラウンドで常にリクエスト処理を行う + デーモンとして実行されます。この文書ではどのように +httpd
を起動するかについて記述しています。 +Apache の起動方法
もし、設定ファイル中で指定されている - Listen +
+ これは選択したマルチプロセッシングモジュールで制御されます。Listen
がデフォルトの 80 (もしくは 1024 以下の他のポート) - である場合は、Apache を起動するためには root + である場合は、Apache を起動するためには root 権限が必要になりますが、 これはこの特権ポートにバインドするためです。 起動して、一度ログファイルを開くといった準備のための @@ -60,46 +26,41 @@ listen と応答を実際に行う子プロセスを起動します。 メインのhttpd
プロセスは root 権限で走り続けますが、 子プロセスはもっと低い権限で走ります。 - これは選択したマルチプロセッシングモジュールで制御されます。-
httpd
が起動されてまず最初にすることは、 - 設定ファイルhttpd.conf
- の位置を特定して読み込むことです。 + 設定ファイル +httpd.conf
の位置を特定して読み込むことです。 このファイルの位置はコンパイル時に設定されますが、実行時に-f
コマンドラインオプションを使って 位置を指定することもできます。例えば次のようにです。-+/usr/local/apache/bin/httpd -f - /usr/local/apache/conf/httpd.conf
-
/usr/local/apache/bin/httpd -f + /usr/local/apache/conf/httpd.conf
-
httpd
のバイナリを直接起動する代わりに、 apachectl - と呼ばれるシェルスクリプトが提供されています。 + というシェルスクリプトが提供されています。apachectl start
やapachectl stop
といった簡単なコマンドで、 デーモンプロセスを制御するのに使えます。スタートアップが万事上手くいったら、サーバはターミナルから +
スタートアップが万事上手くいったら、サーバはターミナルから 切り離されて、コマンドプロンプトが即座に戻ってくるでしょう。 これはサーバが起動している状態を示しています。 その後はブラウザでサーバに接続して、 - DocumentRoot +
+DocumentRoot
ディレクトリのテストページやそこからリンクされている ローカルのドキュメントを見ることができるでしょう。起動時のエラー
-スタートアップ時のエラー -
- -Apache は、スタートアップ時に致命的な問題に遭遇すると、 +
Apache は、起動時に致命的な問題に遭遇すると、 終了する前に、コンソールか - ErrorLog +
+ 「ErrorLog
のどちらかに問題を記述したメッセージを出力します。 最もよくあるエラーメッセージは - "Unable to bind to Port ...
" - です。このメッセージは普通は次のどちらかが原因です:Unable to bind to Port ...
」 + です。このメッセージは普通は次のどちらかが原因です。
- root でログインしていない時に、 @@ -107,13 +68,12 @@
- 同じポートに既にバインドされている Apache がもう一つあるときや他のウェブサーバが存在している時に、 - サーバを開始しようとした。
+ サーバを開始しようとした。より多くの問題解決の方策の説明は、 Apache FAQ をご覧下さい。
- -ブート時の起動
+ブート時の起動
システムがリブートした後でも サーバが実行され続けるようにしたい場合は、 @@ -127,19 +87,15 @@
- -apachectl
スクリプトは通常は、 init スクリプトとして直接リンクできるように設計されていますが、 念のためシステムの要求に合致していることを確認してください。追加情報
+追加情報
httpd や apachectl 、サーバに含まれていたその他補助プログラムの、 コマンドラインオプションに関する追加情報は、 - サーバと補助プログラムページに + サーバと補助プログラムページに 記載されています。 Apache 配布に含まれている全モジュール、 それによって提供されるディレクティブ のドキュメントもあります。
- - - - +
See also