httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rbo...@apache.org
Subject cvs commit: httpd-2.0/docs/manual/howto auth.html cgi.html.en footer.html header.html ssi.html.en
Date Sat, 22 Sep 2001 19:18:26 GMT
rbowen      01/09/22 12:18:26

  Modified:    docs/manual/howto auth.html cgi.html.en footer.html
                        header.html ssi.html.en
  Log:
  w3c tidy to convert to xhtml. Please verify that foreign language files
  in here have not been screwed up.
  
  Revision  Changes    Path
  1.4       +139 -128  httpd-2.0/docs/manual/howto/auth.html
  
  Index: auth.html
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/howto/auth.html,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- auth.html	2001/09/19 15:27:17	1.3
  +++ auth.html	2001/09/22 19:18:26	1.4
  @@ -1,20 +1,21 @@
  -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
  +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  +    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   
  -<html>
  +<html xmlns="http://www.w3.org/1999/xhtml">
     <head>
  -    <meta name="generator" content="HTML Tidy, see www.w3.org">
  +    <meta name="generator" content="HTML Tidy, see www.w3.org" />
   
       <title>Authentication</title>
  -    <link rev="made" href="mailto:rbowen@rcbowen.com">
  +    <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">
  +  <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
  +  vlink="#000080" alink="#FF0000">
       <!--#include virtual="header.html" -->
   
       <h1 align="CENTER">Authentication</h1>
  -    <a name="__index__"></a> <!-- INDEX BEGIN -->
  +    <a id="__index__" name="__index__"></a> <!-- INDEX BEGIN -->
        
   
       <ul>
  @@ -22,8 +23,7 @@
   
         <li><a href="#the prerequisites">The prerequisites</a></li>
   
  -      <li><a href="#getting it working">Getting it
  -      working</a></li>
  +      <li><a href="#getting it working">Getting it working</a></li>
   
         <li><a href="#letting more than one person in">Letting more
         than one person in</a></li>
  @@ -36,94 +36,99 @@
         <li><a href="#more information">More information</a></li>
       </ul>
       <!-- INDEX END -->
  -    <hr>
  +    <hr />
   
  -<table border="1">
  -<tr>
  -<td valign="top"><strong>Related Modules</strong><br>
  -<br>
  - <a href="../mod/mod_auth.html">mod_auth</a><br>
  - <a href="../mod/mod_access.html">mod_access</a><br>
  - </td>
  -<td valign="top"><strong>Related Directives</strong><br>
  -<br>
  - <a href="../mod/mod_access.html#allow">Allow</a><br>
  - <a href="../mod/mod_auth.html#authgroupfile">AuthGroupFile</a><br>
  - <a href="../mod/core.html#authname">AuthName</a><br>
  - <a href="../mod/core.html#authtype">AuthType</a><br>
  - <a href="../mod/mod_auth.html#authuserfile">AuthUserFile</a><br>
  - <a href="../mod/mod_access.html#deny">Deny</a><br>
  - <a href="../mod/core.html#options">Options</a><br>
  - <a href="../mod/core.html#require">Require</a><br>
  -
  - </td>
  -</tr>
  -</table>
  -   
  +    <table border="1">
  +      <tr>
  +        <td valign="top"><strong>Related Modules</strong><br />
  +         <br />
  +         <a href="../mod/mod_auth.html">mod_auth</a><br />
  +         <a href="../mod/mod_access.html">mod_access</a><br />
  +         </td>
  +
  +        <td valign="top"><strong>Related Directives</strong><br />
  +         <br />
  +         <a href="../mod/mod_access.html#allow">Allow</a><br />
  +         <a
  +        href="../mod/mod_auth.html#authgroupfile">AuthGroupFile</a><br />
  +         <a href="../mod/core.html#authname">AuthName</a><br />
  +         <a href="../mod/core.html#authtype">AuthType</a><br />
  +         <a
  +        href="../mod/mod_auth.html#authuserfile">AuthUserFile</a><br />
  +         <a href="../mod/mod_access.html#deny">Deny</a><br />
  +         <a href="../mod/core.html#options">Options</a><br />
  +         <a href="../mod/core.html#require">Require</a><br />
  +         </td>
  +      </tr>
  +    </table>
   
  -    <h1><a name="authentication">Authentication</a></h1>
  +    <h1><a id="authentication"
  +    name="authentication">Authentication</a></h1>
   
       <p>Authentication is any process by which you verify that
       someone is who they claim they are. Authorization is any
       process by which someone is allowed to be where they want to
       go, or to have information that they want to have.</p>
   
  -    <h2><a name="introduction">Introduction</a></h2>
  +    <h2><a id="introduction"
  +    name="introduction">Introduction</a></h2>
   
       <p>If you have information on your web site that is sensitive
       or intended for only a small group of people, the techniques in
       this article will help you make sure that the people that see
       those pages are the people that you wanted to see them.</p>
   
  -    <p>This article covers the "standard" way of protecting parts of your
  -    web site that most of you are going to use.</p>
  +    <p>This article covers the "standard" way of protecting parts
  +    of your web site that most of you are going to use.</p>
   
  -    <h2><a name="the prerequisites">The prerequisites</a></h2>
  +    <h2><a id="the prerequisites" name="the prerequisites">The
  +    prerequisites</a></h2>
   
  -    <p>The directives discussed in this article will need to go either
  -    in your main server configuration file (typically in a
  +    <p>The directives discussed in this article will need to go
  +    either in your main server configuration file (typically in a
       &lt;Directory&gt; section), or in per-directory configuration
       files (<code>.htaccess</code> files).</p>
   
  -    <p>If you plan to use <code>.htaccess</code> files, you will need to
  -    have a server configuration that permits putting authentication
  -    directives in these files. This is done with the 
  -    <code><a href="../mod/core.html#allowoverride">AllowOverride</a></code>
  -    directive, which specifies which directives, if any, may be put in
  -    per-directory configuration files.</p>
  +    <p>If you plan to use <code>.htaccess</code> files, you will
  +    need to have a server configuration that permits putting
  +    authentication directives in these files. This is done with the
  +    <code><a
  +    href="../mod/core.html#allowoverride">AllowOverride</a></code>
  +    directive, which specifies which directives, if any, may be put
  +    in per-directory configuration files.</p>
   
  -    <p>Since we're talking here about authentication, you will need an
  -    <code>AllowOverride</code> directive like the following:</p>
  -
  +    <p>Since we're talking here about authentication, you will need
  +    an <code>AllowOverride</code> directive like the following:</p>
   <pre>
       AllowOverride AuthConfig
   </pre>
   
  -    <p>Or, if you are just going to put the directives directly in your
  -    main server configuration file, you will of course need to have
  -    write permission to that file.</p>
  +    <p>Or, if you are just going to put the directives directly in
  +    your main server configuration file, you will of course need to
  +    have write permission to that file.</p>
   
       <p>And you'll need to know a little bit about the directory
       structure of your server, in order to know where some files are
       kept. This should not be terribly difficult, and I'll try to
       make this clear when we come to that point.</p>
   
  -    <h2><a name="getting it working">Getting it working</a></h2>
  +    <h2><a id="getting it working"
  +    name="getting it working">Getting it working</a></h2>
   
       <p>Here's the basics of password protecting a directory on your
       server.</p>
   
       <p>You'll need to create a password file. This file should be
  -    placed somewhere not accessible from the web. This is so
  -    that folks cannot download the password file. For example, if
  -    your documents are served out of
  +    placed somewhere not accessible from the web. This is so that
  +    folks cannot download the password file. For example, if your
  +    documents are served out of
       <code>/usr/local/apache/htdocs</code> you might want to put the
       password file(s) in <code>/usr/local/apache/passwd</code>.</p>
   
       <p>To create the file, use the <a
       href="../programs/htpasswd.html">htpasswd</a> utility that came
  -    with Apache. This be located in the <code>bin</code> directory of
  -    wherever you installed Apache. To create the file, type:</p>
  +    with Apache. This be located in the <code>bin</code> directory
  +    of wherever you installed Apache. To create the file, type:</p>
   <pre>
           htpasswd -c /usr/local/apache/passwd/password rbowen
   </pre>
  @@ -142,15 +147,15 @@
       On my server, it's located at
       <code>/usr/local/apache/bin/htpasswd</code></p>
   
  -    <p>Next, you'll need to configure the server to request a password
  -    and tell the server which users are allowed access.  You can do
  -    this either by editing the <code>httpd.conf</code> file or using
  -    an <code>.htaccess</code> file.  For example, if you wish to
  -    protect the directory
  +    <p>Next, you'll need to configure the server to request a
  +    password and tell the server which users are allowed access.
  +    You can do this either by editing the <code>httpd.conf</code>
  +    file or using an <code>.htaccess</code> file. For example, if
  +    you wish to protect the directory
       <code>/usr/local/apache/htdocs/secret</code>, you can use the
       following directives, either placed in the file
  -    <code>/usr/local/apache/htdocs/secret/.htaccess</code>, or placed
  -    in httpd.conf inside a &lt;Directory
  +    <code>/usr/local/apache/htdocs/secret/.htaccess</code>, or
  +    placed in httpd.conf inside a &lt;Directory
       /usr/local/apache/apache/htdocs/secret&gt; section.</p>
   <pre>
           AuthType Basic
  @@ -159,70 +164,73 @@
           require user rbowen
   </pre>
   
  -    <p>Let's examine each of those directives individually.  The <a
  +    <p>Let's examine each of those directives individually. The <a
       href="../mod/core.html#authtype">AuthType</a> directive selects
  -    that method that is used to authenticate the user.  The most
  +    that method that is used to authenticate the user. The most
       common method is <code>Basic</code>, and this is the method
  -    implemented by <a href="../mod/mod_auth.html">mod_auth</a>.  It is
  -    important to be aware, however, that Basic authentication sends
  -    the password from the client to the browser unencrypted.  This
  -    method should therefore not be used for highly sensitive data.
  -    Apache supports one other authentication method: <code>AuthType
  -    Digest</code>.  This method is implemented by <a
  -    href="../mod/mod_auth_digest.html">mod_auth_digest</a> and is much
  -    more secure.  Only the most recent versions of clients are known
  -    to support Digest authentication.</p>
  -
  -    <p>The <a href="../mod/core.html#authname">AuthName</a> directive
  -    sets the <em>Realm</em> to be used in the authentication.  The
  -    realm serves two major functions.  First, the client often
  -    presents this information to the user as part of the password
  -    dialog box.  Second, it is used by the client to determine what
  -    password to send for a given authenticated area.  So, for example,
  -    once a client has authenticated in the <code>"Restricted
  -    Files"</code> area, it will automatically retry the same password
  -    for any area on the same server that is marked with the
  -    <code>"Restricted Files"</code> Realm.  Therefore, you can prevent
  -    a user from being prompted more than once for a password by
  -    letting multiple restricted areas share the same realm.  Of
  -    course, for security reasons, the client will always need to ask
  -    again for the password whenever the hostname of the server
  -    changes.</p>
  +    implemented by <a href="../mod/mod_auth.html">mod_auth</a>. It
  +    is important to be aware, however, that Basic authentication
  +    sends the password from the client to the browser unencrypted.
  +    This method should therefore not be used for highly sensitive
  +    data. Apache supports one other authentication method:
  +    <code>AuthType Digest</code>. This method is implemented by <a
  +    href="../mod/mod_auth_digest.html">mod_auth_digest</a> and is
  +    much more secure. Only the most recent versions of clients are
  +    known to support Digest authentication.</p>
  +
  +    <p>The <a href="../mod/core.html#authname">AuthName</a>
  +    directive sets the <em>Realm</em> to be used in the
  +    authentication. The realm serves two major functions. First,
  +    the client often presents this information to the user as part
  +    of the password dialog box. Second, it is used by the client to
  +    determine what password to send for a given authenticated area.
  +    So, for example, once a client has authenticated in the
  +    <code>"Restricted Files"</code> area, it will automatically
  +    retry the same password for any area on the same server that is
  +    marked with the <code>"Restricted Files"</code> Realm.
  +    Therefore, you can prevent a user from being prompted more than
  +    once for a password by letting multiple restricted areas share
  +    the same realm. Of course, for security reasons, the client
  +    will always need to ask again for the password whenever the
  +    hostname of the server changes.</p>
   
       <p>The <a
       href="../mod/mod_auth.html#authuserfile">AuthUserFile</a>
  -    directive sets the path to the password file that we just created
  -    with <code>htpasswd</code>.  If you have a large number of users,
  -    it can be quite slow to search through a plain text file to
  -    authenticate the user on each request.  Apache also has the
  -    ability to store user information in fast database files.  The
  -    modules <a href="../mod/mod_auth_db.html">mod_auth_db</a> and <a
  -    href="../mod/mod_auth_dbm.html">mod_auth_dbm</a> provide the <a
  +    directive sets the path to the password file that we just
  +    created with <code>htpasswd</code>. If you have a large number
  +    of users, it can be quite slow to search through a plain text
  +    file to authenticate the user on each request. Apache also has
  +    the ability to store user information in fast database files.
  +    The modules <a href="../mod/mod_auth_db.html">mod_auth_db</a>
  +    and <a href="../mod/mod_auth_dbm.html">mod_auth_dbm</a> provide
  +    the <a
       href="../mod/mod_auth_db.html#authdbuserfile">AuthDBUserFile</a>
       and <a
       href="../mod/mod_auth_dbm.html#authdbmuserfile">AuthDBMUserFile</a>
  -    directives respectively.  These files can be created and
  +    directives respectively. These files can be created and
       manipulated with the <a
  -    href="../programs/dbmmanage.html">dbmmanage</a> program.  Many
  +    href="../programs/dbmmanage.html">dbmmanage</a> program. Many
       other types of authentication options are available from third
  -    party modules in the <a href="http://modules.apache.org/">Apache
  -    Modules Database</a>.</p>
  +    party modules in the <a
  +    href="http://modules.apache.org/">Apache Modules
  +    Database</a>.</p>
   
       <p>Finally, the <a href="../mod/core.html#require">require</a>
       directive provides the authorization part of the process by
       setting the user that is allowed to access this region of the
  -    server.  In the next section, we discuss various ways to
  -    use the <code>require</code> directive.</p>
  -
  -    <h2><a name="letting more than one person in">Letting more than
  -    one person in</a></h2>
  +    server. In the next section, we discuss various ways to use the
  +    <code>require</code> directive.</p>
   
  -    <p>The directives above only let one person (specifically someone
  -    with a username of <code>rbowen</code>) into the directory. In
  -    most cases, you'll want to let more than one person in. This is
  -    where the <a
  -    href="../mod/mod_auth.html#authgroupfile">AuthGroupFile</a> comes
  -    in.</p>
  +    <h2><a id="letting more than one person in"
  +    name="letting more than one person in">Letting more than one
  +    person in</a></h2>
  +
  +    <p>The directives above only let one person (specifically
  +    someone with a username of <code>rbowen</code>) into the
  +    directory. In most cases, you'll want to let more than one
  +    person in. This is where the <a
  +    href="../mod/mod_auth.html#authgroupfile">AuthGroupFile</a>
  +    comes in.</p>
   
       <p>If you want to let more than one person in, you'll need to
       create a group file that associates group names with a list of
  @@ -279,7 +287,8 @@
       files, and remember to reference th right one in the
       <code>AuthUserFile</code> directive.</p>
   
  -     <h2><a name="possible problems">Possible problems</a></h2>
  +    <h2><a id="possible problems" name="possible problems">Possible
  +    problems</a></h2>
   
       <p>Because of the way that Basic authentication is specified,
       your username and password must be verified every time you
  @@ -291,16 +300,17 @@
       it has to open up that file, and go down the list of users
       until it gets to your name. And it has to do this every time a
       page is loaded.</p>
  -
  -    <p>A consequence of this is that there's a practical limit to how many
  -    users you can put in one password file. This limit will vary
  -    depending on the performance of your particular server machine, but
  -    you can expect to see slowdowns once you get above a few hundred
  -    entries, and may wish to consider a different authentication method
  -    at that time.</p>
   
  -    <h2><a name="what other neat stuff can i do">What other neat
  -    stuff can I do?</a></h2>
  +    <p>A consequence of this is that there's a practical limit to
  +    how many users you can put in one password file. This limit
  +    will vary depending on the performance of your particular
  +    server machine, but you can expect to see slowdowns once you
  +    get above a few hundred entries, and may wish to consider a
  +    different authentication method at that time.</p>
  +
  +    <h2><a id="what other neat stuff can i do"
  +    name="what other neat stuff can i do">What other neat stuff can
  +    I do?</a></h2>
   
       <p>Authentication by username and password is only part of the
       story. Frequently you want to let people in based on something
  @@ -360,12 +370,13 @@
       addition to letting everyone in. What you want is to let
       <em>only</em> those folks in.</p>
   
  -    <h2><a name="more information">More information</a></h2>
  +    <h2><a id="more information" name="more information">More
  +    information</a></h2>
   
  -    <p>You should also read the documentation for
  -    <code><a href="../mod/mod_auth.html">mod_auth</a></code> and
  -    <code><a href="../mod/mod_access.html">mod_access</a></code>
  -    which contain some more information about how this all works.</p>
  +    <p>You should also read the documentation for <code><a
  +    href="../mod/mod_auth.html">mod_auth</a></code> and <code><a
  +    href="../mod/mod_access.html">mod_access</a></code> which
  +    contain some more information about how this all works.</p>
     </body>
   </html>
   
  
  
  
  1.2       +487 -434  httpd-2.0/docs/manual/howto/cgi.html.en
  
  Index: cgi.html.en
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/howto/cgi.html.en,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- cgi.html.en	2000/12/09 19:57:35	1.1
  +++ cgi.html.en	2001/09/22 19:18:26	1.2
  @@ -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       +17 -6     httpd-2.0/docs/manual/howto/footer.html
  
  Index: footer.html
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/howto/footer.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- footer.html	2000/12/09 19:57:35	1.1
  +++ footer.html	2001/09/22 19:18:26	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 2.0
  -</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 2.0</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-2.0/docs/manual/howto/header.html
  
  Index: header.html
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/howto/header.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- header.html	2000/12/09 19:57:35	1.1
  +++ header.html	2001/09/22 19:18:26	1.2
  @@ -1,6 +1,19 @@
  -<DIV ALIGN="CENTER">
  - <IMG SRC="../images/sub.gif" ALT="[APACHE DOCUMENTATION]">
  - <H3>
  -  Apache HTTP Server Version 2.0
  - </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 2.0</h3>
  +    </div>
  +  </body>
  +</html>
  +
  
  
  
  1.7       +419 -392  httpd-2.0/docs/manual/howto/ssi.html.en
  
  Index: ssi.html.en
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/howto/ssi.html.en,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- ssi.html.en	2001/09/05 01:26:24	1.6
  +++ ssi.html.en	2001/09/22 19:18:26	1.7
  @@ -1,464 +1,490 @@
  -<!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/core.html.html#setoutputfilter">SetOutputFilter</a><br>
  -<a href=
  -"../mod/mod_setenvif.html#BrowserMatchNoCase">BrowserMatchNoCase</a><br>
  -
  - </td>
  -</tr>
  -</table>
  -
  -<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/core.html.html#setoutputfilter">SetOutputFilter</a><br />
  +         <a
  +        href="../mod/mod_setenvif.html#BrowserMatchNoCase">BrowserMatchNoCase</a><br />
  +         </td>
  +      </tr>
  +    </table>
  +
  +    <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
           &lt;FilesMatch "\.shtml(\..+)?$"&gt;
             SetOutputFilter INCLUDES
           &lt;/FilesMatch&gt;
   </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 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>
  +    <p>This element is also subject to <code>timefmt</code> format
  +    configurations.</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 />
   
  -<hr>
  -<h2><a name="additionalexamples">Additional examples</a></h2>
  +    <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 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>
  -
  +    <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>
   
  -<hr>
  -<h2><a name="whatelsecaniconfig">What else can I config?</a></h2>
  +    <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 />
   
  -<p>In addition to being able to <code>config</code> the time format,
  -you can also <code>config</code> two other things.</p>
  +    <h2><a id="whatelsecaniconfig" name="whatelsecaniconfig">What
  +    else can I config?</a></h2>
   
  -<p>Usually, when something goes wrong with your SSI directive, you get
  -the message</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>
   <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>
  -<h2><a name="conditionalexpressions">Conditional expressions</a></h2>
  +    <hr />
   
  -<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>
  +    <h2><a id="conditionalexpressions"
  +    name="conditionalexpressions">Conditional expressions</a></h2>
   
  -<p>The structure of this conditional construct is:</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>
   <pre>
           &lt;!--#if expr="test_condition" --&gt;
       &lt;!--#elif expr="test_condition" --&gt;
  @@ -466,25 +492,27 @@
       &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>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>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
  @@ -492,28 +520,27 @@
           Cool JavaScript code goes here
           &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>
   
  -<!--#include virtual="footer.html" -->
  -</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>
  +    <!--#include virtual="footer.html" -->
  +  </body>
   </html>
   
  
  
  

Mime
View raw message