これはSoftware Design 2002年9月号の特集の第1章の原稿に若干の修正と加筆を行ったものです。
$Id: ruby.rd,v 1.15 2002/09/28 07:48:24 akira Exp $

Software Design 2002年09号特集第1章 Apache 2.0の新機能

去る2002年5月， Apache 2.0をテーマとしたTechStyle主催のセミナーが行われました． Apache 2.0における新機能や1.3系との比較などを題材とし，締めくくりには日本Apacheユーザ会の安東先生やTechStyleの風穴さんをまじえてのパネルディスカッションが行われました．実は筆者も講師として参加していたのですが，ちょうどApache 2.0がリリースされた直後であったこともあり，有料のセミナーであったにもかかわらず会場はほぼ満員だったようです．こうしたところからもApache 2.0に対する潜在的な関心の高さをうかがえます．

なお，同セミナーではセミナー後のフォローとして Apache 2.0のホワイトペーパーを制作することが予定されています．本誌が店頭に並ぶころには，このホワイペーパーもリリースされているのではないかと思います．同セミナーは完全に技術的なセミナーというわけではなく， Apache 2.0がリリースされたことによって，特にビジネス分野にどういった影響があるかを考えるという趣旨のものでしたので，内容は今回の特集とはまた違ったものになると思われます．詳しくはTechStyleのホームページを参照してください．

Apache 2.0の歩み

Apache 2.0^*1がリリースされたのは2002年4月5日で，その時のバージョンは2.0.36というものでした．このように，最初のリリースなのに中途半端なバージョンになっているのはリリースのされ方によるものです．

Apacheのバージョン2.0系の開発が始まったのは2000年はじめごろで，現在もまだ現役として使われている1.3系のバージョンが1.3.12だった頃です． 2.0系として最初に一般公開されたのはいわゆるα版という形で，バージョンは2.0a2でした．その後2.0a3，2.0a4，…と進み 2.0a9の後で2.0.14というバージョンが付けられました（ただしこれもまだα版です）．次のステップに進んだのはバージョンが2.0.16になった時で，これが最初のβ版のリリースになります． 2001年4月4日のことで，1.3系のバージョンはその当時1.3.19でした．

その後，2001年11月13日に2回目のβ版が公開され，さらに2002年2月16日には3回目で最後のβ版が公開．そして最初の一般リリースの日，2002年4月5を迎えます．一連の流れを表1にまとめていますが， α版の期間だけで一年間，β版の期間がさらに一年間と，具体的な形になってからでさえ二年間もの時間をかけて開発とテストが行われてきたことが見てとれます．

また，このようにβ版の開発が2.0.xというバージョンのもとに進められ，その流れの中で一般リリースが行われたため，最初の一般リリースであるにもかかわらず中途半端なバージョン（2.0.36）になったようです．

執筆時点での最新のバージョンは2.0.39で，先日見付かった重大なセキュリティホールの修正を組み込む形でリリースされています．

表1 Apache 2.0の歩み（主なバージョン）
日付          2系のバージョン 1.3系のバージョン       コメント
1998-01-01                    1.3.0
2000-02-23                    1.3.12
2000-03-31    2.0a3                                   最初の公開（α版）
2000-09-10                    1.3.14
2001-02-26                    1.3.19
2001-04-04    2.0.16                                  最初のβ版公開
2001-10-08                    1.3.22
2001-11-13    2.0.28                                  2回目のβ版公開
2002-02-16    2.0.32                                  3回目のβ版公開
2002-05-06    2.0.36                                  最初の一般リリース
2002-06-17    2.0.39                                  セキュリティホールの修正
2002-06-18                    1.3.26                  セキュリティホールの修正

5つの新機能

「Apacheのバージョンが2.0になって，いったい何が良くなったんだ?」と思っている方も中にはいらっしゃるのではないでしょうか．

これから見ていくように， Apache 2.0にはその内部構造において非常に大きな変化がありました．この変化はメジャーバージョンが1から2に進むのに十分なものだと考えられる一方で，外見的には（つまり一ユーザとしての視点からでは）どういったところに影響を与えるのかが見えにくいというのも事実です．

実際，1.3系から2.0系での大きな変化の中のいくつかはほぼ開発者にしか関係しないと言っても差し支えないものもあります．しかし，それ以外のいくつかの変化は直接ユーザにも関係するようなものです．そして，そうした変化は大きく5つのトピックとしてとらえることができますが，これを「どちらかというとApacheそのものや関連モジュールの開発者にとって（のみ）興味深いもの」から「一般のユーザにも関係のある新しい機能」の順に並べると，現時点ではおおむね次のようになるでしょう．

マルチプロトコル対応
APR（Apache Portable Runtime）の導入
MPM（Multi Processing Module）の導入
IPv6対応
フィルタ機能の導入

また，これらの変化に伴って設定ファイルについても若干の変更があります．新しい機能のためにディレクティブが新設されるというのが主ですが，機能の統合などによりディレクティブが廃止されたり，意味が変わったりしているものもあります．

以下ではまず上の5つの変化のそれぞれについて説明し，その後で，それらに伴うディレクティブの変更点など， Apache 2.0への移行に際しての注意点についても触れたいと思います．

マルチプロトコル対応

これまでのApacheで扱うことのできるプロトコルはHTTPだけでした．そもそもHTTPサーバなのですからしごく当然なのですが， Apache 2.0ではこの「当然」に関する大きな変化がありました．つまり従来はHTTPと密接に結びついていたApacheが， HTTPから一定の距離をおくことによって， HTTP以外のプロトコルを扱うことができるようになったのです．

このことはconfigureスクリプトを--helpオプション付きで実行して，ヘルプメッセージを表示させることでも伺い知ることができます（リスト1）．数あるオプションの中には--enable-httpが含まれていて，その設明は「HTTP protocol handling（HTTPの処理）」となっています．

リスト1 configureのオプション
$ ./configure --help
[…省略…]
Optional Features:
--disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
[…省略…]
--enable-file-cache     File cache
--enable-echo           ECHO server
--disable-charset-lite  character set translation
[…省略…]
--enable-static-checkgid
                        Build a statically linked version of checkgid
--enable-http           HTTP protocol handling
--disable-mime          mapping of file-extension to MIME
[…省略…]

Apache 2.0ではHTTP通信のための処理が通常のモジュールとして実装されていて（モジュール名はhttp_coreです），他のモジュールの場合と同様，そうしたければApacheから取りはずしてしまうことすら可能となりました．もちろん実際に取りはずしてしまえばHTTPサーバとしては機能しなくなりますから，一般にはそのようなことは行われないでしょうし，デフォルトでもhttp_coreは組み込みモジュールとして構築されます．したがって，特に指定しない限りは従来通りデフォルトでHTTPの処理を行うことができます．

逆に，http_coreと同じような別のプロトコルのためのモジュールを作って，そちらを組み込むようにすれば ApacheをHTTP以外のサーバに仕立て上げることが可能となってきます．

この機能はまったく新しいもので，しかも登場したばかりなのですが，これを活用したモジュールは既に存在しています． 1つはApache 2.0のソースに同梱されているmod_echoモジュールで，これはechoサーバをApache上に実装しています．また，この他にPOPモジュールが開発されてます．

Apacheによるechoサーバ

echoサーバというのは，クライアントから受け取ったデータをそのまま送り返すという動作をするサーバです． inetdなどにはこの機能が組み込まれているものもあり，設定で有効になっていればポート7にアクセスすることでechoサーバに接続できます．実際にアクセスすると次のようになります．

$  telnet localhost echo
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
foo
foo
bar
bar

さて，Apacheでのechoサーバですが，前述した通りmod_echoにおいて実装されており， configure時に--enable-echoを指定しておくと利用可能になります．ディレクティブとしてはechoサーバとして動作するかどうかを制御する ProtocolEchoだけが用意されていて， echoサーバ機能をOn/Offで制御することが可能です．

たとえば以下のような設定を加えると， Apacheはポート8007のバーチャルホストにおいて入力をそのまま送り返すというechoサーバとして動作します．

<VirtualHost _default_:8007>
  ProtocolEcho On
</VirtualHost>

サービスの内容からいってもmod_echoの位置付けあるいは意義はマルチプロトコル対応に関するサンプル提供であろうと思われます．これに対し，POPモジュールはこれよりももう少し実用的なものを目指しているようです．執筆時点ではまだリリースはされていませんが，ある程度の範囲では動作しているようです．

以上のようにマルチプロトコル対応は未来のApacheの可能性を予感させるもので，ユーザとしても楽しみなところではありますが，今はまだそれを使ったモジュールの開発が進みつつあるという状況です．このため現在のところはどちらかと言えば開発者にしか関係しないトピックと言えるでしょう．

APR（Apache Portable Runtime）の導入

図1に示すように，APRが導入されたことによって，従来はApacheのモジュールから直接OSにアクセスしていたのが，間にAPRをはさんで間接的にOSにアクセスする構成となりました． APRの実体はライブラリであり， ApacheモジュールがOSにアクセスする必要がある場合，たとえばファイルを開くとかファイルに書き込むとか，そういった操作の一切をAPRに用意された関数を通して行うわけです．

前: [モジュール]---------->[OS]
後: [モジュール]-->[APR]-->[OS]
図1 APR導入前・導入後

このような構成になったことによって移植性やモジュールの保守性が非常に良くなることが予想されています．というのも，これまでは各種のモジュールの中でプラットフォーム対応を行っていたのですが，これによって次のような状況が発生していました．

似たようなコードが散乱している

UNIXの場合はこう，MS-Windowsの場合はこう， …といった場合分けが広い範囲に分布しており，その部分の保守性が非常に悪い．また新しく対応プラットフォームを増やそうとした場合（や， OSのバージョンアップに伴って変更が必要となった場合）に広い範囲で修正が必要となる．
モジュールによってプラットフォームへの対応状況が異っている

多くのプラットフォームに対応しているかどうかは，そのモジュールの開発者たちがどれくらいがんばっているかに依存する．開発者のすべてが様々なプラットフォームに精通しているわけではないため，ある種のモジュールは特定のプラットフォームでしか利用できない．

APRが導入されたことによって，モジュールはプラットフォームの違いという非常に難しい問題から（少なくともある程度は）解放されることになるでしょう．前述の通り，OSへのアクセスはAPRを介して行われますから， APRにおいて各種プラットフォームへの対応が進めば，モジュールの方では何もしなくても対応プラットフォームが増えていくことになります．

ただし，APRが導入されたことによって困ったこともあります．それはApacheとしてのAPIが大きく変わってしまったことです．これにより，1.3系で使われてきたモジュールの多くは，そのままではApache 2.0では利用できません．各モジュール（特にサードパーティモジュール）では Apache 2.0に対応させるための作業を行わなくてはならず．また，次に説明するMPMが導入されたこともあいまって，現時点では多くのモジュールが限定的にしかApache 2.0に対応していないという状況です．

モジュールの更新が進み，メジャーなモジュールがApache 2.0対応してくると，プラットフォームに関係なくモジュールが利用できるようになります．その意味では関発者以外にも無関係ではありませんが，現状ではその段階にまでいたっていません． APRについてもやや開発者寄りのトピックと言えるでしょう．

MPM（Multi Processing Module）の導入

従来，Apacheとして最も基本となる次の3つの「仕事」はある1つの方針に沿って行われてきました．

リクエストを待ち受けるポートを開く
リクエストを受け付ける
受けたリクエストを実働部隊に割り振る

ここで実働部隊というのはApacheの子プロセスです．ご存知の通り，Apacheでは特定の親プロセスの制御下で，各子プロセスが個々のリクエストを処理するという構成になっているます．このため同時に処理するリクエスト数に応じた数の子プロセスが必要です．この戦略はApacheそのものの動作として固定されていて，いかに柔軟なカスタマイズのできるApacheといえどもこれを変更することはできませんでした．

しかしApache 2.0では違います． Apache 2.0においてはこういった非常にコアな部分まで含めて例外なくモジュール化されました．それらのモジュールはMPMと呼ばれ，コンパイル時のオプションによって選択することができます．バージョン2.0.39では以下に挙げる9種類のMPM（=戦略）が提供されています．

prefork: 1.3系で行われていたのと同じように必要に応じて子プロセスを起動する． UNIX環境でのデフォルトのMPM．
worker: 状況に応じていくつかの子プロセスを作り，各子プロセスではリクエスト処理用に指定された数だけスレッドを生成する．スレッド対応MPMの一つ．
leader: スレッド対応MPMの一つ．スレッドの使い方がwokerとは異る．
threadpool: スレッド対応MPMの一つ．スレッドの使い方がwokerとは異る．
perchild: スレッド対応MPMの一つ．指定された数の子プロセスを作り，その中でスレッドを生成しリクエストを処理する．各子プロセスを特定のユーザ権限で動作させることができる．
beos: BeOS用のMPM．リクエストはスレッドを使って処理する．ただしプロセスは一つだけで，子プロセスを生成しない．
mpmt_os2: OS/2用のMPM．指定された数の子プロセスを作り，各子プロセスでは必要に応じてスレッドを生成する．
netware: NetWare用のMPM．
winnt: MS-Windows NT用のMPM．リクエストはスレッドを使って処理する．ただしプロセスは一つだけで，子プロセスを生成しない．

ご覧の通り，MPMについては各種のプラットフォームごとに専用のものが用意されています．これは各プラットフォームにより適した形でリクエストを処理できるようにするためです．

スレッド対応とMPM

Apache 2.0の特徴の一つとして挙げられることの多いスレッド対応の実態は，スレッドを使ったMPMが提供されたことです．スレッド対応のMPMを選択することで個々のリクエストの処理はスレッドを使って行われるようになります．ただし，現在提供されているUNIX環境用のスレッド対応MPMは，いずれも子プロセスとスレッドの両方を使ったハイブリット構造をとっていて，単一プロセスですべての処理が行われるということはありません．

ともあれ，スレッド対応MPMが提供されたことによって，高負荷時のパフォーマンスなどが良くなるということが予想されています．しかしその副作用として，スレッド対応MPMを選択した場合には，モジュールのすべてにスレッドセーフであることが期待されるようになります． Apache 2.0に対応しているモジュールの中には，完全にはスレッドセーフではないための，スレッド化されていないprefork MPMの下でなければ動作しないというものもあります．おそらく今後はこの状況は改善されていくでしょうが，どうしても必要なモジュールがある場合には，そのモジュールがどのMPMで動作可能なのかを確認しておかなくてはなりません．

ところでUNIX環境用のスレッド対応のMPMとしては worker，leader，threadpool，perchildと4種類のMPMが提供されています．これらは，それぞれにスレッドや子プロセスの使い方が異っています． perchildだけはやや特殊なのですが，それ以外の3つはそれぞれに高パフォーマンスを目指した実装がなされており，負荷のかかり形によってパフォーマンスが違ってくるようです．現在のところleader MPMとthreadpool MPMは実験的という位置付けになっていますが，今後はこのあたりの状況も変わってくるかもしれません．

perchild MPM

ここでperchild MPMについてもう少し詳しく紹介しておきます．

表2に示した通りperchild MPMの特徴は子プロセスを特定のユーザ権限で動作させられることですが，それに加えてバーチャルサーバごとにユーザ権限を細く設定してやることが可能だという特徴があります．この2つの特徴を使うと，各バーチャルホストに対して特定のプロセスを割り当てることが可能となります．

たとえばリスト2のように設定したとします． ChildPerUserIdディレクティブで設定しているのは n番目の子プロセスを指定したユーザ・グループの権限で動作させるということです．またVirtualHostコンテナ内の AssignUserIdディレクティブでは，そのバーチャルホストに対して指定したユーザ・グループの権限で動作しているプロセスを割り当てるということを指示しています．したがって，バーチャルホストの数だけプロセスを用意し，それぞれのユーザ権限を違えておくことによって，結果的にバーチャルホストごとに完全に個別のプロセスを割り当てることができるわけです．

リスト2 perchild MPMのための設定（抜粋）
<IfModule perchild.c>
  NumServer 5
  […省略…]
  ChildPerUserId www-abc www 3
  ChildPerUserId www-xyz www 4
  […省略…]
  <VirtualHost ...>
    ServerName abc.example.com
    AssignUserId www-abc www    
    […省略…]
  </VirtualHost>
  <VirtualHost ...>
    ServerName xyz.example.com
    AssignUserId www-xyz www    
    […省略…]
  </VirtualHost>
</IfModule>

一部のモジュールではモジュール全体に影響の与え得る状態（あるいは変数）を持っている場合があります．このような場合，バーチャルホスト間でプロセスを共有する従来の方式では，バーチャルホスト同士を完全に独立にすることはできません．しかしperchild MPMを使えばそれが可能となり，バーチャルホスト間の独立性をより完全なものとすることができます．

perchild MPMはまだ実験的なものですので，今後仕様が変更されることがあるかもしれません^*2が，他のスレッド対応MPMとはまた違った特徴を持っており，数あるMPMの中でも注目したいMPMの一つと言えます．

IPv6対応

1.3系のApacheではパッチをあてるなどしないと IPv6でのサービスを行うことができませんでしたが， Apache 2.0では最初からIPv6に対応しています．これに伴っていくつかのディレクティブは IPv6アドレスが記述できるよう拡張されています．

IPv6環境が一般的になるまでにはまだ時間がかかるようですが，すでにIPv6環境を整えている人々にとってはこのことは大きな利点となるでしょう．

フィルタ機能の導入

ユーザにとってもっとも大きな変化と言えるのは，このフィルタ機能が登場したことではないかと思っています．

従来のApacheがリクエストを処理する際の流れをおおまかに説明すると次のようになります．

リクエストを受け取る
リクエストされたURLに応じたリソースを決定する
リソースに応じたハンドラを決定する
ハンドラを作用させレスポンスを作る
レスポンスを送り返す

この中のリソースというのは一般にファイルであることが多いわけですが， mod_infoやmod_statusのケースのように必ずしもファイルに結び付けられるわけではありません．ともあれ扱うべきリソースが決まると，それに応じてハンドラが決まります．デフォルトのハンドラはファイルを開いてその内容を取り出すというものです．この他，CGIハンドラやSSIハンドラがあって，それぞれ次のような動作をします．

CGIハンドラ: ファイルをCGIスクリプトとして実行し，その出力からレスポンスを作る
SSIハンドラ: ファイルの中の特定の記述を予め定められたルールに従って変換し，その変換結果からレスポンスを作る

もちろんこの他にも様々なハンドラが用意されていますし，サードパーティモジュールによっても多くのハンドラが提供されています．

さて，ここで注意したいのは 1つのリソースに対して割り当てられるハンドラは1つだけだということです．つまりCGIハンドラで処理したものをさらにSSIハンドラで処理するというようなことはできません．どうしてもCGIプログラムの出力をSSIとして処理したければ， CGIハンドラを拡張してSSIハンドラに備っている機能を加えてやるしかありませんでした．

出力フィルタ

Apache 2.0では新たな概念であるフィルタが導入されました．ここでいうフィルタはUNIXのコマンドラインで一般に使われているフィルタと同じようなイメージでとらえることができます．

foo_handler resource | output_filter1 | output_filter2 | …

Apache 2.0ではハンドラの出力は基本的にフィルタを通してからクライアント（ブラウザ）に送り返されるようになっています．特に設定がされていなければハンドラの出力がそのままレスポンスになりますが，フィルタが設定されている場合には，ハンドラの出力はそのフィルタによってなんらかの加工をされてからクライアントに送られます．この時の処理の流れは次のようになります．

リクエストを受け取る
リクエストされたURLに応じたリソースを決定する
リソースに応じたハンドラを決定する
ハンドラを作用させ出力を得る
出力をフィルタに渡し，その結果からレスポンスを作る
レスポンスを送り返す

Apache 2.0に同梱されているフィルタは次の3つです（それぞれモジュールになっています）．このうちのmod_includeはSSIのためのもので，従来はハンドラとして実装されていましたが， Apache 2.0においてフィルタとして実装され直しました．

mod_defalte - 出力を圧縮するためのフィルタDEFLATEを提供する．
mod_include - SSIを実現するINCLUDESフィルタを提供する．
mod_ext_filter - フィルタを定義する機能を提供する．ただし実験的．

フィルタは1つでなくてもかまいません．複数のフィルタを設定すれば何重にもフィルタを通すことが可能です．設定上は次のようになります．

AddOutputFilter INCLUDES;DEFLATE shtml

この設定は拡張子がshtmlであるファイルに対して INCLUDESとDEFLATEという2つのフィルタを適用することを Apacheに指示しています（SSIの解釈を行った上で圧縮）．また，次のようにして特定の位置のリソースに対してフィルタを指定することもできます．以下の例では/www/data以下に置かれているファイルに対して DEFLATEを適用します．

<Directory /www/data/>    
  SetOutputFilter DAFLATE
</Directory>

ところで，出力フィルタがあるからには入力フィルタもあるのだろうと思われた人も多いでしょう．入力フィルタについてはAddInputFilterや SetInputFilterによって割り当てが可能となっています．

mod_ext_filter

mod_ext_filterは他のフィルタモジュールとはちょっと違った機能を持っています．このモジュールは特定の機能を持ったフィルタを提供するのではなく，設定によってその場でフィルタを定義するためのものです．具体的な例を示しましょう（リスト3）．

リスト3 mod_ext_filterの利用例
ExtFilterDefine giftopnm mode=output \
  intype=image/gif outtype=image/pnm \
  cmd="/usr/bin/giftopnm"
ExtFilterDefine pnminvert mode=output \
  intype=image/pnm outtype=image/pnm \
  cmd="/usr/bin/pnminvert"
ExtFilterDefine pnmtopng mode=output \
  intype=image/pnm outtype=image/png \
  cmd="/usr/bin/pnmtopng"
<VirtualHost _default_:8080>
  <Location />
    SetOutputFilter giftopnm;pnminvert;pnmtopng
  </Location>
</VirtualHost>

フィルタはExtFilterDefineディレクティブによって定義することができます．最初の引数はフィルタに付ける名前で，次のmode=outputは出力時に適用するフィルタであることを示します． intypeではフィルタをかけるべきメディアタイプを指定し， outtypeではフィルタをかけた後の（つまり変換をした後の）メディアタイプを指定します．最後のcmdが重要で，ここには任意のコマンドを指定できます．

以上で定義したフィルタが適用されると， cmdで指定したコマンドが起動され，レスポンスのためのデータがコマンドの標準入力から注入されます．コマンドはそれを受け取って，必要な変換作業を行い，結果を標準出力に書き出さなくてはなりません．一方，Apacheはコマンドの標準出力から変換後のデータを読み出し，それを元にレスポンスを構成します．

リスト2の例について言えば次のような動作をします．

ポート8080で動作するバーチャルホストにおける，すべてのリソースについてフィルタが適用される
ただし，実際に変換が行われるのはメディアタイプがimage/gifであるデータだけ
image/gifであるデータはフィルタgiftopnmによってpnm形式に変換される（この際，メディアタイプがimage/pnmになる）
image/pnmとなったデータは，さらにフィルタpnminvertによって変換される
image/pnmであるデータは，またさらにフィルタpnmtopngによって変換され，最終的にimage/png形式となる

同じことをコマンドラインで行うとするとこうなります．

$ cat input.gif | giftopnm | pnminvert | pnmtopng > output.png

また，このような設定をしたサイトにアクセスをすると図2のようになります．同図の上半分はフィルタが設定されていないデフォルトのサイトにアクセスした様子で，下半分がフィルタを設定したバーチャルホストにアクセスした様子です．イメージの色が反転していることがおわかりいただけるでしょうか．

図2: mod_ext_filterのテスト

通常，新しくフィルタを作る場合には，ハンドラを使る場合と同じくC言語によるプログラミングが必要となります．しかしmod_ext_filterを使うことによって，このように簡単にフィルタを作ることができます．もっとも，mod_ext_filterによるフィルタはいちいちコマンドを起動する必要があるため，ある程度以上のアクセスのあるサイトにおいてはあまり実用的とは言えません．このため，mod_ext_filterはテスト用もしくはプロトタイプ用としてだけ使用し，本格的な運用の際にはC言語で書いたフィルタを使うといったように，うまく使い分ける必要があるでしょう．

Apache 2.0に移行する際の注意点

これまでにも触れてきましたが Apacheをバージョン2.0にアップグレードすることに際して，いくつか問題となりそうなポイントがあります．特に重要だと思われるものについて以下にまとめておきます．

サードパーティモジュール

Apache 2.0に同梱されているモジューについては心配する必要はありませんが， Apacheとは別に開発されているサードパーティモジューについては Apache 2.0に対してどの程度対応しているかを前もって調べておく必要があります．特に次の2点が重要です．

APRに対応しているかどうか

これはおおまかな意味でApache 2.0に対応しているかどうかということにつながります． 1.3系のために作られたモジュールは，基本的に新しいAPIに対応していませんのでそのままでは（コンパイルし直しても）利用することはできません．
スレッド化MPMにも対応しているか

スレッド対応のMPMを使って運用する必要がある場合，モジューがスレッドセーフであるかどうかがポイントになってきます．またモジュールの方で対応MPMが限定されているケースもあります．

必要なモジュールがApache 2.0で動かない場合や， Apache 2.0に対応してはいても特定のMPMでしか利用できない場合には，何を優先するかで選択肢が変わってきます．いずれにしても移行前の調査が重要です．

設定ファイルについての変化

いくつかのディレクティブが整理され統廃合されました．特に重要なものを以下に示します．

AccessConfig，ResourceConfig - Includeで置換
AgentLog，RefererLog - CustomLogで置換
BindAddressとPort - ListenとServerNameで対応
FancyIndexing - IndexOptionsで対応
VirtualHost中のUserとGroup - SuexecUserGroupで対応

また以下のディレクティブは廃止されました．

ServerType - 動作がMPMで定義されるため
AddModule，ClearModuleList - ロードする順番をユーザが気にする必要がなくなったため

その他の注意点

mod_includeがハンドラではなくフィルタになったために， PATH_INFOについての扱いが変わっています．従来はハンドラの中でPATH_INFOを処理していましたが，フィルタになってしまったことによって PATH_INFOを処理をすることができなくなりました．というのは，特にハンドラを割り当てなかった場合に使われる，いわばデフォルトのハンドラであるコアハンドラが PATH_INFO付きのリクエストを拒絶してしまうためです． mod_includeに限らず，ハンドラからフィルタに変わったものについては注意が必要です．

AcceptPathInfoディレクティブによって，コアハンドラのこの挙動を変更することが可能です．

まとめ

以上，Apache 2.0の新機能を概観してきましたが， 1.3系→2.0系への変化は実際に大きなものであることがわかります．ところが，その変化の多くが根底部分において起ったために，また，よりユーザに近い部分での調整が長い時間をかけて行われたために，一ユーザの視点からではなかなかその変化と効果が見えてきません．そしてそれは状況からして仕方のないことでもあるかもしれません．

しかし，今回のこの変化が根本的なものであるがために，その効果はもう少し後になって，時間がたってからじょじょに現れてくるであろうと思われます．たとえば，APRが導入されたことによるメリットは多くのサードパーティモジュールがApache 2.0に対応してきた頃に見えてくるでしょうし， MPMを選択できることの効果は条件の厳しいサーバで運用されるようになってきたころに現れるでしょう．マルチプロトコルについても，様々な実装が出てくる中で，今までには考えられなかった応用が可能となるかもしれません．

冒頭で触れたTechStyleセミナーのパネルディスカッションの中で安東先生がおっしゃっておられましたが， Apache 2.0の効果を実証するたにはより多くの人々が実際に使ってみることが重要です．不具合を見付けたら，どんどんレポートしていけるとさらに良いでしょう．この記事を読んで一人でも多くの人が「Apache 2.0，試してみようかな」と思っていただければうれしく思います．

^*1正確にはApache HTTPサーバと表記すべきですが，ここでは単にApacheと表記しています．この記事では特にことわりがない場合は Apache HTTPサーバのことを指しています．
^*22.0.39では perchild MPMで動作させることができませんでした．そのため，この部分の記述は2.0.36での実験に基づいています．