Apache HTTP サーバ バージョン 2.4
Apache HTTP サーバ バージョン 2.4
| 関連モジュール | 関連ディレクティブ |
|---|---|
CGI (Common Gateway Interface) は、ウェブサーバが コンテンツ生成をする外部プログラムと協調して動作するための方法を 定義しています。そのプログラムはしばしば CGI プログラムや CGI スクリプトと呼ばれます。CGI は、ウェブサイトに動的な コンテンツを置くための最も簡単で一般的な方法です。このドキュメントは、 Apache ウェブサーバで CGI を設定し、 CGI プログラムを書き始めるための入門書となるでしょう。
CGI プログラムを正しく動作させるには、CGI を許可するように Apache の設定を行う必要があります。 これを行なうための方法がいくつかあります。
httpd.conf で
LoadModule
がコメントアウトされていないことを確認してください。
正常に設定されていれば次のようになるはずです:
LoadModule cgi_module modules/mod_cgi.so
ScriptAlias
ディレクティブを使用して、
CGI プログラム用の特別な別ディレクトリを Apache に設定します。
Apache は、このディレクトリ中の全てのファイルを CGI
プログラムであると仮定します。
そして、この特別なリソースがクライアントから要求されると、
そのプログラムの実行を試みます。
ScriptAlias
ディレクティブは以下のように使用します:
ScriptAlias /cgi-bin/ /usr/local/apache2/cgi-bin/
デフォルト位置に Apache をインストールしたならば、
この例はデフォルト状態の httpd.conf
設定ファイルに含まれています。
ScriptAlias
ディレクティブは、URL の前に付加するディレクトリを定義する
Alias
ディレクティブとかなり似ています。
Alias と ScriptAlias
は通常、DocumentRoot
ディレクトリ外のディレクトリのために使用されます。
Alias と ScriptAlias
との差は、ScriptAlias が接頭辞で始まるすべての
URL は CGI プログラムとみなされるという追加の意味を含んでいることです。
従って、上記の例では、/cgi-bin/
で始まるリソースへのあらゆるリクエストに対して、ディレクトリ
/usr/local/apache2/cgi-bin/ から提供し、それらを
CGI プログラムとして扱うよう Apache に示します。
例えば、URL http://www.example.com/cgi-bin/test.pl
が要求された場合、Apache は ファイル
/usr/local/apache2/cgi-bin/test.pl
を実行し、その出力を返すことを試みます。
もちろん、ファイルが存在し、実行可能であり、決められた方法で出力を返します。
そうでなければ、Apache はエラーメッセージを返します。
CGI プログラムは、セキュリティ上の理由から
ScriptAlias
されたディレクトリに制限されることがしばしばあります。この方法により、
CGI プログラムを使用できるユーザを管理者が厳しく制御することができます。
しかしながら、適切なセキュリティ事前対策がとられるならば、CGI
プログラムを任意のディレクトリで実行できないようにする理由はありません。
例えば、ユーザに UserDir
ディレクティブで彼らのホームディレクトリ配下にウェブコンテンツを持たせたいとします。
もし、彼らが CGI プログラムを持つことを望んでいても、メインの
cgi-bin ディレクトリへのアクセスができない場合、
CGI プログラムを実行することができる他の場所が必要になります。
任意のディレクトリで CGI の実行を許可するには二段階の設定が必要です。
まず、AddHandler や SetHandler ディレクティブによって
cgi-script ハンドラが可能になっている必要があります。
次に、Options ディレクティブで
ExecCGI が指定されていなければなりません。
サーバのメインの設定ファイル中で Options
ディレクティブを明示的に使用することで、特定のディレクトリ配下で
CGI の実行を許可するように指定することができます:
<Directory /usr/local/apache2/htdocs/somedir>
Options +ExecCGI
</Directory>
上記ディレクティブは、CGI ファイルの実行を可能にするよう
Apache に伝えます。また、どのファイルが CGI ファイルかを
サーバに伝える必要があります。次の
AddHandler
ディレクティブの例では、cgi または pl
を拡張子に持つすべてのファイルを CGI
プログラムとしてみなすことをサーバに伝えます:
AddHandler cgi-script .cgi .pl
.htaccess チュートリアル
は httpd.conf を変更できない場合にどうやって CGI プログラムを
使えるようにするかを説明しています。
.cgi で終わるすべてのファイルに対して CGI プログラムの
実行を許可するには、以下の設定を使用できます。
<Directory /home/*/public_html>
Options +ExecCGI
AddHandler cgi-script .cgi
</Directory>
ユーザディレクトリの cgi-bin サブディレクトリの
すべてのファイルを CGI プログラムとして指定したい場合には
以下のようなものを使います。
<Directory /home/*/public_html/cgi-bin>
Options ExecCGI
SetHandler cgi-script
</Directory>
「通常の」プログラミングと CGI プログラミングの間には主に二つの違いがあります。
一つは、CGI プログラムのすべての出力にはMIME タイプ ヘッダを付けなければなりません。 これはどのような種類のコンテンツを受け取っているかをクライアントに示す HTTP ヘッダです。ほとんどの場合では、次のように出力します:
Content-type: text/html
もう一つは、出力を HTML か、ブラウザが表示することができる何か他の形式にする必要があります。 大抵の場合は HTML でしょうが、GIF イメージや他の非 HTML コンテンツを出力する CGI プログラムを書くこともあるでしょう。
これら二点以外では、CGI プログラムを書くことは、 あなたが書いている他のプログラムとよく似ているでしょう。
次に示すのは、ブラウザに 1 行印字する CGI
プログラムの例です。以下を入力し、first.pl
というファイルに保存し、それを cgi-bin
ディレクトリに置いてください。
#!/usr/bin/perl
print "Content-type: text/html\n\n";
print "Hello, World.";
Perl に精通していなくても、
何が起こるかを理解することはできるでしょう。1 行目は、
/usr/bin/perl で見つけられるインタプリタに
このファイルを供給することでこのプログラムが実行されることを
Apache に (シェル上で実行しようとしているならば、そのシェルに )
示します。2 行目は、前述したとおり content-type の定義を印字します。
これには復帰改行の二つの組を後に付加します。
これにより、ヘッダの終りに空行が置かれ、HTTP
ヘッダの終りとボディの始まりを示します。3 行目は、"Hello, World."
という文字列を印字し、これで終りとなります。
好みのブラウザを開き、アドレス
http://www.example.com/cgi-bin/first.pl
あるいはファイルを置いたロケーションを指定すると、
Hello, World.
という 1 行がブラウザウィンドに現れるでしょう。
それはあまりエキサイティングなことではありません。
しかし、これがうまく動けば、
他のどのようなものでも動かすことができるようになります。
ウェブから CGI プログラムへのアクセスを行なったとき、 ブラウザで見る可能性がある四つの基本的なことがあります:
Content-Type を CGI プログラム内で
セットしたかを確認してください。サーバはあなたの権限で実行されていないのを忘れないように。
つまり、起動するとき、サーバは特権をもたないユーザ - 通常 nobody
や www の権限で実行されます。したがって、あなたが所有する
ファイルを実行するには別のパーミッションが必要となります。
通常、nobody が実行するのに十分なパーミッションを与える方法は、
ファイルに誰でも実行可能とするパーミッションを与えることです:
chmod a+x first.pl
また、もしあなたのプログラムが他のファイルを読み書きするならば、 それらのファイルは、これが可能となる正しいパーミッション を持っている必要があります。
コマンドラインからプログラムを実行するとき、
意識しなくてもシェルに渡される情報があります。
例えば、参照するファイルのためにどこを検索したらよいかを
シェルに伝える PATH があります。
プログラムが CGI プログラムとしてウェブサーバによって実行されるとき、
それは同じ PATH ではないかもしれません。
CGI プログラム内で呼び出すあらゆるプログラム
(例えば、sendmail のようなもの) は、
フルパスで指定する必要があるでしょう。それにより、CGI
プログラムを実行しようとしたとき、
シェルはそのようなプログラムを見つけることができます。
同様なことは、スクリプトのインタプリタ (しばしば perl)
へのパスで、CGI プログラムの 1 行目に次のように示されます:
#!/usr/bin/perl
これがインタープリタへの実際のパスであることを確認しておきます。
また、CGI プログラムが他の環境変数に依存している場合は、その環境変数が Apache から渡されるようにする必要があります。
CGI プログラムが失敗するのは大抵、プログラム自身に問題がある場合です。 一度 CGI の使い方を理解し、前述の二つの誤りを犯していないならば、 まず間違いなくそうでしょう。ブラウザを使ってテストする前に まず確認することは、コマンドラインからプログラムが実行できることです。 例えば、以下を実行してみてください:
cd /usr/local/apache2/cgi-bin
./first.pl
(perl インタプリタは呼ばないでください。
シェルと Apache がスクリプトの最初の行の パス情報 を使って見つけます。)
最初にプログラムから出力されるのは Content-Type を含み、
後に空行の続く HTTP ヘッダでなければなりません。他のものが出力されている
場合は、Apache はこのプログラムをサーバ経由で実行しようとしたときには
Premature end of script headers エラーを出力します。詳細は
上記の CGI プログラムを書く を読んでください。
エラーログは友達です。 全てのうまくいかないことは、エラーログにメッセージを生成します。 必ずそれを最初に見るべきです。 もし、あなたがウェブサイトを主催している場所が エラーログの参照を許していないならば、きっと他のサイトで主催するべきです。 エラーログの読み方を学ぶことで、ほとんど全ての問題が迅速に確認され、 迅速に解決されるということが分かるでしょう。
suexec サポートプログラムは
バーチャルホストやユーザのホームディレクトリの場所に依って
CGI プログラムを違うユーザ権限の下で走らせることを可能にします。
Suexec の権限のチェックは非常に厳しく、それを満たさない場合は
CGI プログラムが Premature end of script headers エラーで
実行されません。
suexec を使っているかどうかを調べためには apachectl
-V を実行して、SUEXEC_BIN の場所を調べてください。
Apache がそこに suexec のバイナリを発見した場合は、suexec が
使用されます。
suexec を完全に理解していない限り、使うべきではありません。
suexec を無効にするには、SUEXEC_BIN から指されている
suexec バイナリを削除 (か名前を変更) するだけです。
suexec を読んだ後で、まだそれを
使いたいのであれば、suexec -V を実行して suexec の
ログファイルの位置を調べ、そのログファイルを使ってポリシー違反を
見つけてください。
CGI プログラミングに習熟すると、 裏で起こっていることについて更に理解することの役に立ちます。 ブラウザとサーバがどのように相互通信するかについては特にそうです。 なぜなら、"Hello, World." を印字するプログラムを書くことはおおいに結構ですが、 それは特に有益ではありません。
環境変数は、
あなたがコンピュータを使うときに辺りに存在している値です。
それらは、パス
(コマンドをタイプしたときに実行する実際のファイルを探し出すところ)、
ユーザ名、端末型などのような便利なものです。
通常、普段使用している環境変数の完全なリストを調べるには、
コマンドプロンプトで env を入力します。
CGI の処理中、サーバとブラウザも環境変数を設定し、 それにより相互に通信することができるようになります。 その環境変数は、ブラウザタイプ (Netscape, IE, Lynx)、サーバタイプ (Apache, IIS, WebSite)、実行されている CGI プログラムの名前などです。
これらの変数は CGI プログラマが使用できます。 そして、それはクライアントとサーバの通信の話の半分です。 必要な変数の完全なリストは http://hoohoo.ncsa.uiuc.edu/cgi/env.html にあります。
以下の単純な Perl CGI
プログラムは、渡される全ての環境変数を表示します。同様のプログラムは、
Apache ディストリビューションの cgi-bin
ディレクトリに二つ含まれています。
いくつかの変数が必須であり、いくつかは任意であることに注意してください。
そして、公式のリストにはないいくつかの変数が表示されているかもしれません。
さらに、Apache はデフォルトで用意されている基本的なものに
あなた自身の環境変数を加えるための、
多くの異なる方法を用意してします。
#!/usr/bin/perl
print "Content-type: text/html\n\n";
foreach $key (keys %ENV) {
print "$key --> $ENV{$key}<br>";
}
サーバとクライアント間のもう一つの通信は、標準入力
(STDIN)と標準出力 (STDOUT)
を通じて行なわれます。通常の文脈において、STDIN
はキーボードやプログラムが動作するために与えられるファイルを意味し、
STDOUT は通常コンソールまたはスクリーンを意味します。
ウェブフォームから CGI プログラムへPOST
したとき、フォームのデータは特別なフォーマットで束ねられ、
STDIN を通して、CGI プログラムに引き渡されます。
プログラムはデータがキーボード
もしくはファイルから来ていたかのように処理することができます。
「特別なフォーマット」はとても単純です。フィールド名と値はイコール (=) で結ばれます。そして値の組はアンパサンド (&) で結ばれます。 スペース、アンパサンド、イコールのような面倒な文字は、 それらが動作を駄目にしないようにその文字に相当する 16 進に変換されます。 全データ文字列は、以下のようになります:
name=Rich%20Bowen&city=Lexington&state=KY&sidekick=Squirrel%20Monkey
時々、このような文字列が URL
に付加されるのを見るでしょう。その場合、サーバは
QUERY_STRING という環境変数にその文字列を入れます。それは
GET リクエストと呼ばれます。
HTML フォームでは、データを渡すために GET と
POST のどちらを使用するかを、FORM タグの
METHOD 属性の設定で指定します。
CGI プログラムは、その文字列を役に立つ情報に分割する責任があります。 幸いにも、そのデータ処理を助けるライブラリやモジュールが存在します。 これらは、CGI プログラムの他の面でも同様に役に立ちます。
CGI プログラムを書くとき、面倒な仕事の大部分をしてくれる コードライブラリまたはモジュールを使うことを検討すべきです。 これはエラーを減らし、早い開発につながります。
Perl で CGI プログラムを書いているなら、モジュールは CPAN で提供されています。
この目的のための最も普及しているモジュールは CGI.pm です。
CGI::Lite も検討しましょう。これは、ほとんどのプログラム
において必要とするすべての機能の最小セットの実装です。
C で CGI プログラムを書いているなら、いろいろな
オプションがあります。これらの内の一つは http://www.boutell.com/cgic/
で提供されている CGIC ライブラリです。
CGI に関する情報はウェブで数多く提供されています。CGI の問題については Usenet の comp.infosystems.www.authoring.cgi で、 他のユーザと論議することができます。HTML Writers Guide の -servers メーリングリストは、あなたの質問に回答してくれる偉大なリソースです。 http://www.hwg.org/lists/hwg-servers/ で更に多くを探し出すことができます。
そしてもちろん、おそらく CGI プログラムの動作に関する詳細の全てが記述されている CGI の仕様を読むべきです。オリジナルバージョンを NCSA で、アップデートされたドラフトを Common Gateway Interface RFC プロジェクトで参照することができます。
CGI の問題について、加わっているメーリングリストまたはニュース グループに質問を送るとき、起こったもの、起こってほしいこと、 実際に起こったことがどう違うか、使用しているサーバ、 CGI プログラムを記述している言語に関する十分な情報と、 可能であれば問題のコードを提供するようにしてください。 そうすることで、問題がより間単に見つかるようになります。
Apache のソースコードにおいて問題を発見したことを確信していない限り、 CGI の問題に関する質問を Apache バグデータベースに送るべきでない ことに注目してください。