|
-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.
- -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.
- -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 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.
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 -- -
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.
- -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.
- -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.
There are four basic things that you may see in your browser when -you try to access your CGI program from the web:
- -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.
- -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.
- -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.
- -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.
- -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 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>";
- }
-
-
-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.
- -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/
- -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 deleted file mode 100644 index b6bf58c219..0000000000 --- a/docs/manual/howto/cgi.html.ja.jis +++ /dev/null @@ -1,495 +0,0 @@ - - - -|
-関連モジュール - -mod_alias -mod_cgi - - |
-関連ディレクティブ - -AddHandler -Options -ScriptAlias - - |
CGI (Common Gateway Interface) は、ウェブサーバがコンテンツ生成をする -外部プログラムと協調して動作するための方法を定義しています。そのプログラムはしばしば -CGI プログラムや CGI スクリプトと呼ばれます。CGI は、ウェブサイトに -動的なコンテンツを置くための最も簡単で一般的な方法です。このドキュメントは、 -Apache ウェブサーバで CGI を設定し、CGI プログラムを書き始めるための -入門書となるでしょう。
- -CGI プログラムを正しく動作させるには、CGI を許可するように -Apache の設定を行う必要があります。これを行なうための方法がいくつか -あります。
- -ScriptAlias ディレクティブを使用して、CGI プログラム用の
-特別な別ディレクトリを Apache に設定します。
-Apache は、このディレクトリ中の全てのファイルを CGI プログラムであると
-仮定します。そして、この特別なリソースがクライアントから要求されると、
-そのプログラムの実行を試みます。
ScriptAlias ディレクティブは以下のように使用します:
- ScriptAlias /cgi-bin/ /usr/local/apache/cgi-bin/ -- -
デフォルト位置に Apache をインストールしたならば、
-この例はデフォルト状態の httpd.conf 設定ファイル
-に含まれています。
-ScriptAlias ディレクティブは、URL の前に付加するディレクトリを定義する Alias ディレクティブとかなり似ています。
-Alias と ScriptAlias は通常、
-DocumentRoot ディレクトリ外のディレクトリのために使用されます。
-Alias と ScriptAlias との差は、
-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 はエラーメッセージを返します。
-
-
CGI プログラムは、セキュリティ上の理由から
-ScriptAlias されたディレクトリに制限されることがしばしばあります。
-この方法により、CGI プログラムを使用できるユーザを管理者が厳しく制御する
-ことができます。
-しかしながら、適切なセキュリティ事前対策がとられるならば、CGI プログラム
-を任意のディレクトリで実行できないようにする理由はありません。
-例えば、ユーザに UserDir ディレクティブで
-彼らのホームディレクトリ配下にウェブコンテンツを持たせたいとします。
-もし、彼らが CGI プログラムを持つことを望んでいても、メインの
-cgi-bin ディレクトリへのアクセスができない場合、CGI プログラムを
-実行することができる他の場所が必要になります。
サーバのメインの設定ファイル中で Options ディレクティブを
-明示的に使用することで、特定のディレクトリ配下で CGI の実行を許可するように
-指定することができます:
- -
- <Directory /usr/local/apache/htdocs/somedir> - Options +ExecCGI - </Directory> -- -
上記ディレクティブは、CGI ファイルの実行を可能にするよう Apache
-に伝えます。また、どのファイルが CGI ファイルかを
-サーバに伝える必要があります。次の AddHandler
-ディレクティブの例では、cgi または pl を拡張子に
-持つすべてのファイルを CGI プログラムとしてみなすことをサーバに伝えます:
- -
- AddHandler cgi-script cgi pl -- -
.htaccess ファイルは、ディレクトリ毎に
-ディレクティブを指定する方法です。
-Apache は、リソースを提供するときに、提供するファイルが置かれている
-ディレクトリ中の .htaccess というファイルを参照します。
-そのファイルを発見したら、その中で発見されたディレクティブが適用されます。
-.htaccess ファイルは、AllowOverride
-ディレクティブの指定により使えるようになります。
-AllowOverride ディレクティブは、.htaccess ファイルで
-設定できるディレクティブのタイプを指定します。
-AllowOverride ディレクティブの指定がない場合、まったく使えません。
-CGI の実行を許可するために必要となるディレクティブを指定可能にするには、
-以下の設定がサーバのメインの設定で必要になります:
- AllowOverride Options -- -
.htaccess ファイルでは、次のディレクティブが必要と
-なります:
- Options +ExecCGI -- -
この設定では、このディレクトリにおける CGI プログラムの実行を許可するよう -Apache に伝えます。
- -通常のプログラミングと CGI プログラミングの間には主に二つの違いが -あります。
- -一つは、CGI プログラムのすべての出力には MIME-type -ヘッダを付けなければなりません。これはどのような種類のコンテンツを受け取って -いるかをクライアントに示す 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\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 プログラムへのアクセスを行なったとき、 -ブラウザで見る可能性がある四つの基本的なことがあります:
- -サーバはあなたの権限で実行されていないのを忘れないように。 -つまり、起動するとき、サーバは特権をもたないユーザ - 通常 ``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 は通常コンソールまたはスクリーンを
-意味します。
ウェブフォームから 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 バグデータベースに送るべきでない -ことに注目してください。
- - - - - - diff --git a/docs/manual/howto/footer.html b/docs/manual/howto/footer.html deleted file mode 100644 index 4a0991e6fa..0000000000 --- a/docs/manual/howto/footer.html +++ /dev/null @@ -1,8 +0,0 @@ -
-
diff --git a/docs/manual/howto/header.html b/docs/manual/howto/header.html
deleted file mode 100644
index 9bc11593a3..0000000000
--- a/docs/manual/howto/header.html
+++ /dev/null
@@ -1,6 +0,0 @@
-![[APACHE DOCUMENTATION]](../images/sub.gif)
- | Related Modules - - mod_include -mod_cgi -mod_expires - |
-Related Directives - - Options -XBitHack -AddType -AddHandler -BrowserMatchNoCase - - |
-
This HOWTO first appeared in Apache Today -(http://www.apachetoday.com/) as a series of three articles. They -appear here by arrangement with ApacheToday and Internet.com.
- -This article deals with Server Side Includes, usually called simply -SSI. In this article, I'll talk about configuring your server to permit -SSI, and introduce some basic SSI techniques for adding dynamic content -to your existing HTML pages.
- -In the latter part of the article, we'll talk about some of the -somewhat more advanced things that can be done with SSI, such as -conditional statements in your SSI directives.
- -SSI (Server Side Includes) are directives that are placed in HTML -pages, and evaluated on the server while the pages are being served. -They let you add dynamically generated content to an existing HTML -page, without having to serve the entire page via a CGI program, or -other dynamic technology.
- -The decision of when to use SSI, and when to have your page entirely -generated by some program, is usually a matter of how much of the page -is static, and how much needs to be recalculated every time the page is -served. SSI is a great way to add small pieces of information, such as -the current time. But if a majority of your page is being generated at -the time that it is served, you need to look for some other -solution.
- -To permit SSI on your server, you must have the following directive
-either in your httpd.conf file, or in a
-.htaccess file:
- Options +Includes -- -
This tells Apache that you want to permit files to be parsed for SSI -directives.
- -Not just any file is parsed for SSI directives. You have to tell
-Apache which files should be parsed. There are two ways to do this. You
-can tell Apache to parse any file with a particular file extension,
-such as .shtml, with the following directives:
- AddType text/html .shtml - <FilesMatch "\.shtml[.$]"> - SetOutputFilter INCLUDES- -
- </FilesMatch> -
One disadvantage to this approach is that if you wanted to add SSI
-directives to an existing page, you would have to change the name of
-that page, and all links to that page, in order to give it a
-.shtml extension, so that those directives would be
-executed.
The other method is to use the XBitHack directive:
- XBitHack on -- -
XBitHack tells Apache to parse files for SSI directives
-if they have the execute bit set. So, to add SSI directives to an
-existing page, rather than having to change the file name, you would
-just need to make the file executable using chmod.
- chmod +x pagename.html -- -
A brief comment about what not to do. You'll occasionally see people
-recommending that you just tell Apache to parse all .html
-files for SSI, so that you don't have to mess with .shtml
-file names. These folks have perhaps not heard about
-XBitHack. The thing to keep in mind is that, by doing
-this, you're requiring that Apache read through every single file that
-it sends out to clients, even if they don't contain any SSI directives.
-This can slow things down quite a bit, and is not a good idea.
Of course, on Windows, there is no such thing as an execute bit to -set, so that limits your options a little.
- -In its default configuration, Apache does not send the last modified -date or content length HTTP headers on SSI pages, because these values are -difficult to calculate for dynamic content. This can prevent your -document from being cached, and result in slower perceived client -performance. There are two ways to solve this:
- -XBitHack Full configuration. This tells
-Apache to determine the last modified date by looking only at the date
-of the originally requested file, ignoring the modification date of
-any included files. SSI directives have the following syntax:
- -- <!--#element attribute=value attribute=value ... --> -- -
It is formatted like an HTML comment, so if you don't have SSI -correctly enabled, the browser will ignore it, but it will still be -visible in the HTML source. If you have SSI correctly configured, the -directive will be replaced with its results.
- -The element can be one of a number of things, and we'll talk some -more about most of these in the next installment of this series. For -now, here are some examples of what you can do with SSI
- -- <!--#echo var="DATE_LOCAL" --> -- -
The echo element just spits out the value of a
-variable. There are a number of standard variables, which include the
-whole set of environment variables that are available to CGI programs.
-Also, you can define your own variables with the set
-element.
If you don't like the format in which the date gets printed, you can
-use the config element, with a timefmt
-attribute, to modify that formatting.
- <!--#config timefmt="%A %B %d, %Y" --> - Today is <!--#echo var="DATE_LOCAL" --> -- -
- This document last modified <!--#flastmod file="index.html" --> -- -
This element is also subject to timefmt format
-configurations.
This is one of the more common uses of SSI - to output the results -of a CGI program, such as everybody's favorite, a ``hit counter.''
- -- <!--#include virtual="/cgi-bin/counter.pl" --> -- -
Following are some specific examples of things you can do in your -HTML documents with SSI.
- -Earlier, we mentioned that you could use SSI to inform the user when -the document was most recently modified. However, the actual method for -doing that was left somewhat in question. The following code, placed in -your HTML document, will put such a time stamp on your page. Of course, -you will have to have SSI correctly enabled, as discussed above.
- -- <!--#config timefmt="%A %B %d, %Y" --> - This file last modified <!--#flastmod file="ssi.shtml" --> -- -
Of course, you will need to replace the ssi.shtml with
-the actual name of the file that you're referring to. This can be
-inconvenient if you're just looking for a generic piece of code that
-you can paste into any file, so you probably want to use the
-LAST_MODIFIED variable instead:
- <!--#config timefmt="%D" --> - This file last modified <!--#echo var="LAST_MODIFIED" --> -- -
For more details on the timefmt format, go to your
-favorite search site and look for ctime. The syntax is the
-same.
If you are managing any site that is more than a few pages, you may -find that making changes to all those pages can be a real pain, -particularly if you are trying to maintain some kind of standard look -across all those pages.
- -Using an include file for a header and/or a footer can reduce the
-burden of these updates. You just have to make one footer file, and
-then include it into each page with the include SSI
-command. The include element can determine what file to
-include with either the file attribute, or the
-virtual attribute. The file attribute is a
-file path, relative to the current directory. That means that
-it cannot be an absolute file path (starting with /), nor can it
-contain ../ as part of that path. The virtual attribute is
-probably more useful, and should specify a URL relative to the document
-being served. It can start with a /, but must be on the same server as
-the file being served.
- <!--#include virtual="/footer.html" --> -- -
I'll frequently combine the last two things, putting a
-LAST_MODIFIED directive inside a footer file to be
-included. SSI directives can be contained in the included file, and
-includes can be nested - that is, the included file can include another
-file, and so on.
In addition to being able to config the time format,
-you can also config two other things.
Usually, when something goes wrong with your SSI directive, you get -the message
- -- [an error occurred while processing this directive] -- -
If you want to change that message to something else, you can do so
-with the errmsg attribute to the config
-element:
- <!--#config errmsg="[It appears that you don't know how to use SSI]" --> -- -
Hopefully, end users will never see this message, because you will -have resolved all the problems with your SSI directives before your -site goes live. (Right?)
- -And you can config the format in which file sizes are
-returned with the sizefmt attribute. You can specify
-bytes for a full count in bytes, or abbrev
-for an abbreviated number in Kb or Mb, as appropriate.
I expect that I'll have an article some time in the coming months
-about using SSI with small CGI programs. For now, here's something else
-that you can do with the exec element. You can actually
-have SSI execute a command using the shell (/bin/sh, to be
-precise - or the DOS shell, if you're on Win32). The following, for
-example, will give you a directory listing.
- <pre> - <!--#exec cmd="ls" --> - </pre> -- -
or, on Windows
- -- <pre> - <!--#exec cmd="dir" --> - </pre> -- -
You might notice some strange formatting with this directive on
-Windows, because the output from dir contains the string
-``<dir>'' in it, which confuses browsers.
Note that this feature is exceedingly dangerous, as it will execute
-whatever code happens to be embedded in the exec tag. If
-you have any situation where users can edit content on your web pages,
-such as with a ``guestbook'', for example, make sure that you have this
-feature disabled. You can allow SSI, but not the exec
-feature, with the IncludesNOEXEC argument to the
-Options directive.
In addition to spitting out content, Apache SSI gives you the option -of setting variables, and using those variables in comparisons and -conditionals.
- -Most of the features discussed in this article are only available to -you if you are running Apache 1.2 or later. Of course, if you are not -running Apache 1.2 or later, you need to upgrade immediately, if not -sooner. Go on. Do it now. We'll wait.
- -Using the set directive, you can set variables for
-later use. We'll need this later in the discussion, so we'll talk about
-it here. The syntax of this is as follows:
- <!--#set var="name" value="Rich" --> -- -
In addition to merely setting values literally like that, you can
-use any other variable, including, for example, environment variables,
-or some of the variables we discussed in the last article (like
-LAST_MODIFIED, for example) to give values to your
-variables. You will specify that something is a variable, rather than a
-literal string, by using the dollar sign ($) before the name of the
-variable.
- <!--#set var="modified" value="$LAST_MODIFIED" --> -- -
To put a literal dollar sign into the value of your variable, you -need to escape the dollar sign with a backslash.
- -- <!--#set var="cost" value="\$100" --> -- -
Finally, if you want to put a variable in the midst of a longer -string, and there's a chance that the name of the variable will run up -against some other characters, and thus be confused with those -characters, you can place the name of the variable in braces, to remove -this confusion. (It's hard to come up with a really good example of -this, but hopefully you'll get the point.)
- -
- <!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" -->
-
-
-Now that we have variables, and are able to set and compare their
-values, we can use them to express conditionals. This lets SSI be a
-tiny programming language of sorts. mod_include provides
-an if, elif, else,
-endif structure for building conditional statements. This
-allows you to effectively generate multiple logical pages out of one
-actual page.
The structure of this conditional construct is:
- -- <!--#if expr="test_condition" --> - <!--#elif expr="test_condition" --> - <!--#else --> - <!--#endif --> -- -
A test_condition can be any sort of logical comparison -
-either comparing values to one another, or testing the ``truth'' of a
-particular value. (A given string is true if it is nonempty.) For a
-full list of the comparison operators available to you, see the
-mod_include documentation. Here are some examples of how
-one might use this construct.
In your configuration file, you could put the following line:
- -- BrowserMatchNoCase macintosh Mac - BrowserMatchNoCase MSIE InternetExplorer -- -
This will set environment variables ``Mac'' and ``InternetExplorer'' -to true, if the client is running Internet Explorer on a Macintosh.
- -Then, in your SSI-enabled document, you might do the following:
- -
- <!--#if expr="${Mac} && ${InternetExplorer}" -->
- Apologetic text goes here
- <!--#else -->
- Cool JavaScript code goes here
- <!--#endif -->
-
-
-Not that I have anything against IE on Macs - I just struggled for a -few hours last week trying to get some JavaScript working on IE on a -Mac, when it was working everywhere else. The above was the interim -workaround.
- -Any other variable (either ones that you define, or normal
-environment variables) can be used in conditional statements. With
-Apache's ability to set environment variables with the
-SetEnvIf directives, and other related directives, this
-functionality can let you do some pretty involved dynamic stuff without
-ever resorting to CGI.
SSI is certainly not a replacement for CGI, or other technologies -used for generating dynamic web pages. But it is a great way to add -small amounts of dynamic content to pages, without doing a lot of extra -work.
- - - diff --git a/docs/manual/howto/ssi.html.ja.jis b/docs/manual/howto/ssi.html.ja.jis deleted file mode 100644 index eafa3150b7..0000000000 --- a/docs/manual/howto/ssi.html.ja.jis +++ /dev/null @@ -1,501 +0,0 @@ - - - -| 関連モジュール - - mod_include -mod_cgi -mod_expires - |
-関連ディレクティブ - - Options -XBitHack -AddType -AddHandler -BrowserMatchNoCase - - |
-
この文書は最初、Apache Today (http://www.apachetoday.com/) に三回の連載記事として掲載されました。 -ここでは、ApcheToday と Internet.com との協定により載せています。
- -この記事は、通常は単に SSI と呼ばれる Server Side Includes を -扱います。この記事においては、サーバでの SSI を許可するための設定と、 -現在の HTML ページに動的なコンテンツを加えるためのいくつかの基本的な -SSI 技術を紹介します。
- -記事の後半では、SSI ディレクティブで -SSI と共に実行することができる条件文のような幾分高度な事柄に -ついて述べています。
- -SSI (Server Side Includes) は、HTML ページ中に配置されるディレクティブであり、 -サーバでページを提供する時に評価されます。 -SSI は、CGI プログラムやその他の動的な技術で全てのページを提供 -せずに、動的に生成されたコンテンツを現在の HTML ページに -加えます。
- -どういう場合に SSI を使い、どういう場合にプログラムでページを完全に生成するか -は、ページのうちどの程度が静的であり、ページが提供されるたびに -再計算する必要がどの程度あるかで通常は決定します。SSI は現在時刻のような -小さい情報を加えるにはうってつけの方法です。 -しかし、そのページのほとんどの部分が提供時に生成される場合は、 -他の方法を探す必要があります。
- -サーバで SSI 許可するには、httpd.conf ファイル
-または .htaccess ファイルに次のディレクティブを指定する必要があります:
- Options +Includes -- -
この指定は、ファイルを SSI ディレクティブで解析させることを許可する -ということを Apache に伝えます。
- -全てのファイルが SSI ディレクティブで解析されるというわけではありません。
-どのファイルが解析されるかを Apache に伝える必要があります。これを
-行なうには二つ方法があります。次のディレクティブを使うことで、
-例えば .shtml のような特別なファイル拡張子を持つファイルを
-解析するよう Apache に伝えることができます:
- AddType text/html .shtml - AddHandler server-parsed .shtml -- -
この方法の欠点は、もし現在のページに SSI
-ディレクティブを加えたい場合、それらのディレクティブが実行される
-ように .shtml 拡張子にするため、そのページの名前と、
-そのページへの全てのリンクを変更しなければならないことです。
もう一つの方法は、XBitHack ディレクティブを使用することです:
- XBitHack on -- -
XBitHack は、ファイルの実行ビットが立っている場合、
-SSI ディレクティブにより解析することを Apache に伝えます。従って、
-SSI ディレクティブを現在のページに加えるためには、ファイル名を変更しなくてもよく、
-単に chmod を使用してファイルを実行可能にする
-だけで済みます。
- chmod +x pagename.html -- -
行なうべきではないことに関する短いコメント。時々誰かが、
-全ての .html ファイルを SSI で解析するよう Apache に伝えれば、
-わざわざ .shtml というファイル名にする必要がないといって
-薦めるのを見ることでしょう。こういう人たちは、おそらく XBitHack
-について聞いたことがないのでしょう。この方法について注意することは、
-たとえ SSI ディレクティブを全く含まない場合でも、Apache がクライアントに
-送る全てのファイルを最後まで読み込ませることになります。
-この方法はかなり処理を遅くするものであり、良くないアイデアです。
もちろん、Windows ではそのような実行ビットをセットするようなものは -ありませんのでオプションが少し制限されています。
- -デフォルトの設定では、Apache は SSI ページについて最終変更時刻や -コンテンツの長さを HTTP ヘッダに送りません。 -動的なコンテンツであるため、それらの値を計算するのが難しいからです。 -このためドキュメントが -キャッシュされなくなり、結果としてクライアントの性能が -遅くなったように感じさせることになります。 -これを解決する方法が二つあります:
- -XBitHack Full 設定を使用する。この設定により、もともと要求された
-ファイルの時刻を参照し、読み込まれるファイルの変更時刻を
-無視して最終変更時刻を決定するよう Apache に伝えます。SSI ディレクティブは以下の文法で記述します:
- -- <!--#element attribute=value attribute=value ... --> -- -
HTML のコメントのような書式をしているので、もし SSI を -正しく動作可能にしなければ、ブラウザはそれを無視するでしょう。しかし、 -HTML ソース中では見えます。もし SSI を正しく設定したなら、 -ディレクティブはその結果と置き換えられます。
- -element はたくさんあるものから一つ指定することができます。 -指定できるものの大多数については、次回もう少し詳しく説明します。 -ここでは、SSI で行なうことができる例をいくつか示します。
- -- <!--#echo var="DATE_LOCAL" --> -- -
echo 要素は単に変数の値を出力します。CGI プログラムに
-利用可能な環境変数の全てのセットを含む多くの標準変数があります。
-また、set 要素を用いることで、独自の変数を定義することが
-できます。
出力される日付の書式が好きではない場合、その書式を
-修正するために、config 要素に timefmt 属性を
-使用することができます。
- <!--#config timefmt="%A %B %d, %Y" --> - Today is <!--#echo var="DATE_LOCAL" --> -- -
- This document last modified <!--#flastmod file="index.html" --> -- -
この要素も timefmt フォーマットの設定に従います。
これは、全ての人のお気に入りである ``ヒットカウンタ'' のような CGI プログラムの -結果を出力する SSI のより一般的な使用のうちの一つです。
- -- <!--#include virtual="/cgi-bin/counter.pl" --> -- -
以下は、SSI を使用して HTML ドキュメントにおいてできることの -いくつかの特別な例です。
- -先に、ドキュメントが最後に変更されたのはいつかをユーザに通知するために SSI を使用することができることを -述べました。しかしながら、実際の方法は、いくぶん問題のままにしておきました。 -HTML ドキュメントに配置された次のコードは、ページに -そのようなタイムスタンプを入れるでしょう。もちろん、上述の -ように、SSI を正しく動作可能にしておく必要があります。
- -- <!--#config timefmt="%A %B %d, %Y" --> - This file last modified <!--#flastmod file="ssi.shtml" --> -- -
もちろん、ssi.shtml の部分を実際の当該ファイル名と
-置き換える必要があります。もし、あらゆるファイルに張ることが
-できる一般的なコードを探しているなら、これは不便であるかもしれません。
-おそらくその場合は、そうする代わりに変数 LAST_MODIFIED
-を使用したいと考えるでしょう:
- <!--#config timefmt="%D" --> - This file last modified <!--#echo var="LAST_MODIFIED" --> -- -
timefmt 書式についてのより詳細については、
-お好みの検索サイトに行き、ctime で検索してみてください。文法は同じです。
もし数ページを超えるページを持つサイトを管理しているならば、 -全ページに対して変項を行なうことが本当に苦痛となり得ることが分かるでしょう。 -全てのページに渡ってある種の標準的な外観を維持しようと -しているならば特にそうでしょう。
- -ヘッダやフッタ用の挿入用ファイルを使用することで、このような
-更新にかかる負担を減らすことができます。一つのフッタファイルを
-作成し、それを include SSI コマンドで各ページに
-入れるだけで済みます。include 要素は、file 属性
-または virtual 属性のいずれかを使用してどのファイルを挿入するかを
-決めることができます。file 属性は、カレントディレクトリからの
-相対パスで示されたファイルパスです。それは
-/ で始まる絶対ファイルパスにはできず、また、そのパスの一部に ../ を
-含むことができないことを意味します。virtual 属性は、おそらく
-より便利だと思いますが、提供するドキュメントからの相対 URL で指定すべきです。
-それは / で始めることができますが、提供するファイルと同じサーバ上に
-存在しなくてはなりません。
- <!--#include virtual="/footer.html" --> -- -
私は最後の二つを組み合わせて、LAST_MODIFIED ディレクティブを
-フッタファイルの中に置くことがよくあります。
-SSI ディレクティブは、挿入用のファイルに含ませたり、
-挿入ファイルのネストをしたりすることができます。すなわち、
-挿入用のファイルは他のファイルを再帰的に挿入することができます。
時刻書式を config で設定できることに加えて、
-更に二つ config で設定することができます。
通常、SSI ディレクティブで何かがうまくいかないときは、次のメッセージが -出力されます。
- -- [an error occurred while processing this directive] -- -
このメッセージを他のものにしたい場合、
-config 要素の errmsg 属性で変更することが
-できます:
- -
- <!--#config errmsg="[It appears that you don't know how to use SSI]" --> -- -
おそらく、エンドユーザはこのメッセージを決して見ることはありません。 -なぜなら、そのサイトが生きた状態になる前に SSI ディレクティブに関する -全ての問題を解決しているはずだからです。(そうですよね?)
- -そして、config において sizefmt 属性を使用することで、
-返されるファイルサイズの書式を設定することができます。
-バイト数には bytes を、適当に Kb や Mb に
-短縮させるには abbrev を指定することができます。
今後数ヶ月の内に、小さな CGI プログラムと SSI を使用する
-記事を出したいと考えています。ここではそれとは別に、
-exec 要素によって行なうことができることを示します。
-SSI にシェル (正確には /bin/sh。Win32 ならば DOS シェル)
-を使用してコマンドを実行させることができます。下記の例では、ディレクトリ
-リスト出力を行ないます。
- <pre> - <!--#exec cmd="ls" --> - </pre> -- -
Windows 上では、
- -- <pre> - <!--#exec cmd="dir" --> - </pre> -- -
Windows 上では、このディレクティブによっていくつかの奇妙な
-書式に気づくでしょう。なぜなら dir の出力が
-文字列 ``<dir>'' を含み、ブラウザを混乱させるからです。
この機能は非常に危険であり、どんなコードでも exec タグに
-埋め込まれてしまえば実行することに注意してください。例えば
-`` ゲストブック '' のように、もし、ユーザがページの内容を
-編集できる状況にあるならば、この機能を確実に抑制してください。
-Options ディレクティブの IncludesNOEXEC 引数を指定することで、
-SSI は許可するけれど exec 機能は許可しないようにすることができます。
コンテンツを出力することに加え、Apache SSI は変数を設定し、そして比較 -と条件分岐にその変数を使用できる機能を提供しています。
- -この記事で述べた大部分の機能は、Apache 1.2 以降を -使用している場合のみ利用可能です。もちろん、もし Apache 1.2 以降を -使用してない場合、直ちにアップグレードする必要があります。 -さぁ、今それを行ないなさい。それまで待っています。
- -set ディレクティブを使用して、後で使用するために変数を
-設定することができます。これは後の説明で必要になるので、ここで
-それについて述べています。文法は以下のとおりです:
- <!--#set var="name" value="Rich" --> -- -
このように単純に文字どおりに設定することに加え、
-例えば環境変数や前の記事で述べた変数 (例えば LAST_MODIFIED のような) を含む他のあらゆる変数を
-値を設定するのに使用することが
-できます。変数名の前にドル記号 ($) を使用することで、
-それがリテラル文字列ではなくて変数であることを示します。
- <!--#set var="modified" value="$LAST_MODIFIED" --> -- -
ドル記号 ($) を文字として変数の値に入れるには、バックスラッシュによって -ドル記号をエスケープする必要があります。
- -- <!--#set var="cost" value="\$100" --> -- -
最後になりますが、長い文字列の中に変数を置きたい場合で、 -変数名が他の文字とぶつかる可能性があり、それらの文字について -混乱してしまう場合、この混乱を取り除くため、変数名を中括弧で -囲むことができます (これについての良い例を示すのは難しいのですが、 -おそらく分かっていただけるでしょう)。
- -
- <!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" -->
-
-
-さて、変数を持っていて、それらの値を設定して比較することができるのですから、
-条件を表すためにそれらを使用することができます。これにより SSI は
-ある種の小さなプログラミング言語になっています。mod_include は
-条件を表現するために if, elif, else,
-endif 構造を提供しています。これによって、一つの実際のページから
-複数の論理ページを効果的に生成することができます。
条件構造は以下のとおりです:
- -- <!--#if expr="test_condition" --> - <!--#elif expr="test_condition" --> - <!--#else --> - <!--#endif --> -- -
test_condition はあらゆる種類の論理的比較をすることができます。
-値を比較したり、その値が ``真'' かどうかを評価します (空でないなら
-与えられた文字列は真です)。利用可能な比較演算子の全てのリストについては、
-mod_include ドキュメンテーションを参照してください。
-ここでは、この構造をどう使用するかの例をいくつか示します。
設定ファイルで次の行を記述します:
- -- BrowserMatchNoCase macintosh Mac - BrowserMatchNoCase MSIE InternetExplorer -- -
これはクライアントが Macintosh 上でインターネットエクスプローラが -動いている場合、環境変数 ``Mac'' と ``InternetExplorer'' を真と設定します。
- -次に、SSI が可能になったドキュメントで以下を行ないます:
- -
- <!--#if expr="${Mac} && ${InternetExplorer}" -->
- Apologetic text goes here
- <!--#else -->
- Cool JavaScript code goes here
- <!--#endif -->
-
-
-Mac 上の IE に対して何か思うところがあるわけでありません。 -他では実行できているいくつかの JavaScript を Mac 上の IE で -実行させるのに、先週数時間苦労したというだけのことです。 -上の例はその暫定的な対処方法です。
- -他のどんな変数 (あなたが定義するもの、または普通の環境変数のいずれか) も、
-条件文に使用することができます。Apache は SetEnvIf
-ディレクティブや他の関連ディレクティブ使用して環境変数を設定することが
-できます。この機能により、CGI に頼ることなくかなり複雑な動的なことをさせる
-ことができます。
SSI は確かに CGI や動的なウェブページを生成する他の技術に代わるもの -ではありません。しかし、 -たくさんの余分な作業をせずに、少量の動的なコンテンツを加えるには -すぐれた方法です。
- - - -- cgit v1.2.1