コンテントネゴシエーション

Revision Changes Path 1.1 httpd-2.0/docs/manual/content-negotiation.xml.ja Index: content-negotiation.xml.ja =================================================================== コンテントネゴシエーション

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 のコンテントネゴシエーションの機能を使うために、どのようにしてこの調停が行われるか詳細を知る必要はありません。しかしながら、この文書の残りでは関心のある人のために、使用されている方法について説明しています。

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

通常は Apache のアルゴリズムを用いた Server driven negotiation が使用されます。Apache のアルゴリズムは後に詳細に説明されています。このアルゴリズムが使用された場合、Apache はより良い結果になるように、特定の次元において品質の値を「変える」ことができます。Apache が品質の値を変える方法は後で詳細に説明されています。
RFC 2295 で定義されている機構を用いてブラウザが特に指定した場合、 transparent content negotiation が使用されます。このネゴシエーション方法では、「最適な」 variant の決定をブラウザが完全に制御することができます。ですから、結果はブラウザが使用しているアルゴリズムに依存します。 Transparent negotiation の処理の過程で、ブラウザは RFC 2296 で定義されている 'remote variant selection algorithm' を実行するように頼むことができます。

ネゴシエーションの次元

次元	説明
メディアタイプ	ブラウザは Accept ヘッダフィールドで優先傾向を指定します。アイテムそれぞれは、関連した品質数値を持つことができます。 variant の説明も品質数値を持つことができます ("qs" パラメータをご覧下さい)。
言語	ブラウザは Accept-Language ヘッダフィールドで優先傾向を指定します。要素それぞれに品質数値を持たせることができます。 variants は 0 か 1 つかそれ以上の言語と関連づけることができます。
エンコーディング	ブラウザは Accept-Encoding ヘッダフィールドで優先傾向を指定します。要素それぞれに品質数値を持たせることができます。
文字セット	ブラウザは Accept-Charset ヘッダフィールドで優先傾向を指定します。要素それぞれに品質数値を持たせることができます。 variant はメディアタイプのパラメータとして文字セットを指定することもできます。

Apache ネゴシエーションアルゴリズム

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

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

品質の値を変える

上記の 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.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 タイプを使い続けたい (例えば 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 での変更点を含むためには更新されていないかもしれないということに注意してください。

1.1 httpd-2.0/docs/manual/invoking.xml.ja Index: invoking.xml.ja =================================================================== 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 配布に含まれている全モジュール、それによって提供されるディレクティブのドキュメントもあります。

1.1 httpd-2.0/docs/manual/filter.xml.ja Index: filter.xml.ja =================================================================== フィルタ

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 モジュールで外部プログラムをフィルタとして指定することができます。

1.1 httpd-2.0/docs/manual/mpm.xml.ja Index: mpm.xml.ja =================================================================== マルチプロセッシングモジュール (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 が選択されます。

BeOS	beos
OS/2	mpmt_os2
Unix	prefork
Windows	mpm_winnt