httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rbo...@apache.org
Subject cvs commit: httpd-docs-1.3/htdocs/manual/howto cgi.html.en cgi.html.html footer.html header.html ssi.html.en ssi.html.html
Date Mon, 08 Oct 2001 01:23:28 GMT
rbowen      01/10/07 18:23:28

  Modified:    htdocs/manual/howto cgi.html.en cgi.html.html footer.html
                        header.html ssi.html.en ssi.html.html
  Log:
  W3C tidy to convert to xhtml. The .ja.jis files have not been done, as
  tidy always has problems with those.
  
  Revision  Changes    Path
  1.7       +487 -434  httpd-docs-1.3/htdocs/manual/howto/cgi.html.en
  
  Index: cgi.html.en
  ===================================================================
  RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/howto/cgi.html.en,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- cgi.html.en	2000/12/03 03:02:59	1.6
  +++ cgi.html.en	2001/10/08 01:23:28	1.7
  @@ -1,405 +1,454 @@
  -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
  -<html>
  -<head>
  -<title>Apache Tutorial: Dynamic Content with CGI</title>
  -<link rev="made" href="mailto:rbowen@rcbowen.com">
  -</head>
  -<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  -<body bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#000080"
  -alink="#FF0000">
  -<!--#include virtual="header.html" -->
  -<h1 align="CENTER">Dynamic Content with CGI</h1>
  +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  +    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   
  -<a name="__index__"></a> <!-- INDEX BEGIN -->
  - 
  +<html xmlns="http://www.w3.org/1999/xhtml">
  +  <head>
  +    <meta name="generator" content="HTML Tidy, see www.w3.org" />
  +
  +    <title>Apache Tutorial: Dynamic Content with CGI</title>
  +    <link rev="made" href="mailto:rbowen@rcbowen.com" />
  +  </head>
  +  <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  +
  +  <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
  +  vlink="#000080" alink="#FF0000">
  +    <!--#include virtual="header.html" -->
  +
  +    <h1 align="CENTER">Dynamic Content with CGI</h1>
  +    <a id="__index__" name="__index__"></a> <!-- INDEX BEGIN -->
  +     
  +
  +    <ul>
  +      <li><a href="#dynamiccontentwithcgi">Dynamic Content with
  +      CGI</a></li>
  +
  +      <li>
  +        <a href="#configuringapachetopermitcgi">Configuring Apache
  +        to permit CGI</a> 
  +
  +        <ul>
  +          <li><a href="#scriptalias">ScriptAlias</a></li>
  +
  +          <li>
  +            <a href="#cgioutsideofscriptaliasdirectories">CGI
  +            outside of ScriptAlias directories</a> 
  +
  +            <ul>
  +              <li><a
  +              href="#explicitlyusingoptionstopermitcgiexecution">Explicitly
  +              using Options to permit CGI execution</a></li>
  +
  +              <li><a href="#htaccessfiles">.htaccess files</a></li>
  +            </ul>
  +          </li>
  +        </ul>
  +      </li>
  +
  +      <li>
  +        <a href="#writingacgiprogram">Writing a CGI program</a> 
  +
  +        <ul>
  +          <li><a href="#yourfirstcgiprogram">Your first CGI
  +          program</a></li>
  +        </ul>
  +      </li>
  +
  +      <li>
  +        <a href="#butitsstillnotworking">But it's still not
  +        working!</a> 
  +
  +        <ul>
  +          <li><a href="#filepermissions">File permissions</a></li>
  +
  +          <li><a href="#pathinformation">Path information</a></li>
  +
  +          <li><a href="#syntaxerrors">Syntax errors</a></li>
  +
  +          <li><a href="#errorlogs">Error logs</a></li>
  +        </ul>
  +      </li>
  +
  +      <li>
  +        <a href="#whatsgoingonbehindthescenes">What's going on
  +        behind the scenes?</a> 
  +
  +        <ul>
  +          <li><a href="#environmentvariables">Environment
  +          variables</a></li>
  +
  +          <li><a href="#stdinandstdout">STDIN and STDOUT</a></li>
  +        </ul>
  +      </li>
  +
  +      <li><a href="#cgimoduleslibraries">CGI
  +      modules/libraries</a></li>
  +
  +      <li><a href="#formoreinformation">For more
  +      information</a></li>
  +    </ul>
  +    <!-- INDEX END -->
  +    <hr />
  +
  +    <h2><a id="dynamiccontentwithcgi"
  +    name="dynamiccontentwithcgi">Dynamic Content with CGI</a></h2>
  +
  +    <table border="1">
  +      <tr>
  +        <td valign="top"><strong>Related Modules</strong><br />
  +         <br />
  +         <a href="../mod/mod_alias.html">mod_alias</a><br />
  +         <a href="../mod/mod_cgi.html">mod_cgi</a><br />
  +         </td>
  +
  +        <td valign="top"><strong>Related Directives</strong><br />
  +         <br />
  +         <a
  +        href="../mod/mod_mime.html#addhandler">AddHandler</a><br />
  +         <a href="../mod/core.html#options">Options</a><br />
  +         <a
  +        href="../mod/mod_alias.html#scriptalias">ScriptAlias</a><br />
  +         </td>
  +      </tr>
  +    </table>
  +
  +    <p>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.</p>
  +    <hr />
  +
  +    <h2><a id="configuringapachetopermitcgi"
  +    name="configuringapachetopermitcgi">Configuring Apache to
  +    permit CGI</a></h2>
  +
  +    <p>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.</p>
  +
  +    <h3><a id="scriptalias" name="scriptalias">ScriptAlias</a></h3>
  +
  +    <p>The <code>ScriptAlias</code> 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.</p>
   
  -<ul>
  -<li><a href="#dynamiccontentwithcgi">Dynamic Content with
  -CGI</a></li>
  -
  -<li><a href="#configuringapachetopermitcgi">Configuring Apache to
  -permit CGI</a>
  -
  -<ul>
  -<li><a href="#scriptalias">ScriptAlias</a></li>
  -
  -<li><a href="#cgioutsideofscriptaliasdirectories">CGI outside of
  -ScriptAlias directories</a>
  -
  -<ul>
  -<li><a href="#explicitlyusingoptionstopermitcgiexecution">Explicitly using
  -Options to permit CGI execution</a></li>
  -
  -<li><a href="#htaccessfiles">.htaccess files</a></li>
  -</ul>
  -</li>
  -</ul>
  -</li>
  -
  -<li><a href="#writingacgiprogram">Writing a CGI program</a>
  -
  -<ul>
  -<li><a href="#yourfirstcgiprogram">Your first CGI program</a></li>
  -</ul>
  -</li>
  -
  -<li><a href="#butitsstillnotworking">But it's still not
  -working!</a>
  -
  -<ul>
  -<li><a href="#filepermissions">File permissions</a></li>
  -
  -<li><a href="#pathinformation">Path information</a></li>
  -
  -<li><a href="#syntaxerrors">Syntax errors</a></li>
  -
  -<li><a href="#errorlogs">Error logs</a></li>
  -</ul>
  -</li>
  -
  -<li><a href="#whatsgoingonbehindthescenes">What's going on behind
  -the scenes?</a>
  -
  -<ul>
  -<li><a href="#environmentvariables">Environment variables</a></li>
  -
  -<li><a href="#stdinandstdout">STDIN and STDOUT</a></li>
  -</ul>
  -</li>
  -
  -<li><a href="#cgimoduleslibraries">CGI modules/libraries</a></li>
  -
  -<li><a href="#formoreinformation">For more information</a></li>
  -</ul>
  -
  -<!-- INDEX END -->
  -<hr>
  -<h2><a name="dynamiccontentwithcgi">Dynamic Content with
  -CGI</a></h2>
  -
  -<table border="1">
  -<tr><td valign="top">
  -<strong>Related Modules</strong><br><br>
  -
  -<a href="../mod/mod_alias.html">mod_alias</a><br>
  -<a href="../mod/mod_cgi.html">mod_cgi</a><br>
  -
  -</td><td valign="top">
  -<strong>Related Directives</strong><br><br>
  -
  -<a href="../mod/mod_mime.html#addhandler">AddHandler</a><br>
  -<A HREF="../mod/core.html#options">Options</a><br>
  -<a href="../mod/mod_alias.html#scriptalias">ScriptAlias</a><br>
  -
  -</td></tr></table>
  -
  -<p>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.</p>
  -
  -<hr>
  -<h2><a name="configuringapachetopermitcgi">Configuring Apache to
  -permit CGI</a></h2>
  -
  -<p>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.</p>
  -
  -<h3><a name="scriptalias">ScriptAlias</a></h3>
  -
  -<p>The <code>ScriptAlias</code> 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.</p>
  -
  -<p>The <code>ScriptAlias</code> directive looks like:</p>
  -
  +    <p>The <code>ScriptAlias</code> directive looks like:</p>
   <pre>
           ScriptAlias /cgi-bin/ /usr/local/apache/cgi-bin/
   </pre>
  -
  -<p>The example shown is from your default <code>httpd.conf</code>
  -configuration file, if you installed Apache in the default location.
  -The <code>ScriptAlias</code> directive is much like the
  -<code>Alias</code> directive, which defines a URL prefix that is to
  -mapped to a particular directory. <code>Alias</code> and
  -<code>ScriptAlias</code> are usually used for directories that are
  -outside of the <code>DocumentRoot</code> directory. The difference
  -between <code>Alias</code> and <code>ScriptAlias</code> is that
  -<code>ScriptAlias</code> 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
  -<code>/cgi-bin/</code> should be served from the directory
  -<code>/usr/local/apache/cgi-bin/</code>, and should be treated as a CGI
  -program.</p>
  -
  -<p>For example, if the URL
  -<code>http://dev.rcbowen.com/cgi-bin/test.pl</code> is requested,
  -Apache will attempt to execute the file
  -<code>/usr/local/apache/cgi-bin/test.pl</code> 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.</p>
  -
  -<h3><a name="cgioutsideofscriptaliasdirectories">CGI outside of
  -ScriptAlias directories</a></h3>
  -
  -<p>CGI programs are often restricted to <code>ScriptAlias</code>'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 <code>UserDir</code> directive. If they want to have their
  -own CGI programs, but don't have access to the main
  -<code>cgi-bin</code> directory, they will need to be able to run CGI
  -programs elsewhere.</p>
  -
  -<h3><a name="explicitlyusingoptionstopermitcgiexecution">Explicitly using
  -Options to permit CGI execution</a></h3>
  -
  -<p>You could explicitly use the <code>Options</code> directive, inside
  -your main server configuration file, to specify that CGI execution was
  -permitted in a particular directory:</p>
   
  +    <p>The example shown is from your default
  +    <code>httpd.conf</code> configuration file, if you installed
  +    Apache in the default location. The <code>ScriptAlias</code>
  +    directive is much like the <code>Alias</code> directive, which
  +    defines a URL prefix that is to mapped to a particular
  +    directory. <code>Alias</code> and <code>ScriptAlias</code> are
  +    usually used for directories that are outside of the
  +    <code>DocumentRoot</code> directory. The difference between
  +    <code>Alias</code> and <code>ScriptAlias</code> is that
  +    <code>ScriptAlias</code> 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 <code>/cgi-bin/</code> should be served from the
  +    directory <code>/usr/local/apache/cgi-bin/</code>, and should
  +    be treated as a CGI program.</p>
  +
  +    <p>For example, if the URL
  +    <code>http://dev.rcbowen.com/cgi-bin/test.pl</code> is
  +    requested, Apache will attempt to execute the file
  +    <code>/usr/local/apache/cgi-bin/test.pl</code> 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.</p>
  +
  +    <h3><a id="cgioutsideofscriptaliasdirectories"
  +    name="cgioutsideofscriptaliasdirectories">CGI outside of
  +    ScriptAlias directories</a></h3>
  +
  +    <p>CGI programs are often restricted to
  +    <code>ScriptAlias</code>'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 <code>UserDir</code> directive. If they want to have
  +    their own CGI programs, but don't have access to the main
  +    <code>cgi-bin</code> directory, they will need to be able to
  +    run CGI programs elsewhere.</p>
  +
  +    <h3><a id="explicitlyusingoptionstopermitcgiexecution"
  +    name="explicitlyusingoptionstopermitcgiexecution">Explicitly
  +    using Options to permit CGI execution</a></h3>
  +
  +    <p>You could explicitly use the <code>Options</code> directive,
  +    inside your main server configuration file, to specify that CGI
  +    execution was permitted in a particular directory:</p>
   <pre>
           &lt;Directory /usr/local/apache/htdocs/somedir&gt;
                   Options +ExecCGI
           &lt;/Directory&gt;
   </pre>
  -
  -<p>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 <code>AddHandler</code> directive tells the server
  -to treat all files with the <code>cgi</code> or <code>pl</code>
  -extension as CGI programs:</p>
   
  +    <p>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 <code>AddHandler</code> directive
  +    tells the server to treat all files with the <code>cgi</code>
  +    or <code>pl</code> extension as CGI programs:</p>
   <pre>
        AddHandler cgi-script cgi pl
   </pre>
   
  -<h3><a name="htaccessfiles">.htaccess files</a></h3>
  +    <h3><a id="htaccessfiles" name="htaccessfiles">.htaccess
  +    files</a></h3>
   
  -<p>A <code>.htaccess</code> 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 <code>.htaccess</code>, and, if it finds it, it will apply
  -directives found therein. <code>.htaccess</code> files can be permitted
  -with the <code>AllowOverride</code> 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:</p>
  -
  +    <p>A <code>.htaccess</code> 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 <code>.htaccess</code>, and, if it finds
  +    it, it will apply directives found therein.
  +    <code>.htaccess</code> files can be permitted with the
  +    <code>AllowOverride</code> 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:</p>
   <pre>
           AllowOverride Options
   </pre>
  -
  -<p>In the <code>.htaccess</code> file, you'll need the following
  -directive:</p>
   
  +    <p>In the <code>.htaccess</code> file, you'll need the
  +    following directive:</p>
   <pre>
           Options +ExecCGI
   </pre>
  -
  -<p>which tells Apache that execution of CGI programs is permitted in
  -this directory.</p>
   
  -<hr>
  -<h2><a name="writingacgiprogram">Writing a CGI program</a></h2>
  -
  -<p>There are two main differences between ``regular'' programming, and
  -CGI programming.</p>
  -
  -<p>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:</p>
  -
  +    <p>which tells Apache that execution of CGI programs is
  +    permitted in this directory.</p>
  +    <hr />
  +
  +    <h2><a id="writingacgiprogram"
  +    name="writingacgiprogram">Writing a CGI program</a></h2>
  +
  +    <p>There are two main differences between ``regular''
  +    programming, and CGI programming.</p>
  +
  +    <p>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:</p>
   <pre>
           Content-type: text/html
   </pre>
   
  -<p>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.</p>
  -
  -<p>Apart from those two things, writing a CGI program will look a lot
  -like any other program that you might write.</p>
  -
  -<h3><a name="yourfirstcgiprogram">Your first CGI program</a></h3>
  -
  -<p>The following is an example CGI program that prints one line to your
  -browser. Type in the following, save it to a file called
  -<code>first.pl</code>, and put it in your <code>cgi-bin</code>
  -directory.</p>
  -
  +    <p>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.</p>
  +
  +    <p>Apart from those two things, writing a CGI program will look
  +    a lot like any other program that you might write.</p>
  +
  +    <h3><a id="yourfirstcgiprogram" name="yourfirstcgiprogram">Your
  +    first CGI program</a></h3>
  +
  +    <p>The following is an example CGI program that prints one line
  +    to your browser. Type in the following, save it to a file
  +    called <code>first.pl</code>, and put it in your
  +    <code>cgi-bin</code> directory.</p>
   <pre>
           #!/usr/bin/perl
           print "Content-type: text/html\r\n\r\n";
           print "Hello, World.";
   </pre>
  -
  -<p>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
  -<code>/usr/bin/perl</code>. 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.</p>
   
  -<p>If you open your favorite browser and tell it to get the address</p>
  +    <p>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 <code>/usr/bin/perl</code>. 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.</p>
   
  +    <p>If you open your favorite browser and tell it to get the
  +    address</p>
   <pre>
           http://www.example.com/cgi-bin/first.pl
   </pre>
  -
  -<p>or wherever you put your file, you will see the one line
  -<code>Hello, World.</code> 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.</p>
  -
  -<hr>
  -<h2><a name="butitsstillnotworking">But it's still not
  -working!</a></h2>
  -
  -<p>There are four basic things that you may see in your browser when
  -you try to access your CGI program from the web:</p>
  -
  -<dl>
  -<dt>The output of your CGI program</dt>
  -<dd>Great!  That means everything worked fine.<br><br></dd>
  -
  -<dt>The source code of your CGI program or a "POST Method Not Allowed"
  -message</dt> 
  -<dd>That means that you have not properly configured
  -Apache to process your CGI program.  Reread the section on <a
  -href="#configuringapachetopermitcgi">configuring Apache</a> and try to
  -find what you missed.<br><br></dd>
  -
  -<dt>A message starting with "Forbidden"</dt> <dd>That means that there
  -is a permissions problem.  Check the <a href="#errorlogs">Apache
  -error log</a> and the section below on <a
  -href="#filepermissions">file permissions</a>.<br><br></dd>
  -
  -<dt>A message saying "Internal Server Error"</dt> <dd>If you check the
  -<a href="#errorlogs">Apache error log</a>, 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.</dd>
  -</dl>
  -
  -
  -<h3><a name="filepermissions">File permissions</a></h3>
  -
  -<p>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:</p>
   
  +    <p>or wherever you put your file, you will see the one line
  +    <code>Hello, World.</code> 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.</p>
  +    <hr />
  +
  +    <h2><a id="butitsstillnotworking"
  +    name="butitsstillnotworking">But it's still not
  +    working!</a></h2>
  +
  +    <p>There are four basic things that you may see in your browser
  +    when you try to access your CGI program from the web:</p>
  +
  +    <dl>
  +      <dt>The output of your CGI program</dt>
  +
  +      <dd>Great! That means everything worked fine.<br />
  +      <br />
  +      </dd>
  +
  +      <dt>The source code of your CGI program or a "POST Method Not
  +      Allowed" message</dt>
  +
  +      <dd>That means that you have not properly configured Apache
  +      to process your CGI program. Reread the section on <a
  +      href="#configuringapachetopermitcgi">configuring Apache</a>
  +      and try to find what you missed.<br />
  +      <br />
  +      </dd>
  +
  +      <dt>A message starting with "Forbidden"</dt>
  +
  +      <dd>That means that there is a permissions problem. Check the
  +      <a href="#errorlogs">Apache error log</a> and the section
  +      below on <a href="#filepermissions">file
  +      permissions</a>.<br />
  +      <br />
  +      </dd>
  +
  +      <dt>A message saying "Internal Server Error"</dt>
  +
  +      <dd>If you check the <a href="#errorlogs">Apache error
  +      log</a>, 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.</dd>
  +    </dl>
  +
  +    <h3><a id="filepermissions" name="filepermissions">File
  +    permissions</a></h3>
  +
  +    <p>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:</p>
   <pre>
           chmod a+x first.pl
   </pre>
   
  -<p>Also, if your program reads from, or writes to, any other files,
  -those files will need to have the correct permissions to permit
  -this.</p>
  -
  -<p>The exception to this is when the server is configured to use <a
  -href="../suexec.html">suexec</a>.  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.</p>
  -
  -<h3><a name="pathinformation">Path information</a></h3>
  -
  -<p>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.</p>
  -
  -<p>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.</p>
  -
  -<p>A common manifestation of this is the path to the script interpreter
  -(often <code>perl</code>) indicated in the first line of your CGI
  -program, which will look something like:</p>
  -
  +    <p>Also, if your program reads from, or writes to, any other
  +    files, those files will need to have the correct permissions to
  +    permit this.</p>
  +
  +    <p>The exception to this is when the server is configured to
  +    use <a href="../suexec.html">suexec</a>. 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.</p>
  +
  +    <h3><a id="pathinformation" name="pathinformation">Path
  +    information</a></h3>
  +
  +    <p>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.</p>
  +
  +    <p>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.</p>
  +
  +    <p>A common manifestation of this is the path to the script
  +    interpreter (often <code>perl</code>) indicated in the first
  +    line of your CGI program, which will look something like:</p>
   <pre>
        #!/usr/bin/perl
   </pre>
  -
  -<p>Make sure that this is in fact the path to the interpreter.</p>
   
  -<h3><a name="syntaxerrors">Syntax errors</a></h3>
  +    <p>Make sure that this is in fact the path to the
  +    interpreter.</p>
   
  -<p>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.</p>
  -
  -<h3><a name="errorlogs">Error logs</a></h3>
  -
  -<p>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.</p>
  -
  -<hr>
  -<h2><a name="whatsgoingonbehindthescenes">What's going on behind
  -the scenes?</a></h2>
  -
  -<p>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.</p>
  -
  -<h3><a name="environmentvariables">Environment variables</a></h3>
  -
  -<p>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 <code>env</code>
  -at a command prompt.</p>
  -
  -<p>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.</p>
  -
  -<p>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 <a href=
  -"http://hoohoo.ncsa.uiuc.edu/cgi/env.html">http://hoohoo.ncsa.uiuc.edu/cgi/env.html</a></p>
  -
  -<p>This simple Perl CGI program will display all of the environment
  -variables that are being passed around.  Two similar programs are
  -included in the <code>cgi-bin</code> 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 <a href="../env.html">add your own environment variables</a> to
  -the basic ones provided by default.</p>
  +    <h3><a id="syntaxerrors" name="syntaxerrors">Syntax
  +    errors</a></h3>
   
  +    <p>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.</p>
  +
  +    <h3><a id="errorlogs" name="errorlogs">Error logs</a></h3>
  +
  +    <p>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.</p>
  +    <hr />
  +
  +    <h2><a id="whatsgoingonbehindthescenes"
  +    name="whatsgoingonbehindthescenes">What's going on behind the
  +    scenes?</a></h2>
  +
  +    <p>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.</p>
  +
  +    <h3><a id="environmentvariables"
  +    name="environmentvariables">Environment variables</a></h3>
  +
  +    <p>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 <code>env</code> at a command
  +    prompt.</p>
  +
  +    <p>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.</p>
  +
  +    <p>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 <a
  +    href="http://hoohoo.ncsa.uiuc.edu/cgi/env.html">http://hoohoo.ncsa.uiuc.edu/cgi/env.html</a></p>
  +
  +    <p>This simple Perl CGI program will display all of the
  +    environment variables that are being passed around. Two similar
  +    programs are included in the <code>cgi-bin</code> 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 <a
  +    href="../env.html">add your own environment variables</a> to
  +    the basic ones provided by default.</p>
   <pre>
        #!/usr/bin/perl
        print "Content-type: text/html\n\n";
  @@ -407,93 +456,97 @@
             print "$key --&gt; $ENV{$key}&lt;br&gt;";
        }
   </pre>
  -
  -<h3><a name="stdinandstdout">STDIN and STDOUT</a></h3>
   
  -<p>Other communication between the server and the client happens over
  -standard input (<code>STDIN</code>) and standard output
  -(<code>STDOUT</code>). In normal everyday context, <code>STDIN</code>
  -means the keyboard, or a file that a program is given to act on, and
  -<code>STDOUT</code> usually means the console or screen.</p>
  -
  -<p>When you <code>POST</code> 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 <code>STDIN</code>. The program then can process
  -that data as though it was coming in from the keyboard, or from a
  -file</p>
  -
  -<p>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 (&amp;). 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:</p>
  +    <h3><a id="stdinandstdout" name="stdinandstdout">STDIN and
  +    STDOUT</a></h3>
   
  +    <p>Other communication between the server and the client
  +    happens over standard input (<code>STDIN</code>) and standard
  +    output (<code>STDOUT</code>). In normal everyday context,
  +    <code>STDIN</code> means the keyboard, or a file that a program
  +    is given to act on, and <code>STDOUT</code> usually means the
  +    console or screen.</p>
  +
  +    <p>When you <code>POST</code> 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 <code>STDIN</code>. The
  +    program then can process that data as though it was coming in
  +    from the keyboard, or from a file</p>
  +
  +    <p>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 (&amp;).
  +    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:</p>
   <pre>
        name=Rich%20Bowen&amp;city=Lexington&amp;state=KY&amp;sidekick=Squirrel%20Monkey
   </pre>
  -
  -<p>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 <code>QUERY_STRING</code>. That's called a
  -<code>GET</code> request. Your HTML form specifies whether a
  -<code>GET</code> or a <code>POST</code> is used to deliver the data, by
  -setting the <code>METHOD</code> attribute in the <code>FORM</code>
  -tag.</p>
  -
  -<p>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.</p>
  -
  -<hr>
  -<h2><a name="cgimoduleslibraries">CGI modules/libraries</a></h2>
  -
  -<p>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.</p>
  -
  -<p>If you're writing CGI programs in Perl, modules are available on <a
  -href="http://www.cpan.org/">CPAN</a>. 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.</p>
  -
  -<p>If you're writing CGI programs in C, there are a variety of options.
  -One of these is the CGIC library, from <a href=
  -"http://www.boutell.com/cgic/">http://www.boutell.com/cgic/</a></p>
  -
  -<hr>
  -<h2><a name="formoreinformation">For more information</a></h2>
  -
  -<p>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 <a href=
  -"http://www.hwg.org/lists/hwg-servers/">http://www.hwg.org/lists/hwg-servers/</a></p>
  -
  -<p>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 <a href=
  -"http://hoohoo.ncsa.uiuc.edu/cgi/interface.html">NCSA</a> and there is
  -an updated draft at the <a
  -href="http://web.golux.com/coar/cgi/">Common Gateway Interface RFC
  -project</a>.</p>
  -
  -<p>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.</p>
  -
  -<p>Note that questions about CGI problems should <strong>never</strong>
  -be posted to the Apache bug database unless you are sure you have found
  -a problem in the Apache source code.</p>
  -
  -<!--#include virtual="footer.html" -->
   
  -</body>
  +    <p>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 <code>QUERY_STRING</code>.
  +    That's called a <code>GET</code> request. Your HTML form
  +    specifies whether a <code>GET</code> or a <code>POST</code> is
  +    used to deliver the data, by setting the <code>METHOD</code>
  +    attribute in the <code>FORM</code> tag.</p>
  +
  +    <p>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.</p>
  +    <hr />
  +
  +    <h2><a id="cgimoduleslibraries" name="cgimoduleslibraries">CGI
  +    modules/libraries</a></h2>
  +
  +    <p>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.</p>
  +
  +    <p>If you're writing CGI programs in Perl, modules are
  +    available on <a href="http://www.cpan.org/">CPAN</a>. 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.</p>
  +
  +    <p>If you're writing CGI programs in C, there are a variety of
  +    options. One of these is the CGIC library, from <a
  +    href="http://www.boutell.com/cgic/">http://www.boutell.com/cgic/</a></p>
  +    <hr />
  +
  +    <h2><a id="formoreinformation" name="formoreinformation">For
  +    more information</a></h2>
  +
  +    <p>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 <a
  +    href="http://www.hwg.org/lists/hwg-servers/">http://www.hwg.org/lists/hwg-servers/</a></p>
  +
  +    <p>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 <a
  +    href="http://hoohoo.ncsa.uiuc.edu/cgi/interface.html">NCSA</a>
  +    and there is an updated draft at the <a
  +    href="http://web.golux.com/coar/cgi/">Common Gateway Interface
  +    RFC project</a>.</p>
  +
  +    <p>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.</p>
  +
  +    <p>Note that questions about CGI problems should
  +    <strong>never</strong> be posted to the Apache bug database
  +    unless you are sure you have found a problem in the Apache
  +    source code.</p>
  +    <!--#include virtual="footer.html" -->
  +  </body>
   </html>
   
  
  
  
  1.2       +3 -0      httpd-docs-1.3/htdocs/manual/howto/cgi.html.html
  
  Index: cgi.html.html
  ===================================================================
  RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/howto/cgi.html.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- cgi.html.html	2001/02/10 21:59:15	1.1
  +++ cgi.html.html	2001/10/08 01:23:28	1.2
  @@ -1 +1,4 @@
  +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  +    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
   <!--#include virtual="cgi.html.en" -->
  +
  
  
  
  1.2       +17 -6     httpd-docs-1.3/htdocs/manual/howto/footer.html
  
  Index: footer.html
  ===================================================================
  RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/howto/footer.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- footer.html	2000/11/05 20:59:14	1.1
  +++ footer.html	2001/10/08 01:23:28	1.2
  @@ -1,8 +1,19 @@
  -<HR>
  +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  +    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   
  -<H3 ALIGN="CENTER">
  - Apache HTTP Server Version 1.3
  -</H3>
  +<html xmlns="http://www.w3.org/1999/xhtml">
  +  <head>
  +    <meta name="generator" content="HTML Tidy, see www.w3.org" />
   
  -<A HREF="./"><IMG SRC="../images/index.gif" ALT="Index"></A>
  -<A HREF="../"><IMG SRC="../images/home.gif" ALT="Home"></A>
  +    <title></title>
  +  </head>
  +
  +  <body>
  +    <hr />
  +
  +    <h3 align="CENTER">Apache HTTP Server Version 1.3</h3>
  +    <a href="./"><img src="../images/index.gif" alt="Index" /></a>
  +    <a href="../"><img src="../images/home.gif" alt="Home" /></a>
  +  </body>
  +</html>
  +
  
  
  
  1.2       +19 -6     httpd-docs-1.3/htdocs/manual/howto/header.html
  
  Index: header.html
  ===================================================================
  RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/howto/header.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- header.html	2000/11/05 20:59:14	1.1
  +++ header.html	2001/10/08 01:23:28	1.2
  @@ -1,6 +1,19 @@
  -<DIV ALIGN="CENTER">
  - <IMG SRC="../images/sub.gif" ALT="[APACHE DOCUMENTATION]">
  - <H3>
  -  Apache HTTP Server Version 1.3
  - </H3>
  -</DIV>
  +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  +    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  +
  +<html xmlns="http://www.w3.org/1999/xhtml">
  +  <head>
  +    <meta name="generator" content="HTML Tidy, see www.w3.org" />
  +
  +    <title></title>
  +  </head>
  +
  +  <body>
  +    <div align="CENTER">
  +      <img src="../images/sub.gif" alt="[APACHE DOCUMENTATION]" /> 
  +
  +      <h3>Apache HTTP Server Version 1.3</h3>
  +    </div>
  +  </body>
  +</html>
  +
  
  
  
  1.8       +423 -394  httpd-docs-1.3/htdocs/manual/howto/ssi.html.en
  
  Index: ssi.html.en
  ===================================================================
  RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/howto/ssi.html.en,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- ssi.html.en	2001/01/24 18:13:37	1.7
  +++ ssi.html.en	2001/10/08 01:23:28	1.8
  @@ -1,492 +1,521 @@
  -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
  -<html>
  -<head>
  -<title>Apache Tutorial: Introduction to Server Side Includes</title>
  -<link rev="made" href="mailto:rbowen@rcbowen.com">
  -</head>
  -<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  -<body bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#000080"
  -alink="#FF0000">
  -<!--#include virtual="header.html" -->
  -<h1 align="CENTER">Apache Tutorial: Introduction to Server Side
  -Includes</h1>
  -
  -<a name="__index__"></a> <!-- INDEX BEGIN -->
  - 
  -
  -<ul>
  -<li><a href=
  -"#apachetutorial:introductiontoserversideincludes">Apache
  -Tutorial: Introduction to Server Side Includes</a></li>
  -
  -<li><a href="#whataressi">What are SSI?</a></li>
  -
  -<li><a href="#configuringyourservertopermitssi">Configuring your
  -server to permit SSI</a></li>
  -
  -<li><a href="#basicssidirectives">Basic SSI directives</a>
  -
  -<ul>
  -  <li><a href="#today'sdate">Today's date</a></li>
  -
  -  <li><a href="#modificationdateofthefile">Modification date of the
  -file</a></li>
  -
  -  <li><a href="#includingtheresultsofacgiprogram">Including the
  -results of a CGI program</a></li>
  -</ul>
  -</li>
  -
  -<li><a href="#additionalexamples">Additional examples</a>
  -
  -<ul>
  -<li><a href="#whenwasthisdocumentmodified">When was this document
  -modified?</a></li>
  -
  -<li><a href="#includingastandardfooter">Including a standard
  -footer</a></li>
  -
  -<li><a href="#whatelsecaniconfig">What else can I config?</a></li>
  -
  -<li><a href="#executingcommands">Executing commands</a></li>
  -</ul>
  -</li>
  -
  -<li><a href="#advancedssitechniques">Advanced SSI techniques</a>
  -
  -<ul>
  -<li><a href="#settingvariables">Setting variables</a></li>
  -
  -<li><a href="#conditionalexpressions">Conditional expressions</a></li>
  -</ul>
  -</li>
  -
  -<li><a href="#conclusion">Conclusion</a></li>
  -</ul>
  -
  -<!-- INDEX END -->
  -<hr>
  -<h2><a name=
  -"apachetutorial:introductiontoserversideincludes">Apache
  -Tutorial: Introduction to Server Side Includes</a></h2>
  -
  -<table border="1">
  -<tr>
  -<td valign="top"><strong>Related Modules</strong><br>
  -<br>
  - <a href="../mod/mod_include.html">mod_include</a><br>
  -<a href="../mod/mod_cgi.html">mod_cgi</a><br>
  -<a href="../mod/mod_expires.html">mod_expires</a><br>
  - </td>
  -<td valign="top"><strong>Related Directives</strong><br>
  -<br>
  - <a href="../mod/core.html#options">Options</a><br>
  -<a href="../mod/mod_include.html#xbithack">XBitHack</a><br>
  -<a href="../mod/mod_mime.html#addtype">AddType</a><br>
  -<a href="../mod/mod_mime.html#addhandler">AddHandler</a><br>
  -<a href=
  -"../mod/mod_setenvif.html#BrowserMatchNoCase">BrowserMatchNoCase</a><br>
  -
  - </td>
  -</tr>
  -</table>
  -
  -<p>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.</p>
  -
  -<p>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.</p>
  -
  -<p>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.</p>
  -
  -<hr>
  -<h2><a name="whataressi">What are SSI?</a></h2>
  -
  -<p>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.</p>
  -
  -<p>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.</p>
  -
  -<hr>
  -<h2><a name="configuringyourservertopermitssi">Configuring your
  -server to permit SSI</a></h2>
  -
  -<p>To permit SSI on your server, you must have the following directive
  -either in your <code>httpd.conf</code> file, or in a
  -<code>.htaccess</code> file:</p>
  +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  +    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   
  +<html xmlns="http://www.w3.org/1999/xhtml">
  +  <head>
  +    <meta name="generator" content="HTML Tidy, see www.w3.org" />
  +
  +    <title>Apache Tutorial: Introduction to Server Side
  +    Includes</title>
  +    <link rev="made" href="mailto:rbowen@rcbowen.com" />
  +  </head>
  +  <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  +
  +  <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
  +  vlink="#000080" alink="#FF0000">
  +    <!--#include virtual="header.html" -->
  +
  +    <h1 align="CENTER">Apache Tutorial: Introduction to Server Side
  +    Includes</h1>
  +    <a id="__index__" name="__index__"></a> <!-- INDEX BEGIN -->
  +     
  +
  +    <ul>
  +      <li><a
  +      href="#apachetutorial:introductiontoserversideincludes">Apache
  +      Tutorial: Introduction to Server Side Includes</a></li>
  +
  +      <li><a href="#whataressi">What are SSI?</a></li>
  +
  +      <li><a href="#configuringyourservertopermitssi">Configuring
  +      your server to permit SSI</a></li>
  +
  +      <li>
  +        <a href="#basicssidirectives">Basic SSI directives</a> 
  +
  +        <ul>
  +          <li><a href="#today'sdate">Today's date</a></li>
  +
  +          <li><a href="#modificationdateofthefile">Modification
  +          date of the file</a></li>
  +
  +          <li><a href="#includingtheresultsofacgiprogram">Including
  +          the results of a CGI program</a></li>
  +        </ul>
  +      </li>
  +
  +      <li>
  +        <a href="#additionalexamples">Additional examples</a> 
  +
  +        <ul>
  +          <li><a href="#whenwasthisdocumentmodified">When was this
  +          document modified?</a></li>
  +
  +          <li><a href="#includingastandardfooter">Including a
  +          standard footer</a></li>
  +
  +          <li><a href="#whatelsecaniconfig">What else can I
  +          config?</a></li>
  +
  +          <li><a href="#executingcommands">Executing
  +          commands</a></li>
  +        </ul>
  +      </li>
  +
  +      <li>
  +        <a href="#advancedssitechniques">Advanced SSI
  +        techniques</a> 
  +
  +        <ul>
  +          <li><a href="#settingvariables">Setting
  +          variables</a></li>
  +
  +          <li><a href="#conditionalexpressions">Conditional
  +          expressions</a></li>
  +        </ul>
  +      </li>
  +
  +      <li><a href="#conclusion">Conclusion</a></li>
  +    </ul>
  +    <!-- INDEX END -->
  +    <hr />
  +
  +    <h2><a id="apachetutorial:introductiontoserversideincludes"
  +    name="apachetutorial:introductiontoserversideincludes">Apache
  +    Tutorial: Introduction to Server Side Includes</a></h2>
  +
  +    <table border="1">
  +      <tr>
  +        <td valign="top"><strong>Related Modules</strong><br />
  +         <br />
  +         <a href="../mod/mod_include.html">mod_include</a><br />
  +         <a href="../mod/mod_cgi.html">mod_cgi</a><br />
  +         <a href="../mod/mod_expires.html">mod_expires</a><br />
  +         </td>
  +
  +        <td valign="top"><strong>Related Directives</strong><br />
  +         <br />
  +         <a href="../mod/core.html#options">Options</a><br />
  +         <a
  +        href="../mod/mod_include.html#xbithack">XBitHack</a><br />
  +         <a href="../mod/mod_mime.html#addtype">AddType</a><br />
  +         <a
  +        href="../mod/mod_mime.html#addhandler">AddHandler</a><br />
  +         <a
  +        href="../mod/mod_setenvif.html#BrowserMatchNoCase">BrowserMatchNoCase</a><br />
  +         </td>
  +      </tr>
  +    </table>
  +
  +    <p>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.</p>
  +
  +    <p>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.</p>
  +
  +    <p>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.</p>
  +    <hr />
  +
  +    <h2><a id="whataressi" name="whataressi">What are SSI?</a></h2>
  +
  +    <p>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.</p>
  +
  +    <p>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.</p>
  +    <hr />
  +
  +    <h2><a id="configuringyourservertopermitssi"
  +    name="configuringyourservertopermitssi">Configuring your server
  +    to permit SSI</a></h2>
  +
  +    <p>To permit SSI on your server, you must have the following
  +    directive either in your <code>httpd.conf</code> file, or in a
  +    <code>.htaccess</code> file:</p>
   <pre>
           Options +Includes
   </pre>
   
  -<p>This tells Apache that you want to permit files to be parsed for SSI
  -directives.</p>
  +    <p>This tells Apache that you want to permit files to be parsed
  +    for SSI directives.</p>
   
  -<p>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 <code>.shtml</code>, with the following directives:</p>
  -
  +    <p>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 <code>.shtml</code>, with
  +    the following directives:</p>
   <pre>
           AddType text/html .shtml
           AddHandler server-parsed .shtml
   </pre>
  -
  -<p>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
  -<code>.shtml</code> extension, so that those directives would be
  -executed.</p>
   
  -<p>The other method is to use the <code>XBitHack</code> directive:</p>
  +    <p>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 <code>.shtml</code> extension, so that those
  +    directives would be executed.</p>
   
  +    <p>The other method is to use the <code>XBitHack</code>
  +    directive:</p>
   <pre>
           XBitHack on
   </pre>
   
  -<p><code>XBitHack</code> 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 <code>chmod</code>.</p>
  -
  +    <p><code>XBitHack</code> 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 <code>chmod</code>.</p>
   <pre>
           chmod +x pagename.html
   </pre>
  -
  -<p>A brief comment about what not to do. You'll occasionally see people
  -recommending that you just tell Apache to parse all <code>.html</code>
  -files for SSI, so that you don't have to mess with <code>.shtml</code>
  -file names. These folks have perhaps not heard about
  -<code>XBitHack</code>. 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.</p>
  -
  -<p>Of course, on Windows, there is no such thing as an execute bit to
  -set, so that limits your options a little.</p>
  -
  -<p>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:</p>
  -
  -<ol> 
  -
  -<li>Use the <code>XBitHack Full</code> 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. </li> 
  -
  -<li>Use the directives provided by <a
  -href="../mod/mod_expires.html">mod_expires</a> to set an explicit
  -expiration time on your files, thereby letting browsers and proxies
  -know that it is acceptable to cache them. </li>
   
  -</ol>
  +    <p>A brief comment about what not to do. You'll occasionally
  +    see people recommending that you just tell Apache to parse all
  +    <code>.html</code> files for SSI, so that you don't have to
  +    mess with <code>.shtml</code> file names. These folks have
  +    perhaps not heard about <code>XBitHack</code>. 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.</p>
  +
  +    <p>Of course, on Windows, there is no such thing as an execute
  +    bit to set, so that limits your options a little.</p>
  +
  +    <p>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:</p>
  +
  +    <ol>
  +      <li>Use the <code>XBitHack Full</code> 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.</li>
  +
  +      <li>Use the directives provided by <a
  +      href="../mod/mod_expires.html">mod_expires</a> to set an
  +      explicit expiration time on your files, thereby letting
  +      browsers and proxies know that it is acceptable to cache
  +      them.</li>
  +    </ol>
  +    <hr />
   
  +    <h2><a id="basicssidirectives" name="basicssidirectives">Basic
  +    SSI directives</a></h2>
   
  -<hr>
  -<h2><a name="basicssidirectives">Basic SSI directives</a></h2>
  -
  -<p>SSI directives have the following syntax:</p>
  -
  +    <p>SSI directives have the following syntax:</p>
   <pre>
           &lt;!--#element attribute=value attribute=value ... --&gt;
   </pre>
  -
  -<p>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.</p>
  -
  -<p>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</p>
   
  -<h3><a name="today'sdate">Today's date</a></h3>
  +    <p>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.</p>
  +
  +    <p>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</p>
   
  +    <h3><a id="today'sdate" name="today'sdate">Today's
  +    date</a></h3>
   <pre>
           &lt;!--#echo var="DATE_LOCAL" --&gt;
   </pre>
   
  -<p>The <code>echo</code> 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 <code>set</code>
  -element.</p>
  -
  -<p>If you don't like the format in which the date gets printed, you can
  -use the <code>config</code> element, with a <code>timefmt</code>
  -attribute, to modify that formatting.</p>
  -
  +    <p>The <code>echo</code> 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 <code>set</code> element.</p>
  +
  +    <p>If you don't like the format in which the date gets printed,
  +    you can use the <code>config</code> element, with a
  +    <code>timefmt</code> attribute, to modify that formatting.</p>
   <pre>
           &lt;!--#config timefmt="%A %B %d, %Y" --&gt;
           Today is &lt;!--#echo var="DATE_LOCAL" --&gt;
   </pre>
  -
  -<h3><a name="modificationdateofthefile">Modification date of the
  -file</a></h3>
   
  +    <h3><a id="modificationdateofthefile"
  +    name="modificationdateofthefile">Modification date of the
  +    file</a></h3>
   <pre>
           This document last modified &lt;!--#flastmod file="index.html" --&gt;
   </pre>
  -
  -<p>This element is also subject to <code>timefmt</code> format
  -configurations.</p>
   
  -<h3><a name="includingtheresultsofacgiprogram">Including the
  -results of a CGI program</a></h3>
  +    <p>This element is also subject to <code>timefmt</code> format
  +    configurations.</p>
   
  -<p>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.''</p>
  -
  +    <h3><a id="includingtheresultsofacgiprogram"
  +    name="includingtheresultsofacgiprogram">Including the results
  +    of a CGI program</a></h3>
  +
  +    <p>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.''</p>
   <pre>
           &lt;!--#include virtual="/cgi-bin/counter.pl" --&gt;
   </pre>
  -
  -<hr>
  -<h2><a name="additionalexamples">Additional examples</a></h2>
  -
  -<p>Following are some specific examples of things you can do in your
  -HTML documents with SSI.</p>
  +    <hr />
   
  -<hr>
  -<h2><a name="whenwasthisdocumentmodified">When was this document
  -modified?</a></h2>
  -
  -<p>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.</p>
  +    <h2><a id="additionalexamples"
  +    name="additionalexamples">Additional examples</a></h2>
   
  +    <p>Following are some specific examples of things you can do in
  +    your HTML documents with SSI.</p>
  +    <hr />
  +
  +    <h2><a id="whenwasthisdocumentmodified"
  +    name="whenwasthisdocumentmodified">When was this document
  +    modified?</a></h2>
  +
  +    <p>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.</p>
   <pre>
           &lt;!--#config timefmt="%A %B %d, %Y" --&gt;
           This file last modified &lt;!--#flastmod file="ssi.shtml" --&gt;
   </pre>
   
  -<p>Of course, you will need to replace the <code>ssi.shtml</code> 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
  -<code>LAST_MODIFIED</code> variable instead:</p>
  -
  +    <p>Of course, you will need to replace the
  +    <code>ssi.shtml</code> 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
  +    <code>LAST_MODIFIED</code> variable instead:</p>
   <pre>
           &lt;!--#config timefmt="%D" --&gt;
           This file last modified &lt;!--#echo var="LAST_MODIFIED" --&gt;
   </pre>
  -
  -<p>For more details on the <code>timefmt</code> format, go to your
  -favorite search site and look for <code>ctime</code>. The syntax is the
  -same.</p>
  -
  -<hr>
  -<h2><a name="includingastandardfooter">Including a standard
  -footer</a></h2>
  -
  -<p>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.</p>
  -
  -<p>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 <code>include</code> SSI
  -command. The <code>include</code> element can determine what file to
  -include with either the <code>file</code> attribute, or the
  -<code>virtual</code> attribute. The <code>file</code> attribute is a
  -file path, <em>relative to the current directory</em>. That means that
  -it cannot be an absolute file path (starting with /), nor can it
  -contain ../ as part of that path. The <code>virtual</code> 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.</p>
   
  +    <p>For more details on the <code>timefmt</code> format, go to
  +    your favorite search site and look for <code>ctime</code>. The
  +    syntax is the same.</p>
  +    <hr />
  +
  +    <h2><a id="includingastandardfooter"
  +    name="includingastandardfooter">Including a standard
  +    footer</a></h2>
  +
  +    <p>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.</p>
  +
  +    <p>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
  +    <code>include</code> SSI command. The <code>include</code>
  +    element can determine what file to include with either the
  +    <code>file</code> attribute, or the <code>virtual</code>
  +    attribute. The <code>file</code> attribute is a file path,
  +    <em>relative to the current directory</em>. That means that it
  +    cannot be an absolute file path (starting with /), nor can it
  +    contain ../ as part of that path. The <code>virtual</code>
  +    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.</p>
   <pre>
           &lt;!--#include virtual="/footer.html" --&gt;
   </pre>
   
  -<p>I'll frequently combine the last two things, putting a
  -<code>LAST_MODIFIED</code> 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.</p>
  +    <p>I'll frequently combine the last two things, putting a
  +    <code>LAST_MODIFIED</code> 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.</p>
  +    <hr />
   
  -<hr>
  -<h2><a name="whatelsecaniconfig">What else can I config?</a></h2>
  +    <h2><a id="whatelsecaniconfig" name="whatelsecaniconfig">What
  +    else can I config?</a></h2>
   
  -<p>In addition to being able to <code>config</code> the time format,
  -you can also <code>config</code> two other things.</p>
  +    <p>In addition to being able to <code>config</code> the time
  +    format, you can also <code>config</code> two other things.</p>
   
  -<p>Usually, when something goes wrong with your SSI directive, you get
  -the message</p>
  -
  +    <p>Usually, when something goes wrong with your SSI directive,
  +    you get the message</p>
   <pre>
           [an error occurred while processing this directive]
   </pre>
  -
  -<p>If you want to change that message to something else, you can do so
  -with the <code>errmsg</code> attribute to the <code>config</code>
  -element:</p>
   
  +    <p>If you want to change that message to something else, you
  +    can do so with the <code>errmsg</code> attribute to the
  +    <code>config</code> element:</p>
   <pre>
           &lt;!--#config errmsg="[It appears that you don't know how to use SSI]" --&gt;
   </pre>
   
  -<p>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?)</p>
  -
  -<p>And you can <code>config</code> the format in which file sizes are
  -returned with the <code>sizefmt</code> attribute. You can specify
  -<code>bytes</code> for a full count in bytes, or <code>abbrev</code>
  -for an abbreviated number in Kb or Mb, as appropriate.</p>
  -
  -<hr>
  -<h2><a name="executingcommands">Executing commands</a></h2>
  -
  -<p>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 <code>exec</code> element. You can actually
  -have SSI execute a command using the shell (<code>/bin/sh</code>, to be
  -precise - or the DOS shell, if you're on Win32). The following, for
  -example, will give you a directory listing.</p>
  -
  +    <p>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?)</p>
  +
  +    <p>And you can <code>config</code> the format in which file
  +    sizes are returned with the <code>sizefmt</code> attribute. You
  +    can specify <code>bytes</code> for a full count in bytes, or
  +    <code>abbrev</code> for an abbreviated number in Kb or Mb, as
  +    appropriate.</p>
  +    <hr />
  +
  +    <h2><a id="executingcommands"
  +    name="executingcommands">Executing commands</a></h2>
  +
  +    <p>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 <code>exec</code>
  +    element. You can actually have SSI execute a command using the
  +    shell (<code>/bin/sh</code>, to be precise - or the DOS shell,
  +    if you're on Win32). The following, for example, will give you
  +    a directory listing.</p>
   <pre>
           &lt;pre&gt;
           &lt;!--#exec cmd="ls" --&gt;
           &lt;/pre&gt;
   </pre>
  -
  -<p>or, on Windows</p>
   
  +    <p>or, on Windows</p>
   <pre>
           &lt;pre&gt;
           &lt;!--#exec cmd="dir" --&gt;
           &lt;/pre&gt;
   </pre>
  -
  -<p>You might notice some strange formatting with this directive on
  -Windows, because the output from <code>dir</code> contains the string
  -``&lt;<code>dir</code>&gt;'' in it, which confuses browsers.</p>
  -
  -<p>Note that this feature is exceedingly dangerous, as it will execute
  -whatever code happens to be embedded in the <code>exec</code> 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 <code>exec</code>
  -feature, with the <code>IncludesNOEXEC</code> argument to the
  -<code>Options</code> directive.</p>
  -
  -<hr>
  -<h2><a name="advancedssitechniques">Advanced SSI techniques</a></h2>
  -
  -<p>In addition to spitting out content, Apache SSI gives you the option
  -of setting variables, and using those variables in comparisons and
  -conditionals.</p>
  -
  -<h3><a name="caveat">Caveat</a></h3>
  -
  -<p>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.</p>
  -
  -<hr>
  -<h2><a name="settingvariables">Setting variables</a></h2>
  -
  -<p>Using the <code>set</code> 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:</p>
   
  +    <p>You might notice some strange formatting with this directive
  +    on Windows, because the output from <code>dir</code> contains
  +    the string ``&lt;<code>dir</code>&gt;'' in it, which confuses
  +    browsers.</p>
  +
  +    <p>Note that this feature is exceedingly dangerous, as it will
  +    execute whatever code happens to be embedded in the
  +    <code>exec</code> 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
  +    <code>exec</code> feature, with the <code>IncludesNOEXEC</code>
  +    argument to the <code>Options</code> directive.</p>
  +    <hr />
  +
  +    <h2><a id="advancedssitechniques"
  +    name="advancedssitechniques">Advanced SSI techniques</a></h2>
  +
  +    <p>In addition to spitting out content, Apache SSI gives you
  +    the option of setting variables, and using those variables in
  +    comparisons and conditionals.</p>
  +
  +    <h3><a id="caveat" name="caveat">Caveat</a></h3>
  +
  +    <p>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.</p>
  +    <hr />
  +
  +    <h2><a id="settingvariables" name="settingvariables">Setting
  +    variables</a></h2>
  +
  +    <p>Using the <code>set</code> 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:</p>
   <pre>
           &lt;!--#set var="name" value="Rich" --&gt;
   </pre>
   
  -<p>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
  -<code>LAST_MODIFIED</code>, 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.</p>
  -
  +    <p>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 <code>LAST_MODIFIED</code>, 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.</p>
   <pre>
           &lt;!--#set var="modified" value="$LAST_MODIFIED" --&gt;
   </pre>
  -
  -<p>To put a literal dollar sign into the value of your variable, you
  -need to escape the dollar sign with a backslash.</p>
   
  +    <p>To put a literal dollar sign into the value of your
  +    variable, you need to escape the dollar sign with a
  +    backslash.</p>
   <pre>
           &lt;!--#set var="cost" value="\$100" --&gt;
   </pre>
  -
  -<p>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.)</p>
   
  +    <p>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.)</p>
   <pre>
           &lt;!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" --&gt;
   </pre>
  +    <hr />
   
  -<hr>
  -<h2><a name="conditionalexpressions">Conditional expressions</a></h2>
  +    <h2><a id="conditionalexpressions"
  +    name="conditionalexpressions">Conditional expressions</a></h2>
   
  -<p>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. <code>mod_include</code> provides
  -an <code>if</code>, <code>elif</code>, <code>else</code>,
  -<code>endif</code> structure for building conditional statements. This
  -allows you to effectively generate multiple logical pages out of one
  -actual page.</p>
  +    <p>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.
  +    <code>mod_include</code> provides an <code>if</code>,
  +    <code>elif</code>, <code>else</code>, <code>endif</code>
  +    structure for building conditional statements. This allows you
  +    to effectively generate multiple logical pages out of one
  +    actual page.</p>
   
  -<p>The structure of this conditional construct is:</p>
  -
  +    <p>The structure of this conditional construct is:</p>
   <pre>
           &lt;!--#if expr="test_condition" --&gt;
       &lt;!--#elif expr="test_condition" --&gt;
       &lt;!--#else --&gt;
       &lt;!--#endif --&gt;
   </pre>
  -
  -<p>A <em>test_condition</em> 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
  -<code>mod_include</code> documentation. Here are some examples of how
  -one might use this construct.</p>
   
  -<p>In your configuration file, you could put the following line:</p>
  +    <p>A <em>test_condition</em> 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 <code>mod_include</code>
  +    documentation. Here are some examples of how one might use this
  +    construct.</p>
   
  +    <p>In your configuration file, you could put the following
  +    line:</p>
   <pre>
           BrowserMatchNoCase macintosh Mac
           BrowserMatchNoCase MSIE InternetExplorer
   </pre>
  -
  -<p>This will set environment variables ``Mac'' and ``InternetExplorer''
  -to true, if the client is running Internet Explorer on a Macintosh.</p>
   
  -<p>Then, in your SSI-enabled document, you might do the following:</p>
  +    <p>This will set environment variables ``Mac'' and
  +    ``InternetExplorer'' to true, if the client is running Internet
  +    Explorer on a Macintosh.</p>
   
  +    <p>Then, in your SSI-enabled document, you might do the
  +    following:</p>
   <pre>
           &lt;!--#if expr="${Mac} &amp;&amp; ${InternetExplorer}" --&gt;
           Apologetic text goes here
  @@ -495,25 +524,25 @@
           &lt;!--#endif --&gt;
   </pre>
   
  -<p>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.</p>
  -
  -<p>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
  -<code>SetEnvIf</code> directives, and other related directives, this
  -functionality can let you do some pretty involved dynamic stuff without
  -ever resorting to CGI.</p>
  -
  -<hr>
  -<h2><a name="conclusion">Conclusion</a></h2>
  -
  -<p>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.</p>
  -</body>
  +    <p>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.</p>
  +
  +    <p>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
  +    <code>SetEnvIf</code> directives, and other related directives,
  +    this functionality can let you do some pretty involved dynamic
  +    stuff without ever resorting to CGI.</p>
  +    <hr />
  +
  +    <h2><a id="conclusion" name="conclusion">Conclusion</a></h2>
  +
  +    <p>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.</p>
  +  </body>
   </html>
   
  
  
  
  1.2       +3 -0      httpd-docs-1.3/htdocs/manual/howto/ssi.html.html
  
  Index: ssi.html.html
  ===================================================================
  RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/howto/ssi.html.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ssi.html.html	2001/02/16 02:55:26	1.1
  +++ ssi.html.html	2001/10/08 01:23:28	1.2
  @@ -1 +1,4 @@
  +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  +    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
   <!--#include virtual="ssi.html.en" -->
  +
  
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org


Mime
View raw message