From: Yoshiki Hayashi Date: Thu, 18 Jan 2001 08:54:02 +0000 (+0000) Subject: New Japanese translation by Minoru Yamazato X-Git-Tag: APACHE_2_0_BETA_CANDIDATE_1~188 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=5ba42f8b848bff6bc2a522036ae5ee4d41eb33ef;p=apache New Japanese translation by Minoru Yamazato git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87704 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/howto/cgi.html b/docs/manual/howto/cgi.html deleted file mode 100644 index fadbceb41c..0000000000 --- a/docs/manual/howto/cgi.html +++ /dev/null @@ -1,499 +0,0 @@ - - - -Apache Tutorial: Dynamic Content with CGI - - - - - -

Dynamic Content with CGI

- - - - - - - -
-

Dynamic Content with -CGI

- - -
-Related Modules

- -mod_alias
-mod_cgi
- -
-Related Directives

- -AddHandler
-Options
-ScriptAlias
- -
- -

The CGI (Common Gateway Interface) defines a way for a web server -to interact with external content-generating programs, which are often -referred to as CGI programs or CGI scripts. It is the simplest, and -most common, way to put dynamic content on your web site. This -document will be an introduction to setting up CGI on your Apache web -server, and getting started writing CGI programs.

- -
-

Configuring Apache to -permit CGI

- -

In order to get your CGI programs to work properly, you'll need to -have Apache configured to permit CGI execution. There are several ways -to do this.

- -

ScriptAlias

- -

The ScriptAlias directive tells Apache that a -particular directory is set aside for CGI programs. Apache will assume -that every file in this directory is a CGI program, and will attempt to -execute it, when that particular resource is requested by a client.

- -

The ScriptAlias directive looks like:

- -
-        ScriptAlias /cgi-bin/ /usr/local/apache/cgi-bin/
-
- -

The example shown is from your default httpd.conf -configuration file, if you installed Apache in the default location. -The ScriptAlias directive is much like the -Alias directive, which defines a URL prefix that is to -mapped to a particular directory. Alias and -ScriptAlias are usually used for directories that are -outside of the DocumentRoot directory. The difference -between Alias and ScriptAlias is that -ScriptAlias has the added meaning that everything under -that URL prefix will be considered a CGI program. So, the example above -tells Apache that any request for a resource beginning with -/cgi-bin/ should be served from the directory -/usr/local/apache/cgi-bin/, and should be treated as a CGI -program.

- -

For example, if the URL -http://dev.rcbowen.com/cgi-bin/test.pl is requested, -Apache will attempt to execute the file -/usr/local/apache/cgi-bin/test.pl and return the output. -Of course, the file will have to exist, and be executable, and return -output in a particular way, or Apache will return an error message.

- -

CGI outside of -ScriptAlias directories

- -

CGI programs are often restricted to ScriptAlias'ed -directories for security reasons. In this way, administrators can -tightly control who is allowed to use CGI programs. However, if the -proper security precautions are taken, there is no reason why -CGI programs cannot be run from arbitrary directories. For example, -you may wish to let users have web content in their home directories -with the UserDir directive. If they want to have their -own CGI programs, but don't have access to the main -cgi-bin directory, they will need to be able to run CGI -programs elsewhere.

- -

Explicitly using -Options to permit CGI execution

- -

You could explicitly use the Options directive, inside -your main server configuration file, to specify that CGI execution was -permitted in a particular directory:

- -
-        <Directory /usr/local/apache/htdocs/somedir>
-                Options +ExecCGI
-        </Directory>
-
- -

The above directive tells Apache to permit the execution of CGI -files. You will also need to tell the server what files are CGI files. -The following AddHandler directive tells the server -to treat all files with the cgi or pl -extension as CGI programs:

- -
-     AddHandler cgi-script cgi pl
-
- -

.htaccess files

- -

A .htaccess file is a way to set configuration -directives on a per-directory basis. When Apache serves a resource, it -looks in the directory from which it is serving a file for a file -called .htaccess, and, if it finds it, it will apply -directives found therein. .htaccess files can be permitted -with the AllowOverride directive, which specifies what -types of directives can appear in these files, or if they are not -allowed at all. To permit the directive we will need for this purpose, -the following configuration will be needed in your main server -configuration:

- -
-        AllowOverride Options
-
- -

In the .htaccess file, you'll need the following -directive:

- -
-        Options +ExecCGI
-
- -

which tells Apache that execution of CGI programs is permitted in -this directory.

- -
-

Writing a CGI program

- -

There are two main differences between ``regular'' programming, and -CGI programming.

- -

First, all output from your CGI program must be preceded by a -MIME-type header. This is HTTP header that tells the client what sort -of content it is receiving. Most of the time, this will look like:

- -
-        Content-type: text/html
-
- -

Secondly, your output needs to be in HTML, or some other format that -a browser will be able to display. Most of the time, this will be HTML, -but occasionally you might write a CGI program that outputs a gif -image, or other non-HTML content.

- -

Apart from those two things, writing a CGI program will look a lot -like any other program that you might write.

- -

Your first CGI program

- -

The following is an example CGI program that prints one line to your -browser. Type in the following, save it to a file called -first.pl, and put it in your cgi-bin -directory.

- -
-        #!/usr/bin/perl
-        print "Content-type: text/html\r\n\r\n";
-        print "Hello, World.";
-
- -

Even if you are not familiar with Perl, you should be able to see -what is happening here. The first line tells Apache (or whatever shell -you happen to be running under) that this program can be executed by -feeding the file to the interpreter found at the location -/usr/bin/perl. The second line prints the content-type -declaration we talked about, followed by two carriage-return newline -pairs. This puts a blank line after the header, to indicate the end of -the HTTP headers, and the beginning of the body. The third line prints -the string ``Hello, World.'' And that's the end of it.

- -

If you open your favorite browser and tell it to get the address

- -
-        http://www.example.com/cgi-bin/first.pl
-
- -

or wherever you put your file, you will see the one line -Hello, World. appear in your browser window. It's not very -exciting, but once you get that working, you'll have a good chance of -getting just about anything working.

- -
-

But it's still not -working!

- -

There are four basic things that you may see in your browser when -you try to access your CGI program from the web:

- -
-
The output of your CGI program
-
Great! That means everything worked fine.

- -
The source code of your CGI program or a "POST Method Not Allowed" -message
-
That means that you have not properly configured -Apache to process your CGI program. Reread the section on configuring Apache and try to -find what you missed.

- -
A message starting with "Forbidden"
That means that there -is a permissions problem. Check the Apache -error log and the section below on file permissions.

- -
A message saying "Internal Server Error"
If you check the -Apache error log, you will probably find -that it says "Premature end of script headers", possibly along with an -error message generated by your CGI program. In this case, you will -want to check each of the below sections to see what might be preventing -your CGI program from emitting the proper HTTP headers.
-
- - -

File permissions

- -

Remember that the server does not run as you. That is, when the -server starts up, it is running with the permissions of an unprivileged -user - usually ``nobody'', or ``www'' - and so it will need extra -permissions to execute files that are owned by you. Usually, the way to -give a file sufficient permissions to be executed by ``nobody'' is to -give everyone execute permission on the file:

- -
-        chmod a+x first.pl
-
- -

Also, if your program reads from, or writes to, any other files, -those files will need to have the correct permissions to permit -this.

- -

The exception to this is when the server is configured to use suexec. This program allows CGI programs to -be run under different user permissions, depending on which virtual -host or user home directory they are located in. Suexec has very -strict permission checking, and any failure in that checking will -result in your CGI programs failing with an "Internal Server Error". -In this case, you will need to check the suexec log file to see what -specific security check is failing.

- -

Path information

- -

When you run a program from your command line, you have certain -information that is passed to the shell without you thinking about it. -For example, you have a path, which tells the shell where it can look -for files that you reference.

- -

When a program runs through the web server as a CGI program, it does -not have that path. Any programs that you invoke in your CGI program -(like 'sendmail', for example) will need to be specified by a full -path, so that the shell can find them when it attempts to execute your -CGI program.

- -

A common manifestation of this is the path to the script interpreter -(often perl) indicated in the first line of your CGI -program, which will look something like:

- -
-     #!/usr/bin/perl
-
- -

Make sure that this is in fact the path to the interpreter.

- -

Syntax errors

- -

Most of the time when a CGI program fails, it's because of a problem -with the program itself. This is particularly true once you get the -hang of this CGI stuff, and no longer make the above two mistakes. -Always attempt to run your program from the command line before you -test if via a browser. This will eliminate most of your problems.

- -

Error logs

- -

The error logs are your friend. Anything that goes wrong generates -message in the error log. You should always look there first. If the -place where you are hosting your web site does not permit you access to -the error log, you should probably host your site somewhere else. Learn -to read the error logs, and you'll find that almost all of your -problems are quickly identified, and quickly solved.

- -
-

What's going on behind -the scenes?

- -

As you become more advanced in CGI programming, it will become -useful to understand more about what's happening behind the scenes. -Specifically, how the browser and server communicate with one another. -Because although it's all very well to write a program that prints -``Hello, World.'', it's not particularly useful.

- -

Environment variables

- -

Environment variables are values that float around you as you use -your computer. They are useful things like your path (where the -computer searches for a the actual file implementing a command when you -type it), your username, your terminal type, and so on. For a full list -of your normal, every day environment variables, type env -at a command prompt.

- -

During the CGI transaction, the server and the browser also set -environment variables, so that they can communicate with one another. -These are things like the browser type (Netscape, IE, Lynx), the server -type (Apache, IIS, WebSite), the name of the CGI program that is being -run, and so on.

- -

These variables are available to the CGI programmer, and are half of -the story of the client-server communication. The complete list of -required variables is at http://hoohoo.ncsa.uiuc.edu/cgi/env.html

- -

This simple Perl CGI program will display all of the environment -variables that are being passed around. Two similar programs are -included in the cgi-bin directory of the Apache -distribution. Note that some variables are required, while others are -optional, so you may see some variables listed that were not in the -official list. In addition, Apache provides many different ways for -you to add your own environment variables to -the basic ones provided by default.

- -
-     #!/usr/bin/perl
-     print "Content-type: text/html\n\n";
-     foreach $key (keys %ENV) {
-          print "$key --> $ENV{$key}<br>";
-     }
-
- -

STDIN and STDOUT

- -

Other communication between the server and the client happens over -standard input (STDIN) and standard output -(STDOUT). In normal everyday context, STDIN -means the keyboard, or a file that a program is given to act on, and -STDOUT usually means the console or screen.

- -

When you POST a web form to a CGI program, the data in -that form is bundled up into a special format and gets delivered to -your CGI program over STDIN. The program then can process -that data as though it was coming in from the keyboard, or from a -file

- -

The ``special format'' is very simple. A field name and its value -are joined together with an equals (=) sign, and pairs of values are -joined together with an ampersand (&). Inconvenient characters like -spaces, ampersands, and equals signs, are converted into their hex -equivalent so that they don't gum up the works. The whole data string -might look something like:

- -
-     name=Rich%20Bowen&city=Lexington&state=KY&sidekick=Squirrel%20Monkey
-
- -

You'll sometimes also see this type of string appended to the a URL. -When that is done, the server puts that string into the environment -variable called QUERY_STRING. That's called a -GET request. Your HTML form specifies whether a -GET or a POST is used to deliver the data, by -setting the METHOD attribute in the FORM -tag.

- -

Your program is then responsible for splitting that string up into -useful information. Fortunately, there are libraries and modules -available to help you process this data, as well as handle other of the -aspects of your CGI program.

- -
-

CGI modules/libraries

- -

When you write CGI programs, you should consider using a code -library, or module, to do most of the grunt work for you. This leads to -fewer errors, and faster development.

- -

If you're writing CGI programs in Perl, modules are available on CPAN. The most popular module for this -purpose is CGI.pm. You might also consider CGI::Lite, which implements -a minimal set of functionality, which is all you need in most -programs.

- -

If you're writing CGI programs in C, there are a variety of options. -One of these is the CGIC library, from http://www.boutell.com/cgic/

- -
-

For more information

- -

There are a large number of CGI resources on the web. You can -discuss CGI problems with other users on the Usenet group -comp.infosystems.www.authoring.cgi. And the -servers mailing list from -the HTML Writers Guild is a great source of answers to your questions. -You can find out more at http://www.hwg.org/lists/hwg-servers/

- -

And, of course, you should probably read the CGI specification, -which has all the details on the operation of CGI programs. You can -find the original version at the NCSA and there is -an updated draft at the Common Gateway Interface RFC -project.

- -

When you post a question about a CGI problem that you're having, -whether to a mailing list, or to a newsgroup, make sure you provide -enough information about what happened, what you expected to happen, -and how what actually happened was different, what server you're -running, what language your CGI program was in, and, if possible, the -offending code. This will make finding your problem much simpler.

- -

Note that questions about CGI problems should never -be posted to the Apache bug database unless you are sure you have found -a problem in the Apache source code.

- - - - - - diff --git a/docs/manual/howto/cgi.html.ja.jis b/docs/manual/howto/cgi.html.ja.jis new file mode 100644 index 0000000000..b6bf58c219 --- /dev/null +++ b/docs/manual/howto/cgi.html.ja.jis @@ -0,0 +1,495 @@ + + + +Apache Tutorial: CGI による動的コンテンツ + + + + + +

CGI による動的コンテンツ

+ + + + + + + +
+

CGI による動的コンテンツ

+ + +
+関連モジュール

+ +mod_alias
+mod_cgi
+ +
+関連ディレクティブ

+ +AddHandler
+Options
+ScriptAlias
+ +
+ +

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

+ +
+

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

+ +

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

+ +

ScriptAlias

+ +

ScriptAlias ディレクティブを使用して、CGI プログラム用の +特別な別ディレクトリを Apache に設定します。 +Apache は、このディレクトリ中の全てのファイルを CGI プログラムであると +仮定します。そして、この特別なリソースがクライアントから要求されると、 +そのプログラムの実行を試みます。

+ +

ScriptAlias ディレクティブは以下のように使用します:

+ +
+        ScriptAlias /cgi-bin/ /usr/local/apache/cgi-bin/
+
+ +

デフォルト位置に Apache をインストールしたならば、 +この例はデフォルト状態の httpd.conf 設定ファイル +に含まれています。 +ScriptAlias ディレクティブは、URL の前に付加するディレクトリを定義する Alias ディレクティブとかなり似ています。 +AliasScriptAlias は通常、 +DocumentRoot ディレクトリ外のディレクトリのために使用されます。 +AliasScriptAlias との差は、 +ScriptAlias が接頭辞で始まるすべての URL は CGI プログラムと +みなされるという追加の意味を含んでいることです。従って、 +上記の例では、/cgi-bin/ +で始まるリソースへのあらゆるリクエストに対して、ディレクトリ +/usr/local/apache/cgi-bin/ +から提供し、それらを CGI プログラムとして扱うよう Apache に示します。

+ +

例えば、URL http://dev.rcbowen.com/cgi-bin/test.pl +が要求された場合、Apache は ファイル +/usr/local/apache/cgi-bin/test.pl を実行し、その出力を返すことを +試みます。 +もちろん、ファイルが存在し、実行可能であり、決められた方法で出力を返します。 +そうでなければ、Apache はエラーメッセージを返します。 + +

+ScriptAlias ディレクトリ外の CGI

+ +

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

+ +

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

+ +

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

+ +

+        <Directory /usr/local/apache/htdocs/somedir>
+                Options +ExecCGI
+        </Directory>
+
+ +

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

+ +

+     AddHandler cgi-script cgi pl
+
+ +

.htaccess ファイル

+ +

.htaccess ファイルは、ディレクトリ毎に +ディレクティブを指定する方法です。 +Apache は、リソースを提供するときに、提供するファイルが置かれている +ディレクトリ中の .htaccess というファイルを参照します。 +そのファイルを発見したら、その中で発見されたディレクティブが適用されます。 +.htaccess ファイルは、AllowOverride +ディレクティブの指定により使えるようになります。 +AllowOverride ディレクティブは、.htaccess ファイルで +設定できるディレクティブのタイプを指定します。 +AllowOverride ディレクティブの指定がない場合、まったく使えません。 +CGI の実行を許可するために必要となるディレクティブを指定可能にするには、 +以下の設定がサーバのメインの設定で必要になります:

+ +
+        AllowOverride Options
+
+ +

.htaccess ファイルでは、次のディレクティブが必要と +なります:

+ +
+        Options +ExecCGI
+
+ +

この設定では、このディレクトリにおける CGI プログラムの実行を許可するよう +Apache に伝えます。

+ +
+

CGI プログラムを書く

+ +

通常のプログラミングと CGI プログラミングの間には主に二つの違いが +あります。

+ +

一つは、CGI プログラムのすべての出力には MIME-type +ヘッダを付けなければなりません。これはどのような種類のコンテンツを受け取って +いるかをクライアントに示す 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\r\n\r\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 プログラムの出力
+
素晴らしい ! それはすべてがうまく動いたことを意味します。

+ +
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
+
+ +

また、もしあなたのプログラムが他のファイルを読み書きするならば、 +それらのファイルは、これが可能となる正しいパーミッションを持っている必要が +あります。

+ +

これに対する例外は、サーバが suexec を +使用するよう設定されている場合です。 +suexec は、CGI プログラムが置かれているバーチャルホストまたはユーザのホーム +ディレクトリによって、異なるユーザ権限で +実行されるようにします。 +suexec はとても厳しいパーミッションのチェックがあり、 +そのチェックを通過できないと "Internal Server Error" となり、 +その CGI プログラムの実行は失敗します。 +この場合、どのセキュリティチェックが失敗しているのかを知る +ために suexec ログファイルをチェックする必要があります。

+ +

パス情報

+ +

コマンドラインからプログラムを実行するとき、意識しなくても +シェルに渡される情報があります。 +例えば、参照するファイルのためにどこを検索したらよいかをシェルに伝えるパスが +あります。

+ +

プログラムが CGI プログラムとしてウェブサーバによって実行されるとき、 +それはパスを持ちません。 +CGI プログラム内で呼び出すあらゆるプログラム (例えば、'sendmail' の +ようなもの) は、フルパスで指定する必要があるでしょう。 +それにより、CGI プログラムを実行しようとしたとき、シェルはそのようなプログラムを +見つけることができます。

+ +

同様なことは、スクリプトのインタプリタ (しばしば perl ) +へのパスで、CGI プログラムの 1 行目に次のように示されます:

+ +
+     #!/usr/bin/perl
+
+ +

これがインタープリタへの実際のパスであることを確実にしておきます。

+ +

構文エラー

+ +

CGI プログラムが失敗するのは大抵、プログラム自身に問題がある場合です。 +一度 CGI の使い方を理解し、前述の二つの誤りを犯していないならば、 +まず間違いなくそうでしょう。ブラウザを通してテストを行う前に必ず、コマンドライン +からプログラムの実行を試しなさい。これにより、大抵の問題が起こらなくなります。

+ +

エラーログ

+ +

エラーログは友達です。全てのうまくいかないことは、エラーログに +メッセージを生成します。必ずそれを最初に見るべきです。 +もし、あなたがウェブサイトを主催している場所がエラーログの参照を +許していないならば、きっと他のサイトで主催するべきです。 +エラーログの読み方を学ぶことで、ほとんど全ての問題が迅速に +確認され、迅速に解決されるということが分かるでしょう。

+ +
+

裏で何が起こっているのか?

+ +

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 フォームでは、データを渡すために GETPOST +のどちらを使用するかを、 +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 バグデータベースに送るべきでない +ことに注目してください。

+ + + + + +