From 47141f94d827556eebb628668c381d1aa3fe44c0 Mon Sep 17 00:00:00 2001 From: Yoshiki Hayashi Date: Thu, 29 Aug 2002 06:43:42 +0000 Subject: [PATCH] New XML. Submitted by: Hiroaki KAWAI git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96561 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/content-negotiation.xml.ja | 668 +++++++++++++++++++++++++ docs/manual/filter.xml.ja | 70 +++ docs/manual/invoking.xml.ja | 117 +++++ docs/manual/mpm.xml.ja | 105 ++++ 4 files changed, 960 insertions(+) create mode 100644 docs/manual/content-negotiation.xml.ja create mode 100644 docs/manual/filter.xml.ja create mode 100644 docs/manual/invoking.xml.ja create mode 100644 docs/manual/mpm.xml.ja diff --git a/docs/manual/content-negotiation.xml.ja b/docs/manual/content-negotiation.xml.ja new file mode 100644 index 0000000000..570b7bccc8 --- /dev/null +++ b/docs/manual/content-negotiation.xml.ja @@ -0,0 +1,668 @@ + + + + + + + +コンテントネゴシエーション + + + +

Apache は HTTP/1.1 の規格に記述されているコンテントネゴシエーションを + サポートしています。 + ブラウザにより提供されたメディアタイプ、 + 言語、文字セット、エンコーディングの優先傾向に基づいて、 + 最適なリソースの表現を選択できます。 + また、不完全なネゴシエーション情報を送ってくるブラウザからのリクエストを + もっと賢く取り扱えるよう、いくつか機能も実装してあります。

+ +

コンテントネゴシエーションは + mod_negotiation + モジュールによって + 提供されていて、デフォルトで組み込まれています。

+ + +
コンテントネゴシエーションについて + +

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

+ +Accept-Language: fr + +

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

+ +

もっと複雑なリクエストの例を挙げましょう。 + このブラウザはフランス語と英語を受け付ける、しかしフランス語を好む、 + そして様々なメディアタイプを受け付けるが、 + プレインテキストや他のタイプよりは HTML を好む、 + 他のメディアタイプよりは 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 + + +

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

+ +

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

+
+ +
Apache におけるネゴシエーション + +

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

+ +
    +
  • タイプマップ + (すなわち *.var ファイル) + を使う方法。 これは variant + を明示的に挙げているファイルを指定します。
    • + +
  • 'Multiviews' + を使って、サーバが暗黙の内にファイル名にパターン照合を + 行なってその結果から選択する方法。
    • +
+ +
type-map ファイルを使う + +

タイプマップは type-map ハンドラ + (もしくは、古い Apache + の設定と下位互換である mime タイプ + application/x-type-map) + に関連付けられたドキュメントです。 + この機能を使うためには、あるファイルの拡張子を + type-map + として定義するようなハンドラを、 + 設定ファイル中に置く必要があることに注意してください。 + これは

+AddHandler type-map .var +

をサーバ設定ファイル中に書くことが一番良い方法です。

+ +

タイプマップファイルは記述するリソースと同じ名前を持っていて、 + 利用可能な variant それぞれのエントリを持っている必要があります。 + そして、このエントリは連続した HTTP のヘッダ行で構成されます。 + 異なる variant のためのエントリは空行で区切られています。 + エントリ中に空行が複数あってはいけません。 + 習慣的には、マップファイルは全体を結合したもののエントリから始まります + (しかしこれは必須ではなく、あったとしても無視されるものです)。 + 次に例を示します。このファイルはリソース 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 を使用するようになっていたとしても、 + ファイル名の拡張子よりタイプマップの方が優先権を持つということにも + 注意してください。 + 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
+ + +

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

+ +

認識されるヘッダの一覧は + mod_negotiation + ドキュメントにあります。

+
+ +
Multiviews + +

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

+ +

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

+ +

サーバがディレクトリの索引を作ろうとしている場合、 + MultiViews + は DirectoryIndex + ディレクティブで指定されたファイルを探す過程にも + 適用されます。設定ファイルに

+DirectoryIndex index +

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

+ +

もしディレクトリを読んでいる際に、 + 文字セット、コンテントタイプ、言語、エンコーディングを + 指定するための mod_mime + で認識できる拡張子を持たないファイルが見つかると、結果は + MultiViewsMatch + ディレクティブの設定に依存します。このディレクティブは + ハンドラ、フィルタ、他のファイル拡張子タイプのどれが + MultiViews ネゴシエーションで使用できるかを決定します。

+
+
+ +
ネゴシエーション方法 + +

Apache はリソースの variant の一覧を、タイプマップファイルか + ディレクトリ内のファイル名からかで取得した後、 + 「最適な」 variant を決定するために二つの方法の + どちらかを起動します。 + Apache のコンテントネゴシエーションの機能を使うために、 + どのようにしてこの調停が行われるか詳細を知る必要はありません。 + しかしながら、この文書の残りでは関心のある人のために、 + 使用されている方法について説明しています。

+ +

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

+ +
    +
  1. 通常は Apache のアルゴリズムを用いた Server + driven negotiation が使用されます。Apache + のアルゴリズムは後に詳細に説明されています。 + このアルゴリズムが使用された場合、Apache + はより良い結果になるように、特定の次元において品質の値を + 「変える」ことができます。Apache + が品質の値を変える方法は後で詳細に説明されています。
    2. + +
  2. RFC 2295 + で定義されている機構を用いてブラウザが特に指定した場合、 + transparent content negotiation + が使用されます。このネゴシエーション方法では、「最適な」 + variant の決定をブラウザが完全に制御することができます。 + ですから、結果はブラウザが使用しているアルゴリズムに依存します。 + Transparent negotiation の処理の過程で、ブラウザは RFC 2296 + で 定義されている 'remote variant selection algorithm' + を実行するように頼むことができます。
    3. +
+ +
ネゴシエーションの次元 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
次元説明
メディアタイプブラウザは Accept + ヘッダフィールドで優先傾向を指定します。 + アイテムそれぞれは、関連した品質数値を持つことができます。 + variant の説明も品質数値を持つことができます + ("qs" パラメータをご覧下さい)。
言語ブラウザは Accept-Language + ヘッダフィールドで優先傾向を指定します。 + 要素それぞれに品質数値を持たせることができます。 + variants は 0 か 1 つかそれ以上の言語と + 関連づけることができます。
エンコーディングブラウザは Accept-Encoding + ヘッダフィールドで優先傾向を指定します。 + 要素それぞれに品質数値を持たせることができます。
文字セットブラウザは Accept-Charset + ヘッダフィールドで優先傾向を指定します。 + 要素それぞれに品質数値を持たせることができます。 + variant はメディアタイプのパラメータとして文字セットを + 指定することもできます。
+
+ +
Apache ネゴシエーションアルゴリズム + +

ブラウザに返す「最適な」variant を (もしあれば) 選択するように + Apache は次のアルゴリズムを使うことができます。 + このアルゴリズムを設定により変更することはできません。 + 次のように動作します:

+ +
    +
  1. まずはじめに、ネゴシエーションの次元それぞれについて適切な + Accept* ヘッダフィールドを調べ、 + variant それぞれに品質を割り当てます。 + もしある次元の Accept* ヘッダでその variant + が許容できないことが示されていれば、それを削除します。 + variant が一つも残っていなければ、ステップ 4 に行きます。
    2. + +
  2. + 消去法で「最適な」 variant を選びます。 + 次のテストが順番に適用されます。 + テストで選択されなかった variant は削除されていきます。 + テスト後 variant が一つだけ残っていれば、それを最適なものとして + ステップ 3 に進みます。 + 複数 variant が残っていれば、次のテストに進みます。 + +
      +
    1. variant のメディアタイプの品質数値と Accept + ヘッダの品質数値との積を計算して、最高値の variant + を選びます。
      2. + +
    2. 言語品質数値が最高の variant を選びます。
      3. + +
    3. (もしあれば) Accept-Language ヘッダの言語順か、 + (もしあれば) + LanguagePriority + ディレクティブの言語順で最適な言語の variant を選びます。
      4. + +
    4. 最高「レベル」のメディアパラメータ + (text/html メディアタイプのバージョンを与えるために使われます) + を持つ variant を選びます。
      5. + +
    5. Accept-Charset ヘッダ行で与えられている最高の文字セット + メディアパラメータを持つ variant を選びます。 + 明示的に除外されていない限り、ISO-8859-1 + が許容されるようになっています。 + text/* メディアタイプであるけれども + 特定の文字セットに明示的に関連づけられているわけではない + variant は ISO-8859-1 であると仮定されます。
      6. + +
    6. ISO-8859-1 ではない文字セットメディアパラメータと + 関連づけられている variant を選びます。 + そのような variant がない場合は、代わりに全ての + variant を選びます。
      7. + +
    7. 最適なエンコーディングの variant を選びます。 + もし user-agent が許容するエンコーディングがあれば、 + その variant のみを選びます。 + そうではなく、もしエンコードされたものとそうでない + variant が混ざって存在していたらエンコードされていない + variant のみを選びます。 + variant が全部エンコードされているか + variant が全部エンコードされていないという場合は、 + 全ての variant を選びます。
      8. + +
    8. 内容の最も短い variant を選びます。
      9. + +
    9. 残っている variant の最初のものを選びます。 + タイプマップファイルの最初にリストされているか、 + variant がディレクトリから最初に読み込まれる時に + ASCII順でソートしてファイル名が先頭になったか、のどちらかです。
      10. +
    +
    3. + +
  3. アルゴリズムを使って一つの「最適な」variant を選びましたので、 + それを応答として返します。ネゴシエーションの次元を指定するために + HTTP レスポンスヘッダ Vary が設定されます + (リソースのキャッシュをする時に、 + ブラウザやキャッシュはこの情報を使うことができます)。 + 以上で終わり。
    4. + +
  4. ここに来たということは、variant が一つも選択されなかった + (ブラウザが許容するものがなかったため) ということです。 + 406 ステータス ("No Acceptable representation" を意味する) + が、利用可能な variant のリストのついた HTML + ドキュメントとともに返されます。 + 相違の次元を示す HTTP Vary ヘッダも設定されます。
    5. +
+
+
+ +
品質の値を変える + +

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

+ +
メディアタイプとワイルドカード + +

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

+
+ +
言語ネゴシエーションの例外処理 + +

Apache 2.0 では新たに、言語ネゴシエーションが適合するものを + 見つけるのに失敗した時に、優雅にフォールバックできるような + ネゴシエーションアルゴリズムが幾つか追加されました。

+ +

サーバのページをクライアントがリクエストしたけれども、 + ブラウザの送ってきた Accept-Language に合致するページが一つも + 見つからなかった場合に、サーバは "No Acceptable Variant" + か "Multiple Choices" レスポンスをクライアントに返します。 + これらのエラーメッセージを返さないように、 + このような場合には Apache が Accept-Language を無視して、 + クライアントのリクエストに明示的には合致しないドキュメントを + 提供するように設定できます。 + ForceLanguagePriority + ディレクティブは、これらのエラーの一つか両方をオーバーライドするために + 使用できて、 + LanguagePriority + ディレクティブの内容を使ってサーバの判断を代行するようにできます。

+ +

サーバは他に適合するものが見つからなければ、 + 言語サブセットで適合するものを試そうともします。 + 例えばクライアントが英国英語である en-GB 言語で + ドキュメントをリクエストした場合、サーバは HTTP/1.1 + 規格では、単に en とマークされているドキュメントを + マッチするものとすることは通常は許されていません。 + (英国英語は理解できるけど一般的な英語は理解できないという読み手は + 考えられないので、Accept-Language ヘッダで en-GB + を含んで en を含まないのはほぼ確実に設定の間違いである、 + ということに注意してください。 + ですが不幸なことに、多くのクライアントではデフォルトで + このような設定になっています。) + しかしながら、他の言語にはマッチせず、"No Acceptable Variants" + エラーを返したり、 + LanguagePriority + にフォールバックしようとしているときは、 + サブセット指定を無視して、en-GB を en + にマッチします。 + Apache はクライアントの許容言語リストに暗黙に + 非常に低い品質値の親言語を加えることになります。 + しかし、クライアントが "en-GB; qs=0.9, fr; qs=0.8" とリクエストして、 + サーバが "en" と "fr" と設計されたドキュメントを持っている場合は、 + "fr" ドキュメントが返されることに注意してください。 + このような処理は、HTTP 1.1 規格との整合性を維持して、 + 適切に設定されたクライアントともきちんと動作するために + 必要です。

+
+
+ +
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 桁まで丸めません。

+
+ +
リンクと名前の変換に関する注意点 + +

言語ネゴシエーションを使っている場合は、 + ファイルが一つ以上の拡張子を持てて、 + 拡張子の順番は通常は考慮されない + (詳細は mod_mime + を参照) ので、 + 幾つかの異なる名前の変換を選べることになります。

+ +

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

+ +

例:

+ +
    +
  • foo.en.html
    • + +
  • foo.html.en
    • + +
  • foo.en.html.gz
    • +
+ +

ファイル名と、それに対して使えるリンクと使えないリンクの例です:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ファイル名使えるリンク使えないリンク
foo.html.enfoo
+ foo.html		-
foo.en.htmlfoofoo.html
foo.html.en.gzfoo
+ foo.html		foo.gz
+ foo.html.gz
foo.en.html.gzfoofoo.html
+ foo.html.gz
+ foo.gz
foo.gz.html.enfoo
+ foo.gz
+ foo.gz.html		foo.html
foo.html.gz.enfoo
+ foo.html
+ foo.html.gz		foo.gz
+ +

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

+ +

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

+
+ +
キャッシュに関する注意事項 + +

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

+ +

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

+
+ +
追加情報 + +

コンテントネゴシエーションに関する追加情報は、 + Alan J. Flavell さんのLanguage + Negotiation Notes をご覧下さい。ですが、 + Apache 2.0 での変更点を含むためには更新されていないかもしれない + ということに注意してください。

+
+ + diff --git a/docs/manual/filter.xml.ja b/docs/manual/filter.xml.ja new file mode 100644 index 0000000000..a078b2d165 --- /dev/null +++ b/docs/manual/filter.xml.ja @@ -0,0 +1,70 @@ + + + + + + + + + フィルタ + + +

Apache でのフィルタの使い方について記述しています。

+ + +
+ フィルタ + + + mod_deflate + mod_ext_filter + mod_include + + + AddInputFilter + AddOutputFilter + ExtFilterDefine + ExtFilterOptions + SetInputFilter + SetOutputFilter + + + +

フィルタ とは、サーバが送受信したデータに + 適用される処理プロセスのことをいいます。クライアントからサーバに + 送られたデータは 入力フィルタ によって、サーバから + クライアントに送られるデータは出力フィルタによって + 処理されます。複数のフィルタを適用することができ、 + その順番を厳密に指定することもできます。

+ +

Apache 内部では、チャンク (データのぶつ切り) を行ったり、 + バイト範囲の指定されたリクエストを扱ったりといった機能を + 行う際に、フィルタが使われています。それに加えて、 + 実行時の設定ディレクティブで選択が可能なフィルタを + モジュールが提供できます。 + データに適応されるフィルタのセットは、 + SetInputFilter, + SetOutputFilter, + AddInputFilter, + AddOutputFilter + ディレクティブで制御できます。

+ +

現行の Apache HTTP サーバの配布では、 + 次のユーザ選択可能なフィルタが提供されています。

+ +
+
INCLUDES
+
mod_include で Server-Side Include をします。
+
DEFLATE
+
mod_deflate + を使って、クライアントに送信する前に出力を圧縮します。
+
+ +

また、mod_ext_filter モジュールで + 外部プログラムをフィルタとして指定することができます。

+
+ + + + + diff --git a/docs/manual/invoking.xml.ja b/docs/manual/invoking.xml.ja new file mode 100644 index 0000000000..9d3c15b26b --- /dev/null +++ b/docs/manual/invoking.xml.ja @@ -0,0 +1,117 @@ + + + + + + + + Apache の起動 + + +

Windows 上では、Apache は通常は + Windows NT ではサービスとして、Windows 95 + ではコンソールアプリケーションとして実行されます。 + 詳細に関しては、「 + Windows で Apache を実行する」をご覧下さい。

+ +

Unixでは、httpd + プログラムが、バックグラウンドで常にリクエスト処理を行う + デーモンとして実行されます。この文書ではどのように + httpd を起動するかについて記述しています。

+ + +
Apache の起動方法 + +

もし、設定ファイル中で指定されている + Listen + がデフォルトの 80 (もしくは 1024 以下の他のポート) + である場合は、Apache を起動するためには root + 権限が必要になりますが、 + これはこの特権ポートにバインドするためです。 + 起動して、一度ログファイルを開くといった準備のための + 動作を幾つか実行した後は、クライアントからのリクエストに対する + listen と応答を実際に行う子プロセスを起動します。 + メインの httpd プロセスは root 権限で走り続けますが、 + 子プロセスはもっと低い権限で走ります。 + これは選択したマルチプロセッシングモジュールで制御されます。

+ +

httpd が起動されてまず最初にすることは、 + 設定ファイル + httpd.conf の位置を特定して読み込むことです。 + このファイルの位置はコンパイル時に設定されますが、実行時に + -f コマンドラインオプションを使って + 位置を指定することもできます。例えば次のようにです。

+ +/usr/local/apache/bin/httpd -f + /usr/local/apache/conf/httpd.conf + +

httpd のバイナリを直接起動する代わりに、 + apachectl + というシェルスクリプトが提供されています。 + apachectl start や apachectl stop + といった簡単なコマンドで、 + デーモンプロセスを制御するのに使えます。

+ +

スタートアップが万事上手くいったら、サーバはターミナルから + 切り離されて、コマンドプロンプトが即座に戻ってくるでしょう。 + これはサーバが起動している状態を示しています。 + その後はブラウザでサーバに接続して、 + DocumentRoot + ディレクトリのテストページやそこからリンクされている + ローカルのドキュメントを見ることができるでしょう。

+
+ +
起動時のエラー + +

Apache は、起動時に致命的な問題に遭遇すると、 + 終了する前に、コンソールか + ErrorLog + のどちらかに問題を記述したメッセージを出力します。 + 最もよくあるエラーメッセージは + 「Unable to bind to Port ...」 + です。このメッセージは普通は次のどちらかが原因です。

+ +
    +
  • root でログインしていない時に、 + 特権ポートでサーバを起動しようとした。
    • + +
  • 同じポートに既にバインドされている Apache + がもう一つあるときや他のウェブサーバが存在している時に、 + サーバを開始しようとした。
    • +
+ +

より多くの問題解決の方策の説明は、 + Apache FAQ をご覧下さい。

+
+ +
ブート時の起動 + +

システムがリブートした後でも + サーバが実行され続けるようにしたい場合は、 + httpd か apachectl + を呼び出すものをシステムスタートアップファイル + (通常 rc.local や rc.N + 内のファイル) に追加しなければなりません。 + この方法では Apache を root 権限で起動します。 + これをする前に、セキュリティやアクセス制限が + 適切に設定されていていることを確認してください。 + apachectl スクリプトは通常は、 init + スクリプトとして直接リンクできるように設計されていますが、 + 念のためシステムの要求に合致していることを確認してください。

+
+ +
追加情報 + +

httpd や + apachectl + 、サーバに含まれていたその他補助プログラムの、 + コマンドラインオプションに関する追加情報は、 + サーバと補助プログラムページに + 記載されています。 + Apache 配布に含まれている全モジュール、 + それによって提供されるディレクティブ + のドキュメントもあります。

+
+ + diff --git a/docs/manual/mpm.xml.ja b/docs/manual/mpm.xml.ja new file mode 100644 index 0000000000..3390f29228 --- /dev/null +++ b/docs/manual/mpm.xml.ja @@ -0,0 +1,105 @@ + + + + + + + + マルチプロセッシングモジュール (MPM) + + +

この文書ではマルチプロセッシングモジュールがどのようなもので、 +Apache HTTP サーバでどのように使用されるかについて解説しています。

+ + +
はじめに + +

Apache HTTP サーバは異なる幅広い環境、多種多様なプラットホームで + 動作するように、パワフルで柔軟性に富んだ設計になっています。 + 異なるプラットホーム・異なる環境ではしばしば、 + 異なる機能が必要になったり、 + 同じ機能でも効率のために異なる実装が必要になったりします。 + Apache ではモジュール化された設計により幅広い環境に適応してきました。 + この設計のおかげで、管理者は + コンパイル時または実行時にどのモジュールをロードするか選ぶことによって、 + どの機能をサーバに取り込むか選択することがができます。

+ +

Apache 2.0 では、 + このモジュール化された設計をサーバの基本機能にまで拡張しました。 + サーバには精選されたマルチプロセッシングモジュール (MPM) + が付いてきて、これらはマシンのネットワークポートをバインドしたり、 + リクエストを受け付けたり、リクエストを扱うよう子プロセスに割り当てたり、 + といった役割を持ちます。

+ +

モジュール化された設計をサーバのこのレベルまで拡張することで + 二つの重要な利点が生まれます:

+ +
    +
  • Apache は幅広いオペレーティングシステムを + より美しく効率的にサポートできます。 + 特に Windows 版の Apache は随分効率的になりました。 + なぜなら mpm_winnt + によって、Apache 1.3 で用いられていた POSIX + レイヤの代わりにネイティブのネットワーク機能を + 利用できるからです。 + 特別化された MPM + を実装した他のオペレーティングシステムでも、 + 同様にこの利点は生まれます。
    • + +
  • サーバは特定のサイト向けに、より上手にカスタマイズできます。 + 例えば、非常に大きなスケーラビリティを必要とするサイトでは、 + worker といったスレッド化された + MPM を利用できる一方で、安定性や古いソフトウェアとの互換性を + 必要とするサイトでは prefork + が利用できます。また、 + 異なるホストを異なるユーザ ID で動作させる + (perchild) といった + 特別な機能も提供できます。
    • +
+ +

ユーザレベルでは、MPM は他の Apache + モジュールと同等に見えます。 + 主な違いは、いつでも唯一の MPM + がロードされなければならないという点です。 + 利用可能な MPM は + module インデックスにあります。

+ +
+ +
MPM を選ぶ + +

MPM は設定中に選択して、サーバ内部にコンパイルされなければ + なりません。 + コンパイラは、スレッドが使用されていれば様々な機能を最適化できますが、 + そもそもスレッドが使われているということを知る必要があります。 + MPM には Unix 上でスレッドを用いるものや、スレッドをまったく + 使わないものがあるので、 + Apache は、MPM が設定中に選択されて Apache 内部に組み込まれた場合の方が + 常により良いパフォーマンスを発揮します。

+ +

望みの MPM を実際に選ぶためには、./configure スクリプトで + --with-mpm= NAME 引数を用いてください。 + NAME は望みの MPM の名前です。

+ +

サーバコンパイル後は、どの MPM が選択されたかを + ./httpd -l で確かめることができます。 + このコマンドは、MPM + を含め、サーバにコンパイルで組み込まれたモジュール全てを + 列挙します。

+
+ +
MPM デフォルト値 + +

次表に様々な OS 向けのデフォルトの MPM 一覧を掲載しています。 +コンパイル時に意図的に他を選択しなければ、自動的にこれらの MPM +が選択されます。

+ + + + + + +
BeOSbeos
OS/2mpmt_os2
Unixprefork
Windowsmpm_winnt
+
+ + -- 2.40.0