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

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

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

はじめに
CGI を許可するように Apache を設定する
CGI プログラムを書く
しかし、まだ動かない !
裏で何が起こっているのか?
CGI モジュール/ライブラリ
更なる情報

参照

はじめに

関連モジュール	関連ディレクティブ
`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 + バグデータベースに送るべきでない + ことに注目してください。