Apache Tutorial: CGI による動的コンテンツ - Apache HTTP サーバ バージョン 2.4

Apache HTTP サーバ バージョン 2.4

Apache > HTTP サーバ > ドキュメンテーション > バージョン 2.4 > How-To / チュートリアル

# Apache Tutorial: CGI による動的コンテンツ

翻訳済み言語: en | es | fr | ja | ko

この日本語訳はすでに古くなっている 可能性があります。 最近更新された内容を見るには英語版をご覧下さい。

### 参照

- コメント

## はじめに

関連モジュール | 関連ディレクティブ
--- | ---

- `mod_alias`
- `mod_cgi`

- `AddHandler`
- `Options`
- `ScriptAlias`

CGI (Common Gateway Interface) は、ウェブサーバが コンテンツ生成をする外部プログラムと協調して動作するための方法を 定義しています。そのプログラムはしばしば CGI プログラムや CGI スクリプトと呼ばれます。CGI は、ウェブサイトに動的な コンテンツを置くための最も簡単で一般的な方法です。このドキュメントは、 Apache ウェブサーバで CGI を設定し、 CGI プログラムを書き始めるための入門書となるでしょう。

## CGI を許可するように Apache を設定する

CGI プログラムを正しく動作させるには、CGI を許可するように Apache の設定を行う必要があります。 これを行なうための方法がいくつかあります。

注: Apache が共有モジュール機能着きでビルドされている場合、 モジュールがロードされていることを確認してください。 つまり `httpd.conf` で `LoadModule` がコメントアウトされていないことを確認してください。 正常に設定されていれば次のようになるはずです:

`LoadModule cgi_module modules/mod_cgi.so`

### ScriptAlias

`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 はエラーメッセージを返します。

### ScriptAlias ディレクトリ外の CGI

CGI プログラムは、セキュリティ上の理由から `ScriptAlias` されたディレクトリに制限されることがしばしばあります。この方法により、 CGI プログラムを使用できるユーザを管理者が厳しく制御することができます。 しかしながら、適切なセキュリティ事前対策がとられるならば、CGI プログラムを任意のディレクトリで実行できないようにする理由はありません。 例えば、ユーザに `UserDir` ディレクティブで彼らのホームディレクトリ配下にウェブコンテンツを持たせたいとします。 もし、彼らが CGI プログラムを持つことを望んでいても、メインの `cgi-bin` ディレクトリへのアクセスができない場合、 CGI プログラムを実行することができる他の場所が必要になります。

任意のディレクトリで CGI の実行を許可するには二段階の設定が必要です。 まず、`AddHandler` や `SetHandler` ディレクティブによって `cgi-script` ハンドラが可能になっている必要があります。 次に、`Options` ディレクティブで `ExecCGI` が指定されていなければなりません。

### CGI の実行を可能にするために Options を明示的に使用する

サーバのメインの設定ファイル中で `Options` ディレクティブを明示的に使用することで、特定のディレクトリ配下で CGI の実行を許可するように指定することができます:

`<Directory /usr/local/apache2/htdocs/somedir>
Options +ExecCGI
</Directory>`

上記ディレクティブは、CGI ファイルの実行を可能にするよう Apache に伝えます。また、どのファイルが CGI ファイルかを サーバに伝える必要があります。次の `AddHandler` ディレクティブの例では、`cgi` または `pl` を拡張子に持つすべてのファイルを CGI プログラムとしてみなすことをサーバに伝えます:

`AddHandler cgi-script .cgi .pl`

### .htaccess ファイル

`.htaccess` チュートリアル は `httpd.conf` を変更できない場合にどうやって CGI プログラムを 使えるようにするかを説明しています。

### User ディレクトリ

`.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 プログラミングの間には主に二つの違いがあります。

一つは、CGI プログラムのすべての出力にはMIME タイプ ヘッダを付けなければなりません。 これはどのような種類のコンテンツを受け取っているかをクライアントに示す HTTP ヘッダです。ほとんどの場合では、次のように出力します:

`Content-type: text/html`

もう一つは、出力を HTML か、ブラウザが表示することができる何か他の形式にする必要があります。 大抵の場合は HTML でしょうが、GIF イメージや他の非 HTML コンテンツを出力する CGI プログラムを書くこともあるでしょう。

これら二点以外では、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 プログラムへのアクセスを行なったとき、 ブラウザで見る可能性がある四つの基本的なことがあります:

CGI プログラムの出力
  素晴らしい ! それはすべてがうまく動いたことを意味します。 出力が正常だけれども、ブラウザが正常に処理してくれない場合は、 正しい `Content-Type` を CGI プログラム内で セットしたかを確認してください。
CGI プログラムのソースコード、または "POST Method Not Allowed" というメッセージ
  これは、CGI プログラムを処理できるよう Apache を適切に設定していなかったことを意味します。「CGI を許可するように Apache を設定する」の章を読み直し、 あなたが何を間違えたかを探してみてください。
メッセージが "Forbidden" で始まっている
  これはパーミッションの問題ということを意味します。 Apache のエラーログと、後述の「ファイルのパーミッション」 の章をチェックしてください。
"Internal Server Error" というメッセージ
  Apache のエラーログをチェックすると、"Premature end of script headers" というログが記録されていると思います。そして、おそらく CGI プログラムによって生成されたエラーメッセージも記録されているでしょう。 この場合、CGI プログラムが適切な HTTP ヘッダを出力できない原因を知るために、 以下の各章でチェックしてみてください。

### ファイルのパーミッション

サーバはあなたの権限で実行されていないのを忘れないように。 つまり、起動するとき、サーバは特権をもたないユーザ - 通常 `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

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`) を通じて行なわれます。通常の文脈において、`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 モジュール/ライブラリ

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 バグデータベースに送るべきでない ことに注目してください。

翻訳済み言語: en | es | fr | ja | ko

## コメント

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.