config root man

Current Path : /usr/local/share/doc/apache/misc/

FreeBSD hs32.drive.ne.jp 9.1-RELEASE FreeBSD 9.1-RELEASE #1: Wed Jan 14 12:18:08 JST 2015 root@hs32.drive.ne.jp:/sys/amd64/compile/hs32 amd64
Upload File :
Current File : //usr/local/share/doc/apache/misc/FAQ.html

<!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 Server Frequently Asked Questions</title>
    
  </head>
  <!-- Background white, links blue (unvisited), navy (visited), red (active) -->

  <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
  vlink="#000080" alink="#FF0000">
        <div align="CENTER">
      <img src="../images/sub.gif" alt="[APACHE DOCUMENTATION]" />

      <h3>Apache HTTP Server Version 1.3</h3>
        <p><small><em>Is this the version you want?  For more recent
         versions, check our <a href="/docs/">documentation 
         index</a>.</em></small></p>

    </div>



    <h1 align="CENTER">Apache Server Frequently Asked
    Questions</h1>

    <p>The latest version of this FAQ is always available from the
    main Apache web site, at &lt;<a
    href="http://httpd.apache.org/docs/misc/FAQ.html"
    rel="Help"><samp>http://httpd.apache.org/docs/misc/FAQ.html</samp></a>&gt;.</p>
    <!-- Notes about changes:                                           -->
    <!--  - If adding a relative link to another part of the            -->
    <!--    documentation, *do* include the ".html" portion.  There's a -->
    <!--    good chance that the user will be reading the documentation -->
    <!--    on his own system, which may not be configured for          -->
    <!--    multiviews.                                                 -->
    <!--  - When adding items, make sure they're put in the right place -->
    <!--    - verify that the numbering matches up.                     -->
    <!--  - *Don't* use <PRE></PRE> blocks - they don't appear          -->
    <!--    correctly in a reliable way when this is converted to text  -->
    <!--    with Lynx.  Use <DL><DD><CODE>xxx<BR>xx</CODE></DD></DL>    -->
    <!--    blocks inside a <P></P> instead.  This is necessary to get  -->
    <!--    the horizontal and vertical indenting right.                -->
    <!--  - Don't forget to include an HR tag after the last /P tag     -->
    <!--    but before the /LI in an item.                              -->

    <p>If you are reading a text-only version of this FAQ, you may
    find numbers enclosed in brackets (such as "[12]"). These refer
    to the list of reference URLs to be found at the end of the
    document. These references do not appear, and are not needed,
    for the hypertext version.</p>

    <h2>The Questions</h2>
    <!-- Stuff to Add:                                                  -->
    <!-- - can't bind to port 80                                        -->
    <!--   - permission denied                                          -->
    <!--   - address already in use                                     -->
    <!-- - mod_auth & passwd lines "user:pw:.*" - ++1st colon onward is -->
    <!--   treated as pw, not just ++1st to \-\-2nd.                    -->
    <!-- - SSL:                                                         -->
    <!--   - Can I use Apache-SSL for free in Canada?                   -->
    <!--   - Why can't I use Apache-SSL in the U.S.?                    -->
    <!-- - How can I found out how many visitors my site gets?          -->
    <!-- - How do I add a counter?                                      -->
    <!-- - How do I configure Apache as a proxy?                        -->
    <!-- - What browsers support HTTP/1.1?                              -->
    <!-- - What's the point of vhosts-by-name is there aren't any       -->
    <!--   HTTP/1.1 browsers?                                           -->
    <!-- - Is there an Apache for W95/WNT?                              -->
    <!-- - Why does Apache die when a vhost can't be DNS-resolved?      -->
    <!-- - Why do I get "send lost connection" messages in my error     -->
    <!--   log?                                                         -->
    <!--   - specifically consider .pdf files which seem to cause this  -->
    <!--     a lot when accessed via the plugin ... and also mention    -->
    <!--     how range-requests can cause bytes served < file size      -->
    <!-- - Why do directory indexes appear as garbage?  (A: -lucb)      -->
    <!-- - How do I add a footer to all pages offered by my server?     -->
    <!-- - Fix midi question; a bigger problem than midi vs. x-midi is  -->
    <!--   the simple fact that older versions of Apache (and new ones  -->
    <!--   that have been upgraded without upgrading the mime.types     -->
    <!--   file) don't have the type listed at all.                     -->
    <!-- - RewriteRule /~fraggle/* /cgi-bin/fraggle.pl does not work    -->
    <!-- - how do I disable authentication for a subdirectory?          -->
    <!--   (A: you can't but "Satisfy any; Allow from all" can be close -->
    <!-- - '400 malformed request' on Win32 might mean stale proxy; see -->
    <!--   PR #2300.                                                    -->
    <!-- - how do I tell what version of Apache I am running?           -->

    <ol type="A">
      








      

      <li value="1">
        <strong>Background</strong> 

        <ol>
          <li><a href="#what">What is Apache?</a></li>

          <li><a href="#why">How and why was Apache
          created?</a></li>

          <li><a href="#name">Why the name "Apache"?</a></li>

          <li><a href="#compare">OK, so how does Apache compare to
          other servers?</a></li>

          <li><a href="#tested">How thoroughly tested is
          Apache?</a></li>

          <li><a href="#future">What are the future plans for
          Apache?</a></li>

          <li><a href="#support">Whom do I contact for
          support?</a></li>

          <li><a href="#more">Is there any more information on
          Apache?</a></li>

          <li><a href="#where">Where can I get Apache?</a></li>

          <li><a href="#logo">May I use the Apache logo on my
          product or Web site?</a></li>
        </ol>
      </li>
      
      
    
    
  </body>
</html>


      








      

      <li value="2">
        <strong>General Technical Questions</strong> 

        <ol>
          <li><a href="#what2do">"Why can't I ...? Why won't ...
          work?" What to do in case of problems</a></li>

          <li><a href="#compatible">How compatible is Apache with
          my existing NCSA 1.3 setup?</a></li>

          <li><a href="#year2000">Is Apache Year 2000
          compliant?</a></li>

          <li><a href="#submit_patch">How do I submit a patch to
          the Apache Group?</a></li>

          <li><a href="#domination">Why has Apache stolen my
          favourite site's Internet address?</a></li>

          <li><a href="#apspam">Why am I getting spam mail from the
          Apache site?</a></li>

          <li><a href="#redist">May I include the Apache software
          on a CD or other package I'm distributing?</a></li>

          <li><a href="#zoom">What's the best hardware/operating
          system/... How do I get the most out of my Apache Web
          server?</a></li>

          <li><a href="#regex">What are "regular
          expressions"?</a></li>

          <li><a href="#binaries">Why isn't there a binary for my
          platform?</a></li>
        </ol>
      </li>
      
      
    
    
  </body>
</html>


      








      

      <li value="3">
        <strong>Building Apache</strong> 

        <ol>
          <li><a href="#bind8.1">Why do I get an error about an
          undefined reference to "<samp>__inet_ntoa</samp>" or
          other <samp>__inet_*</samp> symbols?</a></li>

          <li><a href="#cantbuild">Why won't Apache compile with my
          system's <samp>cc</samp>?</a></li>

          <li><a href="#linuxiovec">Why do I get complaints about
          redefinition of "<code>struct iovec</code>" when
          compiling under Linux?</a></li>

          <li><a href="#broken-gcc">I'm using gcc and I get some
          compilation errors, what is wrong?</a></li>

          <li><a href="#glibc-crypt">I'm using RedHat Linux 5.0, or
          some other <samp>glibc</samp>-based Linux system, and I
          get errors with the <code>crypt</code> function when I
          attempt to build Apache 1.2.</a></li>
        </ol>
      </li>
      
      
    
    
  </body>
</html>


      








      

      <li value="4">
        <strong>Error Log Messages and Problems Starting
        Apache</strong> 

        <ol>
          <li><a href="#setgid">Why do I get "<samp>setgid: Invalid
          argument</samp>" at startup?</a></li>

          <li><a href="#nodelay">Why am I getting "<samp>httpd:
          could not set socket option TCP_NODELAY</samp>" in my
          error log?</a></li>

          <li><a href="#peerreset">Why am I getting
          "<samp>connection reset by peer</samp>" in my error
          log?</a></li>

          <li><a href="#wheres-the-dump">The errorlog says Apache
          dumped core, but where's the dump file?</a></li>

          <li><a href="#linux-shmget">When I run it under Linux I
          get "shmget: function not found", what should I
          do?</a></li>

          <li><a href="#nfslocking">Server hangs, or fails to
          start, and/or error log fills with "<samp>fcntl:
          F_SETLKW: No record locks available</samp>" or similar
          messages</a></li>

          <li><a href="#aixccbug">Why am I getting "<samp>Expected
          &lt;/Directory&gt; but saw &lt;/Directory&gt;</samp>"
          when I try to start Apache?</a></li>

          <li><a href="#redhat">I'm using RedHat Linux and I have
          problems with httpd dying randomly or not restarting
          properly</a></li>

          <li><a href="#stopping">I upgraded from an Apache version
          earlier than 1.2.0 and suddenly I have problems with
          Apache dying randomly or not restarting properly</a></li>

          <li><a href="#setservername">When I try to start Apache
          from a DOS window, I get a message like "<samp>Cannot
          determine host name. Use ServerName directive to set it
          manually.</samp>" What does this mean?</a></li>

          <li><a href="#ws2_32dll">When I try to start Apache for
          Windows, I get a message like "<samp>Unable To Locate
          WS2_32.DLL...</samp>". What should I do?</a></li>

          <li><a href="#WSADuplicateSocket">Apache for Windows does
          not start. Error log contains this message "<samp>[crit]
          (10045) The attempted operation is not supported for the
          type of object referenced: Parent: WSADuplicateSocket
          failed for socket ###</samp>". What does this
          mean?</a></li>

          <li><a href="#err1067">When I try to start Apache on
          Windows, I get a message like "<code>System error 1067
          has occurred. The process terminated
          unexpectedly.</code>" What does this mean?</a></li>

          <li><a href="#suseFDN">On a SuSE Linux system, I try and 
          configure access control using basic authentication.
	  Although I follow the example exactly, authentication
	  fails, and an error message "<code>admin: not a valid
	  FDN: ....</code>" is logged.</a></li>

          <li><a href="#codered">Why do I have weird entries in my
          logs asking for <code>default.ida</code> and
          <code>cmd.exe</code>?</a></li>

          <li><a href="#restart">Why am I getting server restart
          messages periodically, when I did not restart the
          server?</a></li>

          <li><a href="#modulemagic">Why am I getting &quot;module
          <em>module-name</em> is not compatible with this version of
          Apache&quot; messages in my error log?</a></li>

        </ol>
      </li>
      
      
    
    
  </body>
</html>


      








      

      <li value="5">
        <strong>Configuration Questions</strong> 

        <ol>
          <li><a href="#fdlim">Why can't I run more than
          &lt;<em>n</em>&gt; virtual hosts?</a></li>

          <li><a href="#freebsd-setsize">Can I increase
          <samp>FD_SETSIZE</samp> on FreeBSD?</a></li>

          <li><a href="#errordoc401">Why doesn't my
          <code>ErrorDocument 401</code> work?</a></li>

          <li><a href="#cookies1">Why does Apache send a cookie on
          every response?</a></li>

          <li><a href="#cookies2">Why don't my cookies work, I even
          compiled in <samp>mod_cookies</samp>?</a></li>

          <li><a href="#jdk1-and-http1.1">Why do my Java app[let]s
          give me plain text when I request an URL from an Apache
          server?</a></li>

          <li><a href="#midi">How do I get Apache to send a MIDI
          file so the browser can play it?</a></li>

          <li><a href="#addlog">How do I add browsers and referrers
          to my logs?</a></li>

          <li><a href="#set-servername">Why does accessing
          directories only work when I include the trailing "/"
          (<em>e.g.</em>,&nbsp;<samp>http://foo.domain.com/~user/</samp>)
          but not when I omit it
          (<em>e.g.</em>,&nbsp;<samp>http://foo.domain.com/~user</samp>)?</a></li>

          <li><a href="#no-info-directives">Why doesn't mod_info
          list any directives?</a></li>

          <li><a href="#namevhost">I upgraded to Apache 1.3 and now
          my virtual hosts don't work!</a></li>

          <li><a href="#redhat-htm">I'm using RedHat Linux and my
          .htm files are showing up as HTML source rather than
          being formatted!</a></li>

          <li><a href="#htaccess-work">My <code>.htaccess</code>
          files are being ignored.</a></li>

          <li><a href="#forbidden">Why do I get a
          "<samp>Forbidden</samp>" message whenever I try to access
          a particular directory?</a></li>

          <li><a href="#malfiles">Why do I get a
          "<samp>Forbidden/You don't have permission to access / on
          this server</samp>" message whenever I try to access my
          server?</a></li>

          <li><a href="#ie-ignores-mime">Why do my files appear
          correctly in Internet Explorer, but show up as source or
          trigger a save window with Netscape; or, Why doesn't
          Internet Explorer render my text/plain document
          correctly?</a></li>

	  <li><a href="#canonical-hostnames">My site is accessible
          under many different hostnames; how do I redirect clients
          so that they see only a single name?</a></li>

          <li><a href="#firewall">Why can I access my website from the
          server or from my local network, but I can't access it from
          elsewhere on the Internet?</a></li>

	  <li><a href="#indexes">How do I turn automatic directory listings
	  on or off?</a></li>

         <li><a href="#options">Why do my Options directives not have
         the desired effect?</a></li>

         <li><a href="#serverheader">How can I change the information
         that Apache returns about itself in the headers?</a></li>

         <li><a href="#proxyscan">Why do I see requests for other sites
         appearing in my log files?</a></li>

        </ol>
      </li>
      
      
    
    
  </body>
</html>


      








      

      <li value="6">
        <strong>Dynamic Content (CGI and SSI)</strong> 

        <ol>
          <li><a href="#CGIoutsideScriptAlias">How do I enable CGI
          execution in directories other than the
          ScriptAlias?</a></li>

          <li><a href="#premature-script-headers">What does it mean
          when my CGIs fail with "<samp>Premature end of script
          headers</samp>"?</a></li>

          <li><a href="#POSTnotallowed">Why do I keep getting
          "Method Not Allowed" for form POST requests?</a></li>

          <li><a href="#nph-scripts">How can I get my script's
          output without Apache buffering it? Why doesn't my server
          push work?</a></li>

          <li><a href="#cgi-spec">Where can I find the "CGI
          specification"?</a></li>

          <li><a href="#fastcgi">Why isn't FastCGI included with
          Apache any more?</a></li>

          <li><a href="#ssi-part-i">How do I enable SSI (parsed
          HTML)?</a></li>

          <li><a href="#ssi-part-ii">Why don't my parsed files get
          cached?</a></li>

          <li><a href="#ssi-part-iii">How can I have my script
          output parsed?</a></li>

          <li><a href="#ssi-part-iv">SSIs don't work for
          VirtualHosts and/or user home directories</a></li>

          <li><a href="#errordocssi">How can I use
          <code>ErrorDocument</code> and SSI to simplify customized
          error messages?</a></li>

          <li><a href="#remote-user-var">Why is the environment
          variable <samp>REMOTE_USER</samp> not set?</a></li>

          <li><a href="#user-cgi">How do I allow each of my user
          directories to have a cgi-bin directory?</a></li>
        </ol>
      </li>
      
      
    
    
  </body>
</html>


      








      

      <li value="7">
        <strong>Authentication and Access Restrictions</strong> 

        <ol>
          <li><a href="#dnsauth">Why isn't restricting access by
          host or domain name working correctly?</a></li>

          <li><a href="#user-authentication">How do I set up Apache
          to require a username and password to access certain
          documents?</a></li>

          <li><a href="#remote-auth-only">How do I set up Apache to
          allow access to certain documents only if a site is
          either a local site <em>or</em> the user supplies a
          password and username?</a></li>

          <li><a href="#authauthoritative">Why does my
          authentication give me a server error?</a></li>

          <li><a href="#auth-on-same-machine">Do I have to keep the
          (mSQL) authentication information on the same
          machine?</a></li>

          <li><a href="#msql-slow">Why is my mSQL authentication
          terribly slow?</a></li>

          <li><a href="#passwdauth">Can I use my
          <samp>/etc/passwd</samp> file for Web page
          authentication?</a></li>

          <li><a href="#prompted-twice">Why does Apache ask for my
          password twice before serving a file?</a></li>

          <li><a href="#image-theft">How can I prevent people from
          "stealing" the images from my web site?</a></li>

        </ol>
      </li>
      
      
    
    
  </body>
</html>


      








      

      <li value="8">
        <strong>URL Rewriting</strong> 

        <ol>
          <li><a href="#rewrite-more-config">Where can I find
          mod_rewrite rulesets which already solve particular
          URL-related problems?</a></li>

          <li><a href="#rewrite-article">Where can I find any
          published information about URL-manipulations and
          mod_rewrite?</a></li>

          <li><a href="#rewrite-complexity">Why is mod_rewrite so
          difficult to learn and seems so complicated?</a></li>

          <li><a href="#rewrite-dontwork">What can I do if my
          RewriteRules don't work as expected?</a></li>

          <li><a href="#rewrite-prefixdocroot">Why don't some of my
          URLs get prefixed with DocumentRoot when using
          mod_rewrite?</a></li>

          <li><a href="#rewrite-nocase">How can I make all my URLs
          case-insensitive with mod_rewrite?</a></li>

          <li><a href="#rewrite-virthost">Why are RewriteRules in
          my VirtualHost parts ignored?</a></li>

          <li><a href="#rewrite-envwhitespace">How can I use
          strings with whitespaces in RewriteRule's ENV
          flag?</a></li>
        </ol>
      </li>
      
      
    
    
  </body>
</html>


      








      

      <li value="9">
        <strong>Features</strong> 

        <ol>
          <li><a href="#proxy">Does or will Apache act as a Proxy
          server?</a></li>

          <li><a href="#multiviews">What are "multiviews"?</a></li>

          <li><a href="#putsupport">Why can't I publish to my
          Apache server using PUT on Netscape Gold and other
          programs?</a></li>

          <li><a href="#SSL-i">Why doesn't Apache include
          SSL?</a></li>

          <li><a href="#footer">How can I attach a footer to my
          documents without using SSI?</a></li>

          <li><a href="#search">Does Apache include a search
          engine?</a></li>

          <li><a href="#rotate">How can I rotate my log
          files?</a></li>

          <li><a href="#conditional-logging">How do I keep certain
          requests from appearing in my logs?</a></li>

          <li><a href="#dbinteg">Does Apache include any sort of
          database integration?</a></li>

          <li><a href="#asp">Can I use Active Server Pages (ASP)
          with Apache?</a></li>

          <li><a href="#java">Does Apache come with Java
          support?</a></li>
        </ol>
      </li>
      
      
    
    
  </body>
</html>


    </ol>
    <hr />

    <h2>The Answers</h2>
    








      
      
    

    <h3>A. Background</h3>

    <ol>
      <li>
        <a id="what" name="what"><strong>What is
        Apache?</strong></a> 

        <p>The Apache httpd server</p>

        <ul>
          <li>is a powerful, flexible, HTTP/1.1 compliant web
          server</li>

          <li>implements the latest protocols, including HTTP/1.1
          (RFC2616)</li>

          <li>is highly configurable and extensible with
          third-party modules</li>

          <li>can be customised by writing 'modules' using the
          Apache module API</li>

          <li>provides full source code and comes with an
          unrestrictive license</li>

          <li>runs on Windows NT/9x, Netware 5.x and above, OS/2, and most
          versions of Unix, as well as several other operating
          systems</li>

          <li>is actively being developed</li>

          <li>encourages user feedback through new ideas, bug
          reports and patches</li>

          <li>
            implements many frequently requested features,
            including:<br />
            <br />
             

            <dl>
              <dt>DBM databases for authentication</dt>

              <dd>allows you to easily set up password-protected
              pages with enormous numbers of authorized users,
              without bogging down the server.</dd>

              <dt>Customized responses to errors and problems</dt>

              <dd>Allows you to set up files, or even CGI scripts,
              which are returned by the server in response to
              errors and problems, e.g. setup a script to intercept
              <strong>500 Server Error</strong>s and perform
              on-the-fly diagnostics for both users and
              yourself.</dd>

              <dt>Multiple DirectoryIndex directives</dt>

              <dd>Allows you to say <code>DirectoryIndex index.html
              index.cgi</code>, which instructs the server to
              either send back <code>index.html</code> or run
              <code>index.cgi</code> when a directory URL is
              requested, whichever it finds in the directory.</dd>

              <dt>Unlimited flexible URL rewriting and
              aliasing</dt>

              <dd>Apache has no fixed limit on the numbers of
              Aliases and Redirects which may be declared in the
              config files. In addition, a powerful rewriting
              engine can be used to solve most URL manipulation
              problems.</dd>

              <dt>Content negotiation</dt>

              <dd>i.e. the ability to automatically serve clients
              of varying sophistication and HTML level compliance,
              with documents which offer the best representation of
              information that the client is capable of
              accepting.</dd>

              <dt>Virtual Hosts</dt>

              <dd>A much requested feature, sometimes known as
              multi-homed servers. This allows the server to
              distinguish between requests made to different IP
              addresses or names (mapped to the same machine).
              Apache also offers dynamically configurable
              mass-virtual hosting.</dd>

              <dt>Configurable Reliable Piped Logs</dt>

              <dd>You can configure Apache to generate logs in the
              format that you want. In addition, on most Unix
              architectures, Apache can send log files to a pipe,
              allowing for log rotation, hit filtering, real-time
              splitting of multiple vhosts into separate logs, and
              asynchronous DNS resolving on the fly.</dd>
            </dl>
          </li>
        </ul>
        <hr />
      </li>

      <li>
        <a id="why" name="why"><strong>How and why was Apache
        created?</strong></a> 

        <p>The <a
        href="http://httpd.apache.org/ABOUT_APACHE.html">About
        Apache</a> document explains how the Apache project evolved
        from its beginnings as an outgrowth of the NCSA httpd
        project to its current status as one of the fastest, most
        efficient, and most functional web servers in
        existence.</p>
        <hr />
      </li>

      <li>
        <a id="name" name="name"><strong>Why the name
        "Apache"?</strong></a> 

        <p>The name 'Apache' was chosen from respect for
        the Native American Indian tribe of Apache (Ind&eacute;),
        <a href="http://www.indians.org/welker/apache.htm">well-known
        for their superior skills in warfare strategy and their
        inexhaustible endurance</a>. For more information on the
        Apache Nation, we suggest searching
        <a href="http://www.google.com/search?q=Apache+Nation">Google</a>,
        <a href="http://www.northernlight.com/nlquery.fcg?qr=Apache+Nation"
          >Northernlight</a>, or
        <a href="http://www.alltheweb.com/cgi-bin/asearch?query=Apache+Nation"
          >AllTheWeb</a>.</p>

        <p>Secondarily, and more popularly (though incorrectly) accepted,
        it's a considered cute name which stuck. Apache is "<strong>A
        PA</strong>t<strong>CH</strong>y server". It was based on
        some existing code and a series of "patch files".</p>

        <hr />
      </li>

      <li>
        <a id="compare" name="compare"><strong>OK, so how does
        Apache compare to other servers?</strong></a> 

        <p>For an independent assessment, see <a
        href="http://webcompare.internet.com/">Web
        Compare</a>.</p>

        <p>Apache has been shown to be substantially faster, more
        stable, and more feature-full than many other web servers.
        Although certain commercial servers have claimed to surpass
        Apache's speed (it has not been demonstrated that any of
        these "benchmarks" are a good way of measuring WWW server
        speed at any rate), we feel that it is better to have a
        mostly-fast free server than an extremely-fast server that
        costs thousands of dollars. Apache is run on sites that get
        millions of hits per day, and they have experienced no
        performance difficulties.</p>
        <hr />
      </li>

      <li>
        <a id="tested" name="tested"><strong>How thoroughly tested
        is Apache?</strong></a> 

        <p>Apache is run on over 6 million Internet servers (as of
        February 2000). It has been tested thoroughly by both
        developers and users. The Apache Group maintains rigorous
        standards before releasing new versions of their server,
        and our server runs without a hitch on over one half of all
        WWW servers available on the Internet. When bugs do show
        up, we release patches and new versions as soon as they are
        available.</p>
        <hr />
      </li>

      <li>
        <a id="future" name="future"><strong>What are the future
        plans for Apache?</strong></a> 

        <ul>
          <li>to continue to be an "open source" no-charge-for-use
          HTTP server,</li>

          <li>to keep up with advances in HTTP protocol and web
          developments in general,</li>

          <li>to collect suggestions for fixes/improvements from
          its users,</li>

          <li>to respond to needs of large volume providers as well
          as occasional users.</li>
        </ul>
        <hr />
      </li>

      <li>
        <a id="support" name="support"><strong>Whom do I contact
        for support?</strong></a> 

        <p>There is no official support for Apache. None of the
        developers want to be swamped by a flood of trivial
        questions that can be resolved elsewhere. Bug reports and
        suggestions should be sent <em>via</em> <a
        href="http://httpd.apache.org/bug_report.html">the bug
        report page</a>. Other questions should be directed to the
        <a href="http://httpd.apache.org/userslist.html">Apache HTTP
        Server Users List</a> or the
        <a
        href="news:comp.infosystems.www.servers.unix">comp.infosystems.www.servers.unix</a>
        or <a
        href="news:comp.infosystems.www.servers.ms-windows">comp.infosystems.www.servers.ms-windows</a>
        newsgroup (as appropriate for the platform you use), where
        some of the Apache team lurk, in the company of many other
        httpd gurus who should be able to help.</p>

        <p>Commercial support for Apache is, however, available
        from a number of third parties.</p>
        <hr />
      </li>

      <li>
        <a id="more" name="more"><strong>Is there any more
        information available on Apache?</strong></a> 

        <p>Indeed there is. See the main <a
        href="http://httpd.apache.org/">Apache web site</a>. There
        is also a regular electronic publication called <a
        href="http://www.apacheweek.com/" rel="Help"><cite>Apache
        Week</cite></a> available. Links to relevant <cite>Apache
        Week</cite> articles are included below where appropriate.
        There are also some <a
        href="http://httpd.apache.org/info/apache_books.html">Apache-specific
        books</a> available.</p>
        <hr />
      </li>

      <li>
        <a id="where" name="where"><strong>Where can I get
        Apache?</strong></a> 

        <p>You can find out how to download the source for Apache
        at the project's <a href="http://httpd.apache.org/">main
        web page</a>.</p>
        <hr />
      </li>

      <li>
        <a id="logo" name="logo"><b>May I use the Apache logo on my
        product or Web site?</b></a> 

        <p>You may <b>NOT</b> use any original artwork from the
        Apache Software Foundation, nor make or use modified
        versions of such artwork, except under the following
        conditions:</p>

        <ul>
          <li>You may use the <a
          href="http://www.apache.org/images/apache_pb.gif">'Powered by Apache'
          graphic</a> on a Web site that is being served by the
          Apache HTTP server software.</li>

          <li>You may use the aforementioned 'Powered by Apache'
          graphic or the <a
          href="http://www.apache.org/images/asf_logo.gif">
          Apache Software Foundation logo</a> in product
          description and promotional material <b>IF and ONLY
          IF</b> such use can in no way be interpreted as anything
          other than an attribution. Using the Apache name and
          artwork in a manner that implies endorsement of a product
          or service is <b>strictly forbidden</b>.</li>
        </ul>
        <hr />
      </li>
    </ol>
    
    
  </body>
</html>


    








      
      
    

    <h3>B. General Technical Questions</h3>

    <ol>
      <li>
        <a id="what2do" name="what2do"><strong>"Why can't I ...?
        Why won't ... work?" What to do in case of
        problems</strong></a> 

        <p>If you are having trouble with your Apache server
        software, you should take the following steps:</p>

        <ol>
          <li>
            <strong>Check the errorlog!</strong> 

            <p>Apache tries to be helpful when it encounters a
            problem. In many cases, it will provide some details by
            writing one or messages to the server error log.
            Sometimes this is enough for you to diagnose &amp; fix
            the problem yourself (such as file permissions or the
            like). The default location of the error log is
            <samp>/usr/local/apache/logs/error_log</samp>, but see
            the <a
            href="../mod/core.html#errorlog"><samp>ErrorLog</samp></a>
            directive in your config files for the location on your
            server.</p>
          </li>

          <li>
            <strong>Check the <a
            href="http://httpd.apache.org/docs/misc/FAQ.html">FAQ</a>!</strong>
            

            <p>The latest version of the Apache Frequently-Asked
            Questions list can always be found at the main Apache
            web site.</p>
          </li>

          <li>
            <strong>Check the Apache bug database</strong> 

            <p>Most problems that get reported to The Apache Group
            are recorded in the <a
            href="http://bugs.apache.org/">bug database</a>.
            <em><strong>Please</strong> check the existing reports,
            open <strong>and</strong> closed, before adding
            one.</em> If you find that your issue has already been
            reported, please <em>don't</em> add a "me, too" report.
            If the original report isn't closed yet, we suggest
            that you check it periodically. You might also consider
            contacting the original submitter, because there may be
            an email exchange going on about the issue that isn't
            getting recorded in the database.</p>
          </li>

          <li>
            <strong>Ask in a user support group.</strong> 

            <p>A lot of common problems never make it to the bug
            database because there's already high Q&amp;A traffic
            about them in the <a
            href="http://httpd.apache.org/userslist.html">Users
            mailing list</a> or <a
            href="news:comp.infosystems.www.servers.unix"><samp>comp.infosystems.www.servers.unix</samp></a>
            and related newsgroups. These newsgroups are also
            available via <a
            href="http://groups.google.com/groups?group=comp.infosystems.www.servers">
            Google</a>. Many Apache users, and some of the developers,
            can be found roaming their virtual halls, so it is suggested
            that you seek wisdom there. The chances are good that
            you'll get a faster answer there than from the bug
            database, even if you <em>don't</em> see your question
            already posted.</p>
          </li>

          <li>
            <strong>If all else fails, report the problem in the
            bug database</strong> 

            <p>If you've gone through those steps above that are
            appropriate and have obtained no relief, then please
            <em>do</em> let The Apache Group know about the problem
            by <a
            href="http://httpd.apache.org/bug_report.html">logging
            a bug report</a>.</p>

            <p>If your problem involves the server crashing and
            generating a core dump, please include a backtrace (if
            possible). As an example,</p>

            <dl>
              <dd><code># cd <em>ServerRoot</em><br />
               # dbx httpd core<br />
               (dbx) where</code></dd>
            </dl>

            <p>(Substitute the appropriate locations for your
            <samp>ServerRoot</samp> and your <samp>httpd</samp> and
            <samp>core</samp> files. You may have to use
            <code>gdb</code> instead of <code>dbx</code>.)</p>
          </li>
        </ol>
        <hr />
      </li>

      <li>
        <a id="compatible" name="compatible"><strong>How compatible
        is Apache with my existing NCSA 1.3 setup?</strong></a> 

        <p>Apache attempts to offer all the features and
        configuration options of NCSA httpd 1.3, as well as many of
        the additional features found in NCSA httpd 1.4 and NCSA
        httpd 1.5.</p>

        <p>NCSA httpd appears to be moving toward adding
        experimental features which are not generally required at
        the moment. Some of the experiments will succeed while
        others will inevitably be dropped. The Apache philosophy is
        to add what's needed as and when it is needed.</p>

        <p>Friendly interaction between Apache and NCSA developers
        should ensure that fundamental feature enhancements stay
        consistent between the two servers for the foreseeable
        future.</p>
        <hr />
      </li>

      <li>
        <a id="year2000" name="year2000"><strong>Is Apache Year
        2000 compliant?</strong></a> 

        <p>Yes, Apache is Year 2000 compliant.</p>

        <p>Apache internally never stores years as two digits. On
        the HTTP protocol level RFC1123-style addresses are
        generated which is the only format a HTTP/1.1-compliant
        server should generate. To be compatible with older
        applications Apache recognizes ANSI C's
        <code>asctime()</code> and RFC850-/RFC1036-style date
        formats, too. The <code>asctime()</code> format uses
        four-digit years, but the RFC850 and RFC1036 date formats
        only define a two-digit year. If Apache sees such a date
        with a value less than 70 it assumes that the century is
        <samp>20</samp> rather than <samp>19</samp>.</p>

        <p>Although Apache is Year 2000 compliant, you may still
        get problems if the underlying OS has problems with dates
        past year 2000 (<em>e.g.</em>, OS calls which accept or
        return year numbers). Most (UNIX) systems store dates
        internally as signed 32-bit integers which contain the
        number of seconds since 1<sup>st</sup> January 1970, so the
        magic boundary to worry about is the year 2038 and not
        2000. But modern operating systems shouldn't cause any
        trouble at all.</p>

        <p>Users of Apache 1.2.x should upgrade to a current
        version of Apache 1.3 (see <a
        href="../new_features_1_3.html#misc">year-2000 improvements
        in Apache 1.3</a> for details).</p>

        <p>The Apache HTTP Server project is an open-source
        software product of the Apache Software Foundation. The
        project and the Foundation <b>cannot</b> offer legal
        assurances regarding any suitability of the software for
        your application. There are several commercial Apache
        support organizations and derivative server products
        available that may be able to stand behind the software and
        provide you with any assurances you may require. You may
        find links to some of these vendors at <samp>&lt;<a
        href="http://www.apache.org/info/support.cgi">http://www.apache.org/info/support.cgi</a>&gt;</samp>.</p>

        <p>The Apache HTTP server software is distributed with the
        following disclaimer, found in the software license:</p>
<pre>
   THIS SOFTWARE IS PROVIDED BY THE APACHE GROUP ``AS IS'' AND ANY
   EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
   IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
   PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE APACHE GROUP OR
   ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
   NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
   LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
   HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
   STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
   ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
   OF THE POSSIBILITY OF SUCH DAMAGE.
 
</pre>
        <hr />
      </li>

      <li>
        <a id="submit_patch" name="submit_patch"><strong>How do I
        submit a patch to the Apache Group?</strong></a> 

        <p>The Apache Group encourages patches from outside
        developers. There are 2 main "types" of patches: small
        bugfixes and general improvements. Bugfixes should be
        submitting using the Apache <a
        href="http://httpd.apache.org/bug_report.html">bug report
        page</a>. Improvements, modifications, and additions should
        follow the instructions below.</p>

        <p>In general, the first course of action is to be a member
        of the <samp>dev@httpd.apache.org</samp> mailing list. This
        indicates to the Group that you are closely following the
        latest Apache developments. Your patch file should be
        generated using either '<code>diff&nbsp;-c</code>' or
        '<code>diff&nbsp;-u</code>' against the latest CVS tree. To
        submit your patch, send email to
        <samp>dev@httpd.apache.org</samp> with a
        <samp>Subject:</samp> line that starts with
        <samp>[PATCH]</samp> and includes a general description of
        the patch. In the body of the message, the patch should be
        clearly described and then included at the end of the
        message. If the patch-file is long, you can note a URL to
        the file instead of the file itself. Use of MIME
        enclosures/attachments should be avoided.</p>

        <p>Be prepared to respond to any questions about your
        patches and possibly defend your code. If your patch
        results in a lot of discussion, you may be asked to submit
        an updated patch that incorporates all changes and
        suggestions.</p>
        <hr />
      </li>

      <li>
        <a id="domination" name="domination"><strong>Why has Apache
        stolen my favourite site's Internet address?</strong></a> 

        <p>The simple answer is: "It hasn't." This misconception is
        usually caused by the site in question having migrated to
        the Apache Web server software, but not having migrated the
        site's content yet. When Apache is installed, the default
        page that gets installed tells the Webmaster the
        installation was successful. The expectation is that this
        default page will be replaced with the site's real content.
        If it doesn't, complain to the Webmaster, not to the Apache
        project -- we just make the software and aren't responsible
        for what people do (or don't do) with it.</p>
        <hr />
      </li>

      <li>
        <a id="apspam" name="apspam"><strong>Why am I getting spam
        mail from the Apache site?</strong></a> 

        <p>The short answer is: "You aren't." Usually when someone
        thinks the Apache site is originating spam, it's because
        they've traced the spam to a Web site, and the Web site
        says it's using Apache. See the <a
        href="#domination">previous FAQ entry</a> for more details
        on this phenomenon.</p>

        <p>No marketing spam originates from the Apache site. The
        only mail that comes from the site goes only to addresses
        that have been <em>requested</em> to receive the mail.</p>
        <hr />
      </li>

      <li>
        <a id="redist" name="redist"><strong>May I include the
        Apache software on a CD or other package I'm
        distributing?</strong></a> 

        <p>The detailed answer to this question can be found in the
        Apache license, which is included in the Apache
        distribution in the file <code>LICENSE</code>. You can also
        find it on the Web at <samp>&lt;<a
        href="http://www.apache.org/LICENSE.txt">http://www.apache.org/LICENSE.txt</a>&gt;</samp>.</p>
        <hr />
      </li>

      <li>
        <a id="zoom" name="zoom"><strong>What's the best
        hardware/operating system/... How do I get the most out of
        my Apache Web server?</strong></a> 

        <p>Check out Dean Gaudet's <a
        href="perf-tuning.html">performance tuning page</a>.</p>
        <hr />
      </li>

      <li>
        <a id="regex" name="regex"><strong>What are "regular
        expressions"?</strong></a> 

        <p>Regular expressions are a way of describing a pattern -
        for example, "all the words that begin with the letter A"
        or "every 10-digit phone number" or even "Every sentence
        with two commas in it, and no capital letter Q". Regular
        expressions (aka "regex"s) are useful in Apache because
        they let you apply certain attributes against collections
        of files or resources in very flexible ways - for example,
        all .gif and .jpg files under any "images" directory could
        be written as /\/images\/.*(jpg|gif)$/.</p>

        <p>The best overview around is probably the one which comes
        with Perl. We implement a simple subset of Perl's regex
        support, but it's still a good way to learn what they mean.
        You can start by going to the <a
        href="http://www.perl.com/doc/manual/html/pod/perlre.html">CPAN
        page on regular expressions</a>, and branching out from
        there.</p> <hr />
      </li>

      <li>
        <a id="binaries" name="binaries"><b>Why isn't there a
        binary for my platform?</b></a> 

        <p>The developers make sure that the software builds and
        works correctly on the platforms available to them; this
        does <i>not</i> necessarily mean that <i>your</i> platform
        is one of them. In addition, the Apache HTTP server project
        is primarily source oriented, meaning that distributing
        valid and buildable source code is the purpose of a
        release, not making sure that there is a binary package for
        all of the supported platforms.</p>

        <p>If you don't see a kit for your platform listed in the
        binary distribution area (&lt;URL:<a
        href="http://httpd.apache.org/dist/httpd/binaries/">http://httpd.apache.org/dist/httpd/binaries/</a>&gt;),
        it means either that the platform isn't available to any of
        the developers, or that they just haven't gotten around to
        preparing a binary for it. As this is a voluntary project,
        they are under no obligation to do so. Users are encouraged
        and expected to build the software themselves.</p>

        <p>The sole exception to these practices is the Windows
        package. Unlike most Unix and Unix-like platforms, Windows
        systems do not come with a bundled software development
        environment, so we <i>do</i> prepare binary kits for
        Windows when we make a release. Again, however, it's a
        voluntary thing and only a limited number of the developers
        have the capability to build the InstallShield package, so
        the Windows release may lag somewhat behind the source
        release. This lag should be no more than a few days at
        most.</p>
        <hr />
      </li>
    </ol>
    
    
  </body>
</html>


    








      
      
    

    <h3>C. Building Apache</h3>

    <ol>
      <li>
        <a id="bind8.1" name="bind8.1"><strong>Why do I get an
        error about an undefined reference to
        "<samp>__inet_ntoa</samp>" or other <samp>__inet_*</samp>
        symbols?</strong></a> 

        <p>If you have installed <a
        href="http://www.isc.org/bind.html">BIND-8</a> then this is
        normally due to a conflict between your include files and
        your libraries. BIND-8 installs its include files and
        libraries <code>/usr/local/include/</code> and
        <code>/usr/local/lib/</code>, while the resolver that comes
        with your system is probably installed in
        <code>/usr/include/</code> and <code>/usr/lib/</code>. If
        your system uses the header files in
        <code>/usr/local/include/</code> before those in
        <code>/usr/include/</code> but you do not use the new
        resolver library, then the two versions will conflict.</p>

        <p>To resolve this, you can either make sure you use the
        include files and libraries that came with your system or
        make sure to use the new include files and libraries.
        Adding <code>-lbind</code> to the
        <code>EXTRA_LDFLAGS</code> line in your
        <samp>Configuration</samp> file, then re-running
        <samp>Configure</samp>, should resolve the problem. (Apache
        versions 1.2.* and earlier use <code>EXTRA_LFLAGS</code>
        instead.)</p>

        <p><strong>Note:</strong>As of BIND 8.1.1, the bind
        libraries and files are installed under
        <samp>/usr/local/bind</samp> by default, so you should not
        run into this problem. Should you want to use the bind
        resolvers you'll have to add the following to the
        respective lines:</p>

        <dl>
          <dd><code>EXTRA_CFLAGS=-I/usr/local/bind/include<br />
           EXTRA_LDFLAGS=-L/usr/local/bind/lib<br />
           EXTRA_LIBS=-lbind</code></dd>
        </dl>
        <hr />
      </li>

      <li>
        <a id="cantbuild" name="cantbuild"><strong>Why won't Apache
        compile with my system's <samp>cc</samp>?</strong></a> 

        <p>If the server won't compile on your system, it is
        probably due to one of the following causes:</p>

        <ul>
          <li><strong>The <samp>Configure</samp> script doesn't
          recognize your system environment.</strong><br />
           This might be either because it's completely unknown or
          because the specific environment (include files, OS
          version, <em>et cetera</em>) isn't explicitly handled. If
          this happens, you may need to port the server to your OS
          yourself.</li>

          <li><strong>Your system's C compiler is
          garbage.</strong><br />
           Some operating systems include a default C compiler that
          is either not ANSI C-compliant or suffers from other
          deficiencies. The usual recommendation in cases like this
          is to acquire, install, and use <samp>gcc</samp>.</li>

          <li><strong>Your <samp>include</samp> files may be
          confused.</strong><br />
           In some cases, we have found that a compiler
          installation or system upgrade has left the C header
          files in an inconsistent state. Make sure that your
          include directory tree is in sync with the compiler and
          the operating system.</li>

          <li><strong>Your operating system or compiler may be out
          of revision.</strong><br />
           Software vendors (including those that develop operating
          systems) issue new releases for a reason; sometimes to
          add functionality, but more often to fix bugs that have
          been discovered. Try upgrading your compiler and/or your
          operating system.</li>
        </ul>

        <p>The Apache Group tests the ability to build the server
        on many different platforms. Unfortunately, we can't test
        all of the OS platforms there are. If you have verified
        that none of the above issues is the cause of your problem,
        and it hasn't been reported before, please submit a <a
        href="http://httpd.apache.org/bug_report.html">problem
        report</a>. Be sure to include <em>complete</em> details,
        such as the compiler &amp; OS versions and exact error
        messages.</p>
        <hr />
      </li>

      <li>
        <a id="linuxiovec" name="linuxiovec"><strong>Why do I get
        complaints about redefinition of "<code>struct
        iovec</code>" when compiling under Linux?</strong></a> 

        <p>This is a conflict between your C library includes and
        your kernel includes. You need to make sure that the
        versions of both are matched properly. There are two
        workarounds, either one will solve the problem:</p>

        <ul>
          <li>Remove the definition of <code>struct iovec</code>
          from your C library includes. It is located in
          <code>/usr/include/sys/uio.h</code>.
          <strong>Or,</strong></li>

          <li>Add <code>-DNO_WRITEV</code> to the
          <code>EXTRA_CFLAGS</code> line in your
          <samp>Configuration</samp> and reconfigure/rebuild. This
          hurts performance and should only be used as a last
          resort.</li>
        </ul>
        <hr />
      </li>

      <li>
        <a id="broken-gcc" name="broken-gcc"><strong>I'm using gcc
        and I get some compilation errors, what is
        wrong?</strong></a> 

        <p>GCC parses your system header files and produces a
        modified subset which it uses for compiling. This behavior
        ties GCC tightly to the version of your operating system.
        So, for example, if you were running IRIX 5.3 when you
        built GCC and then upgrade to IRIX 6.2 later, you will have
        to rebuild GCC. Similarly for Solaris 2.4, 2.5, or 2.5.1
        when you upgrade to 2.6. Sometimes you can type "gcc -v"
        and it will tell you the version of the operating system it
        was built against.</p>

        <p>If you fail to do this, then it is very likely that
        Apache will fail to build. One of the most common errors is
        with <code>readv</code>, <code>writev</code>, or
        <code>uio.h</code>. This is <strong>not</strong> a bug with
        Apache. You will need to re-install GCC.</p>
        <hr />
      </li>

      <li>
        <a id="glibc-crypt" name="glibc-crypt"><strong>I'm using
        RedHat Linux 5.0, or some other <samp>glibc</samp>-based
        Linux system, and I get errors with the <code>crypt</code>
        function when I attempt to build Apache 1.2.</strong></a> 

        <p><samp>glibc</samp> puts the <code>crypt</code> function
        into a separate library. Edit your
        <code>src/Configuration</code> file and set this:</p>

        <dl>
          <dd><code>EXTRA_LIBS=-lcrypt</code></dd>
        </dl>

        <p>Then re-run <samp>src/Configure</samp> and re-execute
        the make.</p>
        <hr />
      </li>
    </ol>
    
    
  </body>
</html>


    








      
      
    

    <h3>D. Error Log Messages and Problems Starting Apache</h3>

    <ol>
      <li>
        <a id="setgid" name="setgid"><strong>Why do I get
        "<samp>setgid: Invalid argument</samp>" at
        startup?</strong></a> 

        <p>Your <a
        href="../mod/core.html#group"><samp>Group</samp></a>
        directive (probably in <samp>conf/httpd.conf</samp>) needs
        to name a group that actually exists in the
        <samp>/etc/group</samp> file (or your system's equivalent).
        This problem is also frequently seen when a negative number
        is used in the <code>Group</code> directive (<em>e.g.</em>,
        "<code>Group&nbsp;#-1</code>"). Using a group name -- not
        group number -- found in your system's group database
        should solve this problem in all cases.</p>
        <hr />
      </li>

      <li>
        <a id="nodelay" name="nodelay"><strong>Why am I getting
        "<samp>httpd: could not set socket option
        TCP_NODELAY</samp>" in my error log?</strong></a> 

        <p>This message almost always indicates that the client
        disconnected before Apache reached the point of calling
        <code>setsockopt()</code> for the connection. It shouldn't
        occur for more than about 1% of the requests your server
        handles, and it's advisory only in any case.</p>
        <hr />
      </li>

      <li>
        <a id="peerreset" name="peerreset"><strong>Why am I getting
        "<samp>connection reset by peer</samp>" in my error
        log?</strong></a> 

        <p>This is a normal message and nothing about which to be
        alarmed. It simply means that the client canceled the
        connection before it had been completely set up - such as
        by the end-user pressing the "Stop" button. People's
        patience being what it is, sites with response-time
        problems or slow network links may experience this more
        than high capacity ones or those with large pipes to the
        network.</p>
        <hr />
      </li>

      <li>
        <a id="wheres-the-dump" name="wheres-the-dump"><strong>The
        errorlog says Apache dumped core, but where's the dump
        file?</strong></a> 

        <p>In Apache version 1.2, the error log message about
        dumped core includes the directory where the dump file
        should be located. However, many Unixes do not allow a
        process that has called <code>setuid()</code> to dump core
        for security reasons; the typical Apache setup has the
        server started as root to bind to port 80, after which it
        changes UIDs to a non-privileged user to serve
        requests.</p>

        <p>Dealing with this is extremely operating
        system-specific, and may require rebuilding your system
        kernel. Consult your operating system documentation or
        vendor for more information about whether your system does
        this and how to bypass it. If there <em>is</em> a
        documented way of bypassing it, it is recommended that you
        bypass it only for the <samp>httpd</samp> server process if
        possible.</p>

        <p>The canonical location for Apache's core-dump files is
        the <a href="../mod/core.html#serverroot">ServerRoot</a>
        directory. As of Apache version 1.3, the location can be
        set <em>via</em> the <a
        href="../mod/core.html#coredumpdirectory"><samp>CoreDumpDirectory</samp></a>
        directive to a different directory. Make sure that this
        directory is writable by the user the server runs as (as
        opposed to the user the server is <em>started</em> as).</p>
        <hr />
      </li>

      <li>
        <a id="linux-shmget" name="linux-shmget"><strong>When I run
        it under Linux I get "shmget: function not found", what
        should I do?</strong></a> 

        <p>Your kernel has been built without SysV IPC support. You
        will have to rebuild the kernel with that support enabled
        (it's under the "General Setup" submenu). Documentation for
        kernel building is beyond the scope of this FAQ; you should
        consult the <a
        href="http://www.redhat.com/mirrors/LDP/HOWTO/Kernel-HOWTO.html">
        Kernel HOWTO</a>, or the documentation provided with your
        distribution, or a <a
        href="http://www.redhat.com/mirrors/LDP/HOWTO/META-FAQ.html">
        Linux newsgroup/mailing list</a>. As a last-resort
        workaround, you can comment out the
        <code>#define&nbsp;USE_SHMGET_SCOREBOARD</code> definition
        in the <samp>LINUX</samp> section of
        <samp>src/conf.h</samp> and rebuild the server (prior to
        1.3b4, simply removing
        <code>#define&nbsp;HAVE_SHMGET</code> would have sufficed).
        This will produce a server which is slower and less
        reliable.</p>
        <hr />
      </li>

      <li>
        <a id="nfslocking" name="nfslocking"><strong>Server hangs,
        or fails to start, and/or error log fills with
        "<samp>fcntl: F_SETLKW: No record locks available</samp>"
        or similar messages</strong></a> 

        <p>These are symptoms of a fine locking problem, which
        usually means that the server is trying to use a
        synchronization file on an NFS filesystem.</p>

        <p>Because of its parallel-operation model, the Apache Web
        server needs to provide some form of synchronization when
        accessing certain resources. One of these synchronization
        methods involves taking out locks on a file, which means
        that the filesystem whereon the lockfile resides must
        support locking. In many cases this means it <em>can't</em>
        be kept on an NFS-mounted filesystem.</p>

        <p>To cause the Web server to work around the NFS locking
        limitations, include a line such as the following in your
        server configuration files:</p>

        <dl>
          <dd><code>LockFile /var/run/apache-lock</code></dd>
        </dl>

        <p>The directory should not be generally writable
        (<em>e.g.</em>, don't use <samp>/var/tmp</samp>). See the
        <a
        href="../mod/core.html#lockfile"><samp>LockFile</samp></a>
        documentation for more information.</p>
        <hr />
      </li>

      <li>
        <a id="aixccbug" name="aixccbug"><strong>Why am I getting
        "<samp>Expected &lt;/Directory&gt; but saw
        &lt;/Directory&gt;</samp>" when I try to start
        Apache?</strong></a> 

        <p>This is a known problem with certain versions of the AIX
        C compiler. IBM are working on a solution, and the issue is
        being tracked by <a
        href="http://bugs.apache.org/index/full/2312">problem
        report #2312</a>.</p>
        <hr />
      </li>

      <li>
        <a id="redhat" name="redhat"><strong>I'm using RedHat Linux
        and I have problems with httpd dying randomly or not
        restarting properly</strong></a> 

        <p>RedHat Linux versions 4.x (and possibly earlier) RPMs
        contain various nasty scripts which do not stop or restart
        Apache properly. These can affect you even if you're not
        running the RedHat supplied RPMs.</p>

        <p>If you're using the default install then you're probably
        running Apache 1.1.3, which is outdated. From RedHat's ftp
        site you can pick up a more recent RPM for Apache 1.2.x.
        This will solve one of the problems.</p>

        <p>If you're using a custom built Apache rather than the
        RedHat RPMs then you should <code>rpm -e apache</code>. In
        particular you want the mildly broken
        <code>/etc/logrotate.d/apache</code> script to be removed,
        and you want the broken <code>/etc/rc.d/init.d/httpd</code>
        (or <code>httpd.init</code>) script to be removed. The
        latter is actually fixed by the apache-1.2.5 RPMs but if
        you're building your own Apache then you probably don't
        want the RedHat files.</p>

        <p>We can't stress enough how important it is for folks,
        <em>especially vendors</em> to follow the <a
        href="../stopping.html">stopping Apache directions</a>
        given in our documentation. In RedHat's defense, the broken
        scripts were necessary with Apache 1.1.x because the Linux
        support in 1.1.x was very poor, and there were various race
        conditions on all platforms. None of this should be
        necessary with Apache 1.2 and later.</p>
        <hr />
      </li>

      <li>
        <a id="stopping" name="stopping"><strong>I upgraded from an
        Apache version earlier than 1.2.0 and suddenly I have
        problems with Apache dying randomly or not restarting
        properly</strong></a> 

        <p>You should read <a href="#redhat">the previous note</a>
        about problems with RedHat installations. It is entirely
        likely that your installation has start/stop/restart
        scripts which were built for an earlier version of Apache.
        Versions earlier than 1.2.0 had various race conditions
        that made it necessary to use <code>kill -9</code> at times
        to take out all the httpd servers. But that should not be
        necessary any longer. You should follow the <a
        href="../stopping.html">directions on how to stop and
        restart Apache</a>.</p>

        <p>As of Apache 1.3 there is a script
        <code>src/support/apachectl</code> which, after a bit of
        customization, is suitable for starting, stopping, and
        restarting your server.</p>
        <hr />
      </li>

      <li>
        <a id="setservername" name="setservername"><b>When I try to
        start Apache from a DOS window, I get a message like
        "<samp>Cannot determine host name. Use ServerName directive
        to set it manually.</samp>" What does this mean?</b></a> 

        <p>It means what it says; the Apache software can't
        determine the hostname of your system. Edit your
        <samp>conf\httpd.conf</samp> file, look for the string
        "ServerName", and make sure there's an uncommented
        directive such as</p>

        <dl>
          <dd><code>ServerName localhost</code></dd>
        </dl>

        <p>or</p>

        <dl>
          <dd><code>ServerName www.foo.com</code></dd>
        </dl>

        <p>in the file. Correct it if there one there with wrong
        information, or add one if you don't already have one.</p>

        <p>Also, make sure that your Windows system has DNS
        enabled. See the TCP/IP setup component of the Networking
        or Internet Options control panel.</p>

        <p>After verifying that DNS is enabled and that you have a
        valid hostname in your <samp>ServerName</samp> directive,
        try to start the server again.</p>
        <hr />
      </li>

      <li>
        <a id="ws2_32dll" name="ws2_32dll"><b>When I try to start
        Apache for Windows, I get a message like "<samp>Unable To
        Locate WS2_32.DLL...</samp>". What should I do?</b></a> 

        <p>Short answer: You need to install Winsock 2, available
        from <a
        href="http://www.microsoft.com/windows95/downloads/">http://www.microsoft.com/windows95/downloads/</a></p>

        <p>Detailed answer: Prior to version 1.3.9, Apache for
        Windows used Winsock 1.1. Beginning with version 1.3.9,
        Apache began using Winsock 2 features (specifically,
        WSADuplicateSocket()). WS2_32.DLL implements the Winsock 2
        API. Winsock 2 ships with Windows NT 4.0 and Windows 98.
        Some of the earlier releases of Windows 95 did not include
        Winsock 2.</p>
        <hr />
      </li>

      <li>
        <a id="WSADuplicateSocket"
        name="WSADuplicateSocket"><b>Apache for Windows does not
        start. Error log contains this message: "<samp>[crit]
        (10045) The attempted operation is not supported for the
        type of object referenced: Parent: WSADuplicateSocket
        failed for socket ###</samp>". What does this mean?</b></a>
        

        <p>We have seen this problem when Apache is run on systems
        along with Virtual Private Networking clients like Aventail
        Connect. Aventail Connect is a Layered Service Provider
        (LSP) that inserts itself, as a "shim," between the Winsock
        2 API and Window's native Winsock 2 implementation. The
        Aventail Connect shim does not implement
        WSADuplicateSocket, which is the cause of the failure.</p>

        <p>The shim is not unloaded when Aventail Connect is shut
        down. Once observed, the problem persists until the shim is
        either explicitly unloaded or the machine is rebooted.
        Another potential solution (not tested) is to add
        <code>apache.exe</code> to the Aventail "Connect Exclusion
        List".</p>

        <p>Apache is affected in a similar way by <em>any</em>
        firewall program that isn't correctly configured. Assure
        you exclude your Apache server ports (usually port 80) from
        the list of ports to block. Refer to your firewall
        program's documentation for the how-to.</p>
        <hr />
      </li>

      <li>
        <a id="err1067" name="err1067"><b>When I try to start
        Apache on Windows, I get a message like "<code>System error
        1067 has occurred. The process terminated
        unexpectedly</code>." What does this mean?</b></a> 

        <p>This message means that the Web server was unable to
        start correctly for one reason or another. To find out why,
        execute the following commands in a DOS window:</p>
<pre>
    c:
    cd "\Program Files\Apache Group\Apache"
    apache
 
</pre>

        <p>(If you don't get the prompt back, hit Control-C to
        cause Apache to exit.)</p>

        <p>The error you see will probably be one of those
        preceding this question in the FAQ.</p>

        <p>As of Apache 1.3.14, first check the Windows NT Event
        Log for Application errors using the Windows NT/2000 Event
        Viewer program. Any errors that occur prior to opening the
        Apache error log will be stored here, if Apache is run as a
        Service on NT or 2000. As with any error, also check your
        Apache error log.</p>
        <hr />
      </li>

      <li><a id="suseFDN" name="suseFDN"><b>On a SuSE Linux system, I try and 
          configure access control using basic authentication.
	  Although I follow the example exactly, authentication
	  fails, and an error message "<code>admin: not a valid
	  FDN: ....</code>" is logged.</b></a>

          <p>
	  In the SuSE distribution, additional 3rd party authentication
	  modules have been added and activated by default. These modules
	  interfere with the Apache standard modules and cause Basic
	  authentication to fail. Our recommendation is to comment all
	  those modules in <code>/etc/httpd/suse_addmodule.conf</code>
	  and <code>/etc/httpd/suse_loadmodule.conf</code> which are not
	  actually required for running your server.
          </p><hr />
      </li>

     <li><a id="codered" name="codered"><b>Why do I have weird entries in my
          logs asking for <code>default.ida</code> and
          <code>cmd.exe</code>?</b></a>
      
          <p>The host requesting pages from your website and creating
          those entries is a Windows machine running IIS that has been
          infected by an Internet worm such as Nimda or Code Red. You
          can safely ignore these error messages as they do not affect
          Apache.  ApacheWeek has an <a
          href="http://www.apacheweek.com/features/codered">article</a>
          with more information.</p><hr />
     </li>

    <li><a id="restart" name="restart"><b>Why am I getting server restart
    messages periodically, when I did not restart the server?</b></a>

          <p>Problem: You are noticing restart messages in your error log,
          periodically, when you know you did not restart the server
          yourself:</p>

<pre>
[Thu Jun  6 04:02:01 2002] [notice] SIGHUP received.  Attempting to restart
[Thu Jun  6 04:02:02 2002] [notice] Apache configured -- resuming normal operations
</pre>

          <p>Check your cron jobs to see when/if your server logs are being
          rotated. Compare the time of rotation to the error message time.
          If they are the same, you can somewhat safely assume that the 
          restart is due to your server logs being rotated.</p><hr />
     </li>

     <li><a id="modulemagic" name="modulemagic"><b>Why am I getting
          &quot;module <em>module-name</em> is not compatible with this version
          of Apache&quot; messages in my error log?</b></a>
      
          <p>Module Magic Number (MMN) is a constant defined in Apache
          source that is associated with binary compatibility of
          modules. It is changed when internal Apache structures,
          function calls and other significant parts of API change in
          such a way that binary compatibility cannot be guaranteed any
          more. On MMN change, all third party modules have to be at
          least recompiled, sometimes even slightly changed in order
          to work with the new version of Apache.</p>

          <p>If you're getting the above error messages, contact the
          vendor of the module for the new binary, or compile it if
          you have access to the source code.</p><hr />
     </li>

    </ol>
    
    
  </body>
</html>


    








      
      
    

    <h3>E. Configuration Questions</h3>

    <ol>
      <li>
        <a id="fdlim" name="fdlim"><strong>Why can't I run more
        than &lt;<em>n</em>&gt; virtual hosts?</strong></a> 

        <p>You are probably running into resource limitations in
        your operating system. The most common limitation is the
        <em>per</em>-process limit on <strong>file
        descriptors</strong>, which is almost always the cause of
        problems seen when adding virtual hosts. Apache often does
        not give an intuitive error message because it is normally
        some library routine (such as <code>gethostbyname()</code>)
        which needs file descriptors and doesn't complain
        intelligibly when it can't get them.</p>

        <p>Each log file requires a file descriptor, which means
        that if you are using separate access and error logs for
        each virtual host, each virtual host needs two file
        descriptors. Each <a
        href="../mod/core.html#listen"><samp>Listen</samp></a>
        directive also needs a file descriptor.</p>

        <p>Typical values for &lt;<em>n</em>&gt; that we've seen
        are in the neighborhood of 128 or 250. When the server
        bumps into the file descriptor limit, it may dump core with
        a SIGSEGV, it might just hang, or it may limp along and
        you'll see (possibly meaningful) errors in the error log.
        One common problem that occurs when you run into a file
        descriptor limit is that CGI scripts stop being executed
        properly.</p>

        <p>As to what you can do about this:</p>

        <ol>
          <li>Reduce the number of <a
          href="../mod/core.html#listen"><samp>Listen</samp></a>
          directives. If there are no other servers running on the
          machine on the same port then you normally don't need any
          Listen directives at all. By default Apache listens to
          all addresses on port 80.</li>

          <li>Reduce the number of log files. You can use <a
          href="../mod/mod_log_config.html"><samp>mod_log_config</samp></a>
          to log all requests to a single log file while including
          the name of the virtual host in the log file. You can
          then write a script to split the logfile into separate
          files later if necessary. Such a script is provided with
          the Apache 1.3 distribution in the
          <samp>src/support/split-logfile</samp> file.</li>

          <li>
            Increase the number of file descriptors available to
            the server (see your system's documentation on the
            <code>limit</code> or <code>ulimit</code> commands).
            For some systems, information on how to do this is
            available in the <a href="perf.html">performance
            hints</a> page. There is a specific note for <a
            href="#freebsd-setsize">FreeBSD</a> below. 

            <p>For Windows 95, try modifying your
            <samp>C:\CONFIG.SYS</samp> file to include a line
            like</p>

            <dl>
              <dd><code>FILES=300</code></dd>
            </dl>

            <p>Remember that you'll need to reboot your Windows 95
            system in order for the new value to take effect.</p>
          </li>

          <li>"Don't do that" - try to run with fewer virtual
          hosts</li>

          <li>Spread your operation across multiple server
          processes (using <a
          href="../mod/core.html#listen"><samp>Listen</samp></a>
          for example, but see the first point) and/or ports.</li>
        </ol>

        <p>Since this is an operating-system limitation, there's
        not much else available in the way of solutions.</p>

        <p>As of 1.2.1 we have made attempts to work around various
        limitations involving running with many descriptors. <a
        href="descriptors.html">More information is
        available.</a></p>
        <hr />
      </li>

      <li>
        <a id="freebsd-setsize" name="freebsd-setsize"><strong>Can
        I increase <samp>FD_SETSIZE</samp> on FreeBSD?</strong></a>
        

        <p>On versions of FreeBSD before 3.0, the
        <samp>FD_SETSIZE</samp> define defaults to 256. This means
        that you will have trouble usefully using more than 256
        file descriptors in Apache. This can be increased, but
        doing so can be tricky.</p>

        <p>If you are using a version prior to 2.2, you need to
        recompile your kernel with a larger
        <samp>FD_SETSIZE</samp>. This can be done by adding a line
        such as:</p>

        <dl>
          <dd><code>options FD_SETSIZE <em>nnn</em></code></dd>
        </dl>

        <p>to your kernel config file. Starting at version 2.2,
        this is no longer necessary.</p>

        <p>If you are using a version of 2.1-stable from after
        1997/03/10 or 2.2 or 3.0-current from before 1997/06/28,
        there is a limit in the resolver library that prevents it
        from using more file descriptors than what
        <samp>FD_SETSIZE</samp> is set to when libc is compiled. To
        increase this, you have to recompile libc with a higher
        <samp>FD_SETSIZE</samp>.</p>

        <p>In FreeBSD 3.0, the default <samp>FD_SETSIZE</samp> has
        been increased to 1024 and the above limitation in the
        resolver library has been removed.</p>

        <p>After you deal with the appropriate changes above, you
        can increase the setting of <samp>FD_SETSIZE</samp> at
        Apache compilation time by adding
        "<samp>-DFD_SETSIZE=<em>nnn</em></samp>" to the
        <samp>EXTRA_CFLAGS</samp> line in your
        <samp>Configuration</samp> file.</p>
        <hr />
      </li>

      <li>
        <a id="errordoc401" name="errordoc401"><strong>Why doesn't
        my <code>ErrorDocument 401</code> work?</strong></a> 

        <p>You need to use it with a URL in the form
        "<samp>/foo/bar</samp>" and not one with a method and
        hostname such as "<samp>http://host/foo/bar</samp>". See
        the <a
        href="../mod/core.html#errordocument"><samp>ErrorDocument</samp></a>
        documentation for details. This was incorrectly documented
        in the past.</p>
        <hr />
      </li>

      <li>
        <a id="cookies1" name="cookies1"><strong>Why does Apache
        send a cookie on every response?</strong></a> 

        <p>Apache does <em>not</em> automatically send a cookie on
        every response, unless you have re-compiled it with the <a
        href="../mod/mod_usertrack.html"><samp>mod_usertrack</samp></a>
        module, and specifically enabled it with the <a
        href="../mod/mod_usertrack.html#cookietracking"><samp>CookieTracking</samp></a>
        directive. This module has been in Apache since version
        1.2. This module may help track users, and uses cookies to
        do this. If you are not using the data generated by
        <samp>mod_usertrack</samp>, do not compile it into
        Apache.</p>
        <hr />
      </li>

      <li>
        <a id="cookies2" name="cookies2"><strong>Why don't my
        cookies work, I even compiled in
        <samp>mod_cookies</samp>?</strong></a> 

        <p>Firstly, you do <em>not</em> need to compile in
        <samp>mod_cookies</samp> in order for your scripts to work
        (see the <a href="#cookies1">previous question</a> for more
        about <samp>mod_cookies</samp>). Apache passes on your
        <samp>Set-Cookie</samp> header fine, with or without this
        module. If cookies do not work it will be because your
        script does not work properly or your browser does not use
        cookies or is not set-up to accept them.</p>
        <hr />
      </li>

      <li>
        <a id="jdk1-and-http1.1"
        name="jdk1-and-http1.1"><strong>Why do my Java app[let]s
        give me plain text when I request an URL from an Apache
        server?</strong></a> 

        <p>As of version 1.2, Apache is an HTTP/1.1 (HyperText
        Transfer Protocol version 1.1) server. This fact is
        reflected in the protocol version that's included in the
        response headers sent to a client when processing a
        request. Unfortunately, low-level Web access classes
        included in the Java Development Kit (JDK) version 1.0.2
        expect to see the version string "HTTP/1.0" and do not
        correctly interpret the "HTTP/1.1" value Apache is sending
        (this part of the response is a declaration of what the
        server can do rather than a declaration of the dialect of
        the response). The result is that the JDK methods do not
        correctly parse the headers, and include them with the
        document content by mistake.</p>

        <p>This is definitely a bug in the JDK 1.0.2 foundation
        classes from Sun, and it has been fixed in version 1.1.
        However, the classes in question are part of the virtual
        machine environment, which means they're part of the Web
        browser (if Java-enabled) or the Java environment on the
        client system - so even if you develop <em>your</em>
        classes with a recent JDK, the eventual users might
        encounter the problem. The classes involved are replaceable
        by vendors implementing the Java virtual machine
        environment, and so even those that are based upon the
        1.0.2 version may not have this problem.</p>

        <p>In the meantime, a workaround is to tell Apache to
        "fake" an HTTP/1.0 response to requests that come from the
        JDK methods; this can be done by including a line such as
        the following in your server configuration files:</p>

        <dl>
          <dd><code>BrowserMatch Java1.0 force-response-1.0<br />
           BrowserMatch JDK/1.0 force-response-1.0</code></dd>
        </dl>

        <p>More information about this issue can be found in the <a
        href="http://httpd.apache.org/info/jdk-102.html"><cite>Java
        and HTTP/1.1</cite></a> page at the Apache web site.</p>
        <hr />
      </li>

      <li>
        <a id="midi" name="midi"><strong>How do I get Apache to
        send a MIDI file so the browser can play it?</strong></a> 

        <p>Even though the registered MIME type for MIDI files is
        <samp>audio/midi</samp>, some browsers are not set up to
        recognize it as such; instead, they look for
        <samp>audio/x-midi</samp>. There are two things you can do
        to address this:</p>

        <ol>
          <li>Configure your browser to treat documents of type
          <samp>audio/midi</samp> correctly. This is the type that
          Apache sends by default. This may not be workable,
          however, if you have many client installations to change,
          or if some or many of the clients are not under your
          control.</li>

          <li>
            Instruct Apache to send a different
            <samp>Content-type</samp> header for these files by
            adding the following line to your server's
            configuration files: 

            <dl>
              <dd><code>AddType audio/x-midi .mid .midi
              .kar</code></dd>
            </dl>

            <p>Note that this may break browsers that <em>do</em>
            recognize the <samp>audio/midi</samp> MIME type unless
            they're prepared to also handle
            <samp>audio/x-midi</samp> the same way.</p>
          </li>
        </ol>
        <hr />
      </li>

      <li>
        <a id="addlog" name="addlog"><strong>How do I add browsers
        and referrers to my logs?</strong></a> 

        <p>Apache provides a couple of different ways of doing
        this. The recommended method is to compile the <a
        href="../mod/mod_log_config.html"><samp>mod_log_config</samp></a>
        module into your configuration and use the <a
        href="../mod/mod_log_config.html#customlog"><samp>CustomLog</samp></a>
        directive.</p>

        <p>You can either log the additional information in files
        other than your normal transfer log, or you can add them to
        the records already being written. For example:</p>

        <p>
        <code>CustomLog&nbsp;logs/access_log&nbsp;"%h&nbsp;%l&nbsp;%u&nbsp;%t&nbsp;\"%r\"&nbsp;%s&nbsp;%b&nbsp;\"%{Referer}i\"&nbsp;\"%{User-Agent}i\""</code></p>

        <p>This will add the values of the <samp>User-agent:</samp>
        and <samp>Referer:</samp> headers, which indicate the
        client and the referring page, respectively, to the end of
        each line in the access log.</p>

        <p>You may want to check out the <cite>Apache Week</cite>
        article entitled: "<a
        href="http://www.apacheweek.com/features/logfiles"
        rel="Help"><cite>Gathering Visitor Information: Customizing
        Your Logfiles</cite></a>".</p>
        <hr />
      </li>

      <li>
        <a id="set-servername" name="set-servername"><strong>Why
        does accessing directories only work when I include the
        trailing "/"
        (<em>e.g.</em>,&nbsp;<samp>http://foo.domain.com/~user/</samp>)
        but not when I omit it
        (<em>e.g.</em>,&nbsp;<samp>http://foo.domain.com/~user</samp>)?</strong></a>
        

        <p>When you access a directory without a trailing "/",
        Apache needs to send what is called a redirect to the
        client to tell it to add the trailing slash. If it did not
        do so, relative URLs would not work properly. When it sends
        the redirect, it needs to know the name of the server so
        that it can include it in the redirect. There are two ways
        for Apache to find this out; either it can guess, or you
        can tell it. If your DNS is configured correctly, it can
        normally guess without any problems. If it is not, however,
        then you need to tell it.</p>

        <p>Add a <a
        href="../mod/core.html#servername">ServerName</a> directive
        to the config file to tell it what the domain name of the
        server is.</p>

        <p>The other thing that can occasionally cause this symptom is a
        misunderstanding of the <a
        href="../mod/mod_alias.html#alias">Alias</a> directive,
        resulting in an alias working with a trailing slash, and not 
        without one. The <code>Alias</code> directive is very literal,
        and aliases what you tell it to. Consider the following
        example:</p>

        <pre>
        Alias /example/ /home/www/example/
        </pre>

        <p>The above directive creates an alias for URLs starting with
        <code>/example/</code>, but does <em>not</em> alias URLs
        starting with <code>/example</code>. That is to say, a URL such
        as <code>http://servername.com/example/</code> will get the
        desired content, but a URL such as
        <code>http://servername.com/example</code> will result in a
        "file not found" error.</p>

        <p>The following <code>Alias</code>, on the other hand, will
        work for both cases:</p>

        <pre>
        Alias /example /home/www/example
        </pre>

        <hr />
      </li>

      <li>
        <a id="no-info-directives"
        name="no-info-directives"><strong>Why doesn't mod_info list
        any directives?</strong></a> 

        <p>The <a
        href="../mod/mod_info.html"><samp>mod_info</samp></a>
        module allows you to use a Web browser to see how your
        server is configured. Among the information it displays is
        the list modules and their configuration directives. The
        "current" values for the directives are not necessarily
        those of the running server; they are extracted from the
        configuration files themselves at the time of the request.
        If the files have been changed since the server was last
        reloaded, the display will not match the values actively in
        use. If the files and the path to the files are not
        readable by the user as which the server is running (see
        the <a href="../mod/core.html#user"><samp>User</samp></a>
        directive), then <samp>mod_info</samp> cannot read them in
        order to list their values. An entry <em>will</em> be made
        in the error log in this event, however.</p>
        <hr />
      </li>

      <li>
        <a id="namevhost" name="namevhost"><strong>I upgraded to
        Apache 1.3 and now my virtual hosts don't
        work!</strong></a> 

        <p>In versions of Apache prior to 1.3b2, there was a lot of
        confusion regarding address-based virtual hosts and
        (HTTP/1.1) name-based virtual hosts, and the rules
        concerning how the server processed
        <samp>&lt;VirtualHost&gt;</samp> definitions were very
        complex and not well documented.</p>

        <p>Apache 1.3b2 introduced a new directive, <a
        href="../mod/core.html#namevirtualhost"><samp>NameVirtualHost</samp></a>,
        which simplifies the rules quite a bit. However, changing
        the rules like this means that your existing name-based
        <samp>&lt;VirtualHost&gt;</samp> containers probably won't
        work correctly immediately following the upgrade.</p>

        <p>To correct this problem, add the following line to the
        beginning of your server configuration file, before
        defining any virtual hosts:</p>

        <dl>
          <dd><code>NameVirtualHost <em>n.n.n.n</em></code></dd>
        </dl>

        <p>Replace the "<samp>n.n.n.n</samp>" with the IP address
        to which the name-based virtual host names resolve; if you
        have multiple name-based hosts on multiple addresses,
        repeat the directive for each address.</p>

        <p>Make sure that your name-based
        <samp>&lt;VirtualHost&gt;</samp> blocks contain
        <samp>ServerName</samp> and possibly
        <samp>ServerAlias</samp> directives so Apache can be sure
        to tell them apart correctly.</p>

        <p>Please see the <a href="../vhosts/">Apache Virtual Host
        documentation</a> for further details about
        configuration.</p>
        <hr />
      </li>

      <li>
        <a id="redhat-htm" name="redhat-htm"><strong>I'm using
        RedHat Linux and my .htm files are showing up as HTML
        source rather than being formatted!</strong></a> 

        <p>RedHat messed up and forgot to put a content type for
        <code>.htm</code> files into <code>/etc/mime.types</code>.
        Edit <code>/etc/mime.types</code>, find the line containing
        <code>html</code> and add <code>htm</code> to it. Then
        restart your httpd server:</p>

        <dl>
          <dd><code>kill -HUP `cat /var/run/httpd.pid`</code></dd>
        </dl>

        <p>Then <strong>clear your browsers' caches</strong>. (Many
        browsers won't re-examine the content type after they've
        reloaded a page.)</p>
        <hr />
      </li>

      <li>
        <a id="htaccess-work" name="htaccess-work"><strong>My
        <code>.htaccess</code> files are being
        ignored.</strong></a> 

        <p>This is almost always due to your <a
        href="../mod/core.html#allowoverride">AllowOverride</a>
        directive being set incorrectly for the directory in
        question. If it is set to <code>None</code> then .htaccess
        files will not even be looked for. If you do have one that
        is set, then be certain it covers the directory you are
        trying to use the .htaccess file in. This is normally
        accomplished by ensuring it is inside the proper <a
        href="../mod/core.html#directory">Directory</a>
        container.</p>
        <hr />
      </li>

      <li>
        <a id="forbidden" name="forbidden"><strong>Why do I get a
        "<samp>Forbidden</samp>" message whenever I try to access a
        particular directory?</strong></a> 

        <p>This message is generally caused because either</p>

        <ul>
          <li>The underlying file system permissions do not allow
          the User/Group under which Apache is running to access
          the necessary files; or</li>

          <li>The Apache configuration has some access restrictions
          in place which forbid access to the files.</li>
        </ul>

        <p>You can determine which case applies to your situation
        by checking the error log.</p>

        <p>In the case where file system permission are at fault,
        remember that not only must the directory and files in
        question be readable, but also all parent directories must
        be at least searchable (i.e., <i>chmod +x /directory/path</i>)
        by the web server in order for the content to be accessible.</p>
        <hr />
      </li>

      <li>
        <a id="malfiles" name="malfiles"><b>Why do I get a
        "<samp>Forbidden/You don't have permission to access / on
        this server</samp>" message whenever I try to access my
        server?</b></a> 

        <p>Search your <code>conf/httpd.conf</code> file for this
        exact string: <code>&lt;Files ~&gt;</code>. If you find it,
        that's your problem -- that particular &lt;Files&gt;
        container is malformed. Delete it or replace it with
        <code>&lt;Files ~ "^\.ht"&gt;</code> and restart your
        server and things should work as expected.</p>

        <p>This error appears to be caused by a problem with the
        version of linuxconf distributed with Redhat 6.x. It may
        reappear if you use linuxconf again.</p>

        <p>If you don't find this string, check out the <a
        href="#forbidden">previous question</a>.</p>
        <hr />
      </li>

      <li>
        <a id="ie-ignores-mime" name="ie-ignores-mime"><strong>Why
        do my files appear correctly in Internet Explorer, but show
        up as source or trigger a save window with
        Netscape; or, Why doesn't Internet Explorer render
        my text/plain document correctly?</strong></a> 

        <p>MS Internet Explorer (MSIE) and Netscape handle mime type
        detection in different ways, and therefore will display the
        document differently. In particular, IE sometimes relies on
        the file extension or the contents of the file to determine
        the mime type. This can happen when the server specifies a
        mime type of <code>application/octet-stream</code> or
        <code>text/plain</code>.  This behavior violates the the HTTP
        standard and makes it impossible to deliver plain text
        documents to MSIE clients in some cases.  More details are
        available on MSIE's mime type detection behavior in an <a
        href="http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp">
        MSDN article</a> and a <a
        href="http://ppewww.ph.gla.ac.uk/~flavell/www/content-type.html">note</a>
        by Alan J. Flavell.</p>

        <p>The best you can do as a server administrator is to
        accurately configure the mime type of your documents by editing
        the <code>mime.types</code> file or using an <a
        href="../mod/mod_mime.html#addtype"><code>AddType</code></a>
        directive in the Apache configuration files.  In some cases,
        you may be able to fool MSIE into rendering text/plain documents
        correctly by assuring they have a <code>.txt</code> filename
        extension, but this will not work if MSIE thinks the content
        looks like another file type.
</p> <hr />
      </li>
      <li>
	<a name="canonical-hostnames"><strong>My site is accessible
        under many different hostnames; how do I redirect clients
        so that they see only a single name?</strong></a>

        <p>Many sites map a variety of hostnames to the same content.
        For example, <code>www.example.com</code>,
        <code>example.com</code> and <code>www.example.net</code> may
        all refer to the same site.  It is best to make sure that,
        regardless of the name clients use to access the site, they
        will be redirected to a single, canonical hostname.  This
        makes the site easier to maintain and assures that there will
        be only one version of the site in proxy caches and search
        engines.</p>

        <p>There are two techniques to implement canonical hostnames:</p>

        <ol>
          <li>Use <a href="../mod/mod_rewrite.html">mod_rewrite</a>
          as described in the "Canonical Hostnames" section of the
          <a href="rewriteguide.html">URL Rewriting Guide</a>.</li>

          <li>Use <a href="../vhosts/name-based.html">name-based
          virtual hosting</a>:

<blockquote><code>
NameVirtualHost *<br />
<br />
&lt;VirtualHost *&gt;<br />
&nbsp;&nbsp;ServerName www.example.net<br />
&nbsp;&nbsp;ServerAlias example.com<br />
&nbsp;&nbsp;Redirect permanent / http://www.example.com/<br />
&lt;/VirtualHost&gt;<br />
<br />
&lt;VirtualHost *&gt;<br />
&nbsp;&nbsp;ServerName www.example.com<br />
&nbsp;&nbsp;DocumentRoot /usr/local/apache/htdocs<br />
&lt;/VirtualHost&gt;
</code></blockquote>
          </li></ol>
        <hr /></li>

         <li><a id="firewall" name="firewall"><strong>Why can I access my
         website from the server or from my local network, but I
         can't access it from elsewhere on the Internet?</strong></a>

         <p>There are many possible reasons for this, and almost all
         of them are related to the configuration of your network, not
         the configuration of the Apache HTTP Server.  One of the most
         common problems is that a firewall blocks access to the
         default HTTP port 80.  In particular, many consumer ISPs
         block access to this port.  You can see if this is the case
         by changing any <code>Port</code> and <code>Listen</code>
         directives in <code>httpd.conf</code> to use port 8000 and
         then request your site using
         <code>http://yourhost.example.com:8000/</code>.  (Of course,
         a very restrictive firewall may block this port as well.)</p>

        <hr /></li>

         <li><a id="indexes" name="indexes"><strong>How do I turn automatic
         directory listings on or off?</strong></a>

         <p>If a client requests a URL that designates a directory and
         the directory does not contain a filename that matches the <a
         href="../mod/mod_dir.html#directoryindex">DirectoryIndex</a>
         directive, then <a
         href="../mod/mod_autoindex.html">mod_autoindex</a> can be
         configured to present a listing of the directory contents.</p>

         <p>To turn on automatic directory indexing, find the 
         <a href="../mod/core.html#options">Options</a> directive that
         applies to the directory and add the <code>Indexes</code>
         keyword. For example:</p>

         <blockquote><code>
         &lt;Directory /path/to/directory&gt;<br />
         &nbsp;&nbsp;&nbsp;Options +Indexes<br />
         &lt;/Directory&gt;
         </code></blockquote>
         
         <p>To turn off automatic directory indexing, remove
         the <code>Indexes</code> keyword from the appropriate 
         <code>Options</code> line. To turn off directory listing
         for a particular subdirectory, you can use 
         <code>Options -Indexes</code>. For example:</p>

         <blockquote><code>
         &lt;Directory /path/to/directory&gt;<br />
         &nbsp;&nbsp;&nbsp;Options -Indexes<br />
         &lt;/Directory&gt;
         </code></blockquote>

       <hr /></li>

         <li><a id="options" name="options"><strong>Why do my Options
         directives not have the desired effect?</strong></a>

         <p>Directives placed in the configuration files are applied
         in a very particular order, as described by <a
         href="../sections.html">How Directory, Location, and Files
         sections work</a>.  In addition, each <a
         href="../mod/core.html#options">Options</a> directive has the
         effect of resetting the options to <code>none</code> before
         adding the specified options (unless only "+" and "-" options
         are used).  The consequence is that <code>Options</code> set
         in the main server or virtual host context (outside any
         directory, location, or files section) will usually have no
         effect, because they are overridden by more specific
         <code>Options</code> directives.  For example, in the following</p>

<blockquote><code>
&lt;Directory /usr/local/apache/htdocs&gt;<br />
&nbsp;&nbsp;&nbsp;&nbsp;Options Indexes<br />
&lt;/Directory&gt;<br />
Options Includes ExecCGI<br />
</code></blockquote>
    
         <p><code>Includes</code> and <code>ExecCGI</code> will be 
         <strong>off</strong> in the <code>/usr/local/apache/htdocs</code>
         directory.</p>

         <p>You can usually avoid problems by either finding the 
         <code>Options</code> directive that already applies to a 
         specific directory and changing it, or by putting your
         <code>Options</code> directive inside the most specific possible
         <code>&lt;Directory&gt;</code> section.</p>

       <hr /></li>


       <li><a id="serverheader" name="serverheader"><strong>How can I change
       the information that Apache returns about itself in the
       headers?</strong></a>

    <p>When a client connects to Apache, part of the information returned in
    the headers is the name "Apache" Additional information that can be sent
    is the version number, such as "1.3.26", the operating system, and a
    list of non-standard modules you have installed.</p>

    <p>For example:</p>

<blockquote><code>
Server: Apache/1.3.26 (Unix) mod_perl/1.26
</code></blockquote>

    <p>Frequently, people want to remove this information, under the mistaken
    understanding that this will make the system more secure. This is
    probably not the case, as the same exploits will likely be attempted
    regardless of the header information you provide.</p>

    <p>There are, however, two answers to this question: the correct answer,
    and the answer that you are probably looking for.</p>

    <p>The correct answer to this question is that you should use the
    ServerTokens directive to alter the quantity of information which is
    passed in the headers. Setting this directive to <code>Prod</code> will
    pass the least possible amount of information:</p>

<blockquote><code>
Server: Apache
</code></blockquote>

    <p>The answer you are probably looking for is how to make Apache lie 
    about what what it is, ie send something like:</p>

<blockquote><code>
Server: Bob's Happy HTTPd Server
</code></blockquote>

    <p>In order to do this, you will need to modify the Apache source code and
    rebuild Apache. This is not advised, as it is almost certain not to
    provide you with the added security you think that you are gaining. The
    exact method of doing this is left as an exercise for the reader, as we
    are not keen on helping you do something that is intrinsically a bad
    idea.</p>

    <hr /></li>

         <li><a id="proxyscan" name="proxyscan"><strong>Why do I see requests
         for other sites appearing in my log files?</strong></a>

         <p>A an access_log entry showing this situation could look
         like this:</p> 

         <blockquote><code> 63.251.56.142 - -
         [25/Jul/2002:12:48:04 -0700] "GET http://www.yahoo.com/
         HTTP/1.0" 200 1456 </code></blockquote>

         <p>The question is: why did a request for
         <code>www.yahoo.com</code> come to your server instead of
         Yahoo's server?  And why does the response have a status 
         code of 200 (success)?</p>

         <p>This is usually the result of malicious clients trying to
         exploit open proxy servers to access a website without
         revealing their true location.  If you find entries like this
         in your log, the first thing to do is to make sure you have
         properly configured your server not to proxy for unknown
         clients.  If you don't need to provide a proxy server at all,
         you should simply assure that the <a
         href="../mod/mod_proxy.html#proxyrequests">ProxyRequests</a>
         directive is <strong>not</strong> set <code>on</code>.
         If you do need to run a proxy server, then you must ensure
         that you <a href="../mod/mod_proxy.html#access">secure your
         server properly</a> so that only authorized clients can use
         it.</p>

         <p>If your server is configured properly, then the attempt to
         proxy through your server will fail.  If you see a status
         code of <code>404</code> (file not found) in the log, then
         you know that the request failed.  If you see a status code
         of <code>200</code> (success), that does not necessarily mean
         that the attempt to proxy succeeded.  RFC2616 section 5.1.2
         mandates that Apache must accept requests with absolute URLs
         in the request-URI, even for non-proxy requests.  Since
         Apache has no way to know all the different names that your
         server may be known under, it cannot simply reject hostnames
         it does not recognize.  Instead, it will serve requests for
         unknown sites locally by stripping off the hostname and using
         the default server or virtual host.  Therefore you can
         compare the size of the file (1456 in the above example) to
         the size of the corresponding file in your default server.
         If they are the same, then the proxy attempt failed, since a
         document from your server was delivered, not a document from
         <code>www.yahoo.com</code>.</p>

         <p>If you wish to prevent this type of request entirely, then
         you need to let Apache know what hostnames to accept and what
         hostnames to reject.  You do this by configuring name-virtual
         hosts, where the first listed host is the default host that
         will catch and reject unknown hostnames.  For example:</p>

<blockquote>
<pre>
NameVirtualHost *

&lt;VirtualHost *&gt;
  ServerName default.only
  &lt;Location /&gt;
    Order allow,deny
    Deny from all
  &lt;/Location&gt;
&lt;/VirtualHost&gt;

&lt;VirtualHost *&gt;
  ServerName realhost1.example.com
  ServerAlias alias1.example.com alias2.example.com
  DocumentRoot /path/to/site1
&lt;/VirtualHost&gt;

...
</pre>
</blockquote>
    <hr /></li>

    </ol>
    
    
  </body>
</html>


    








      
      
    

    <h3>F. Dynamic Content (CGI and SSI)</h3>

    <ol>
      <li>
        <a id="CGIoutsideScriptAlias"
        name="CGIoutsideScriptAlias"><strong>How do I enable CGI
        execution in directories other than the
        ScriptAlias?</strong></a> 

        <p>Apache recognizes all files in a directory named as a <a
        href="../mod/mod_alias.html#scriptalias"><samp>ScriptAlias</samp></a>
        as being eligible for execution rather than processing as
        normal documents. This applies regardless of the file name,
        so scripts in a ScriptAlias directory don't need to be
        named "<samp>*.cgi</samp>" or "<samp>*.pl</samp>" or
        whatever. In other words, <em>all</em> files in a
        ScriptAlias directory are scripts, as far as Apache is
        concerned.</p>

        <p>To persuade Apache to execute scripts in other
        locations, such as in directories where normal documents
        may also live, you must tell it how to recognize them - and
        also that it's okay to execute them. For this, you need to
        use something like the <a
        href="../mod/mod_mime.html#addhandler"><samp>AddHandler</samp></a>
        directive.</p>

        <ol>
          <li>
            In an appropriate section of your server configuration
            files, add a line such as 

            <dl>
              <dd><code>AddHandler cgi-script .cgi</code></dd>
            </dl>

            <p>The server will then recognize that all files in
            that location (and its logical descendants) that end in
            "<samp>.cgi</samp>" are script files, not
            documents.</p>
          </li>

          <li>Make sure that the directory location is covered by
          an <a
          href="../mod/core.html#options"><samp>Options</samp></a>
          declaration that includes the <samp>ExecCGI</samp>
          option.</li>
        </ol>

        <p>In some situations, you might not want to actually allow
        all files named "<samp>*.cgi</samp>" to be executable.
        Perhaps all you want is to enable a particular file in a
        normal directory to be executable. This can be
        alternatively accomplished <em>via</em> <a
        href="../mod/mod_rewrite.html"><samp>mod_rewrite</samp></a>
        and the following steps:</p>

        <ol>
          <li>
            Locally add to the corresponding <samp>.htaccess</samp>
            file a ruleset similar to this one: 

            <dl>
              <dd><code>RewriteEngine on<br />
               RewriteBase /~foo/bar/<br />
               RewriteRule ^quux\.cgi$ -
              [T=application/x-httpd-cgi]</code></dd>
            </dl>
          </li>

          <li>Make sure that the directory location is covered by
          an <a
          href="../mod/core.html#options"><samp>Options</samp></a>
          declaration that includes the <samp>ExecCGI</samp> and
          <samp>FollowSymLinks</samp> option.</li>
        </ol>
        <hr />
      </li>

      <li>
        <a id="premature-script-headers"
        name="premature-script-headers"><strong>What does it mean
        when my CGIs fail with "<samp>Premature end of script
        headers</samp>"?</strong></a> 

        <p>It means just what it says: the server was expecting a
        complete set of HTTP headers (one or more followed by a
        blank line), and didn't get them.</p>

        <p>The most common cause of this problem is the script
        dying before sending the complete set of headers, or
        possibly any at all, to the server. To see if this is the
        case, try running the script standalone from an interactive
        session, rather than as a script under the server. If you
        get error messages, this is almost certainly the cause of
        the "premature end of script headers" message. Even if the
        CGI runs fine from the command line, remember that the
        environment and permissions may be different when running
        under the web server. The CGI can only access resources
        allowed for the <a
        href="../mod/core.html#user"><code>User</code></a> and <a
        href="../mod/core.html#group"><code>Group</code></a>
        specified in your Apache configuration. In addition, the
        environment will not be the same as the one provided on the
        command line, but it can be adjusted using the directives
        provided by <a href="../mod/mod_env.html">mod_env</a>.</p>

        <p>The second most common cause of this (aside from people
        not outputting the required headers at all) is a result of
        an interaction with Perl's output buffering. To make Perl
        flush its buffers after each output statement, insert the
        following statements around the <code>print</code> or
        <code>write</code> statements that send your HTTP
        headers:</p>

        <dl>
          <dd><code>{<br />
           &nbsp;local ($oldbar) = $|;<br />
           &nbsp;$cfh = select (STDOUT);<br />
           &nbsp;$| = 1;<br />
           &nbsp;#<br />
           &nbsp;# print your HTTP headers here<br />
           &nbsp;#<br />
           &nbsp;$| = $oldbar;<br />
           &nbsp;select ($cfh);<br />
           }</code></dd>
        </dl>

        <p>This is generally only necessary when you are calling
        external programs from your script that send output to
        stdout, or if there will be a long delay between the time
        the headers are sent and the actual content starts being
        emitted. To maximize performance, you should turn
        buffer-flushing back <em>off</em> (with <code>$| = 0</code>
        or the equivalent) after the statements that send the
        headers, as displayed above.</p>

        <p>If your script isn't written in Perl, do the equivalent
        thing for whatever language you <em>are</em> using
        (<em>e.g.</em>, for C, call <code>fflush()</code> after
        writing the headers).</p>

        <p>Another cause for the "premature end of script headers"
        message are the RLimitCPU and RLimitMEM directives. You may
        get the message if the CGI script was killed due to a
        resource limit.</p>

        <p>In addition, a configuration problem in <a
        href="../suexec.html">suEXEC</a>, mod_perl, or another
        third party module can often interfere with the execution
        of your CGI and cause the "premature end of script headers"
        message.</p>
        <hr />
      </li>

      <li>
        <a id="POSTnotallowed" name="POSTnotallowed"><strong>Why do
        I keep getting "Method Not Allowed" for form POST
        requests?</strong></a> 

        <p>This is almost always due to Apache not being configured
        to treat the file you are trying to POST to as a CGI
        script. You can not POST to a normal HTML file; the
        operation has no meaning. See the FAQ entry on <a
        href="#CGIoutsideScriptAlias">CGIs outside ScriptAliased
        directories</a> for details on how to configure Apache to
        treat the file in question as a CGI.</p>
        <hr />
      </li>

      <li>
        <a id="nph-scripts" name="nph-scripts"><strong>How can I
        get my script's output without Apache buffering it? Why
        doesn't my server push work?</strong></a> 

        <p>As of Apache 1.3, CGI scripts are essentially not
        buffered. Every time your script does a "flush" to output
        data, that data gets relayed on to the client. Some
        scripting languages, for example Perl, have their own
        buffering for output - this can be disabled by setting the
        <code>$|</code> special variable to 1. Of course this does
        increase the overall number of packets being transmitted,
        which can result in a sense of slowness for the end
        user.</p>

        <p>Prior to 1.3, you needed to use "nph-" scripts to
        accomplish non-buffering. Today, the only difference
        between nph scripts and normal scripts is that nph scripts
        require the full HTTP headers to be sent.</p>
        <hr />
      </li>

      <li>
        <a id="cgi-spec" name="cgi-spec"><strong>Where can I find
        the "CGI specification"?</strong></a> 

        <p>The Common Gateway Interface (CGI) specification can be
        found at the original NCSA site &lt; <a
        href="http://hoohoo.ncsa.uiuc.edu/cgi/interface.html"><samp>
        http://hoohoo.ncsa.uiuc.edu/cgi/interface.html</samp></a>&gt;.
        This version hasn't been updated since 1995, and there have
        been some efforts to update it.</p>

        <p>A new draft is being worked on with the intent of making
        it an informational RFC; you can find out more about this
        project at &lt;<a
        href="http://web.golux.com/coar/cgi/"><samp>http://web.golux.com/coar/cgi/</samp></a>&gt;.</p>
        <hr />
      </li>

      <li>
        <a id="fastcgi" name="fastcgi"><strong>Why isn't FastCGI
        included with Apache any more?</strong></a> 

        <p>The simple answer is that it was becoming too difficult
        to keep the version being included with Apache synchronized
        with the master copy at the <a
        href="http://www.fastcgi.com/">FastCGI web site</a>. When a
        new version of Apache was released, the version of the
        FastCGI module included with it would soon be out of
        date.</p>

        <p>You can still obtain the FastCGI module for Apache from
        the master FastCGI web site.</p>
        <hr />
      </li>

      <li>
        <a id="ssi-part-i" name="ssi-part-i"><strong>How do I
        enable SSI (parsed HTML)?</strong></a> 

        <p>SSI (an acronym for Server-Side Include) directives
        allow static HTML documents to be enhanced at run-time
        (<em>e.g.</em>, when delivered to a client by Apache). The
        format of SSI directives is covered in the <a
        href="../mod/mod_include.html">mod_include manual</a>;
        suffice it to say that Apache supports not only SSI but
        xSSI (eXtended SSI) directives.</p>

        <p>Processing a document at run-time is called
        <em>parsing</em> it; hence the term "parsed HTML" sometimes
        used for documents that contain SSI instructions. Parsing
        tends to be resource-consumptive compared to serving static
        files, and is not enabled by default. It can also interfere
        with the cachability of your documents, which can put a
        further load on your server. (See the <a
        href="#ssi-part-ii">next question</a> for more information
        about this.)</p>

        <p>To enable SSI processing, you need to</p>

        <ul>
          <li>Build your server with the <a
          href="../mod/mod_include.html"><samp>mod_include</samp></a>
          module. This is normally compiled in by default.</li>

          <li>Make sure your server configuration files have an <a
          href="../mod/core.html#options"><samp>Options</samp></a>
          directive which permits <samp>Includes</samp>.</li>

          <li>
            Make sure that the directory where you want the SSI
            documents to live is covered by the "server-parsed"
            content handler, either explicitly or in some ancestral
            location. That can be done with the following <a
            href="../mod/mod_mime.html#addhandler"><samp>AddHandler</samp></a>
            directive: 

            <dl>
              <dd><code>AddHandler server-parsed .shtml</code></dd>
            </dl>

            <p>This indicates that all files ending in ".shtml" in
            that location (or its descendants) should be parsed.
            Note that using ".html" will cause all normal HTML
            files to be parsed, which may put an inordinate load on
            your server.</p>
          </li>
        </ul>

        <p>For additional information, see the <cite>Apache
        Week</cite> article on <a
        href="http://www.apacheweek.com/features/ssi"
        rel="Help"><cite>Using Server Side Includes</cite></a>.</p>
        <hr />
      </li>

      <li>
        <a id="ssi-part-ii" name="ssi-part-ii"><strong>Why don't my
        parsed files get cached?</strong></a> 

        <p>Since the server is performing run-time processing of
        your SSI directives, which may change the content shipped
        to the client, it can't know at the time it starts parsing
        what the final size of the result will be, or whether the
        parsed result will always be the same. This means that it
        can't generate <samp>Content-Length</samp> or
        <samp>Last-Modified</samp> headers. Caches commonly work by
        comparing the <samp>Last-Modified</samp> of what's in the
        cache with that being delivered by the server. Since the
        server isn't sending that header for a parsed document,
        whatever's doing the caching can't tell whether the
        document has changed or not - and so fetches it again to be
        on the safe side.</p>

        <p>You can work around this in some cases by causing an
        <samp>Expires</samp> header to be generated. (See the <a
        href="../mod/mod_expires.html"
        rel="Help"><samp>mod_expires</samp></a> documentation for
        more details.) Another possibility is to use the <a
        href="../mod/mod_include.html#xbithack"
        rel="Help"><samp>XBitHack Full</samp></a> mechanism, which
        tells Apache to send (under certain circumstances detailed
        in the XBitHack directive description) a
        <samp>Last-Modified</samp> header based upon the last
        modification time of the file being parsed. Note that this
        may actually be lying to the client if the parsed file
        doesn't change but the SSI-inserted content does; if the
        included content changes often, this can result in stale
        copies being cached.</p>
        <hr />
      </li>

      <li>
        <a id="ssi-part-iii" name="ssi-part-iii"><strong>How can I
        have my script output parsed?</strong></a> 

        <p>So you want to include SSI directives in the output from
        your CGI script, but can't figure out how to do it? The
        short answer is "you can't." This is potentially a security
        liability and, more importantly, it can not be cleanly
        implemented under the current server API. The best
        workaround is for your script itself to do what the SSIs
        would be doing. After all, it's generating the rest of the
        content.</p>

        <p>This is a feature The Apache Group hopes to add in the
        next major release after 1.3.</p>
        <hr />
      </li>

      <li>
        <a id="ssi-part-iv" name="ssi-part-iv"><strong>SSIs don't
        work for VirtualHosts and/or user home
        directories.</strong></a> 

        <p>This is almost always due to having some setting in your
        config file that sets "Options Includes" or some other
        setting for your DocumentRoot but not for other
        directories. If you set it inside a Directory section, then
        that setting will only apply to that directory.</p>
        <hr />
      </li>

      <li>
        <a id="errordocssi" name="errordocssi"><strong>How can I
        use <code>ErrorDocument</code> and SSI to simplify
        customized error messages?</strong></a> 

        <p>Have a look at <a href="custom_errordocs.html">this
        document</a>. It shows in example form how you can a
        combination of XSSI and negotiation to tailor a set of
        <code>ErrorDocument</code>s to your personal taste, and
        returning different internationalized error responses based
        on the client's native language.</p>
        <hr />
      </li>

      <li>
        <a id="remote-user-var" name="remote-user-var"><strong>Why
        is the environment variable <samp>REMOTE_USER</samp> not
        set?</strong></a> 

        <p>This variable is set and thus available in SSI or CGI
        scripts <strong>if and only if</strong> the requested
        document was protected by access authentication. For an
        explanation on how to implement these restrictions, see <a
        href="http://www.apacheweek.com/"><cite>Apache
        Week</cite></a>'s articles on <a
        href="http://www.apacheweek.com/features/userauth"><cite>Using
        User Authentication</cite></a> or <a
        href="http://www.apacheweek.com/features/dbmauth"><cite>DBM
        User Authentication</cite></a>.</p>

        <p>Hint: When using a CGI script to receive the data of a
        HTML <samp>FORM</samp> notice that protecting the document
        containing the <samp>FORM</samp> is not sufficient to
        provide <samp>REMOTE_USER</samp> to the CGI script. You
        have to protect the CGI script, too. Or alternatively only
        the CGI script (then authentication happens only after
        filling out the form).</p>
        <hr />
      </li>

      <li>
        <a id="user-cgi" name="user-cgi"><strong>How do I allow
        each of my user directories to have a cgi-bin
        directory?</strong></a> 

        <p>Remember that CGI execution does not need to be
        restricted only to cgi-bin directories. You can <a
        href="#CGIoutsideScriptAlias">allow CGI script execution in
        arbitrary parts of your filesystem</a>.</p>

        <p>There are many ways to give each user directory a
        cgi-bin directory such that anything requested as
        <samp>http://example.com/~user/cgi-bin/program</samp> will
        be executed as a CGI script. Two alternatives are:</p>

        <ol>
          <li>
            Place the cgi-bin directory next to the public_html
            directory: 

            <dl>
              <dd><code>ScriptAliasMatch ^/~([^/]*)/cgi-bin/(.*)
              /home/$1/cgi-bin/$2</code></dd>
            </dl>
          </li>

          <li>
            Place the cgi-bin directory underneath the public_html
            directory: 

            <dl>
              <dd><code>&lt;Directory
              /home/*/public_html/cgi-bin&gt;<br />
               &nbsp;&nbsp;&nbsp;&nbsp;Options ExecCGI<br />
               &nbsp;&nbsp;&nbsp;&nbsp;SetHandler cgi-script<br />
               &lt;/Directory&gt;</code></dd>
            </dl>
          </li>
        </ol>
        <p>If you are using suexec, the first technique will not work
        because CGI scripts must be stored under the <code>public_html</code>
        directory.</p>

        <hr />
      </li>
    </ol>
    
    
  </body>
</html>


    








      
      
    

    <h3>G. Authentication and Access Restrictions</h3>

    <ol>
      <li>
        <a id="dnsauth" name="dnsauth"><strong>Why isn't
        restricting access by host or domain name working
        correctly?</strong></a> 

        <p>Two of the most common causes of this are:</p>

        <ol>
          <li><strong>An error, inconsistency, or unexpected
          mapping in the DNS registration</strong><br />
           This happens frequently: your configuration restricts
          access to <samp>Host.FooBar.Com</samp>, but you can't get
          in from that host. The usual reason for this is that
          <samp>Host.FooBar.Com</samp> is actually an alias for
          another name, and when Apache performs the
          address-to-name lookup it's getting the <em>real</em>
          name, not <samp>Host.FooBar.Com</samp>. You can verify
          this by checking the reverse lookup yourself. The easiest
          way to work around it is to specify the correct host name
          in your configuration.</li>

          <li>
            <strong>Inadequate checking and verification in your
            configuration of Apache</strong><br />
             If you intend to perform access checking and
            restriction based upon the client's host or domain
            name, you really need to configure Apache to
            double-check the origin information it's supplied. You
            do this by adding the <samp>-DMAXIMUM_DNS</samp> clause
            to the <samp>EXTRA_CFLAGS</samp> definition in your
            <samp>Configuration</samp> file. For example: 

            <dl>
              <dd><code>EXTRA_CFLAGS=-DMAXIMUM_DNS</code></dd>
            </dl>

            <p>This will cause Apache to be very paranoid about
            making sure a particular host address is
            <em>really</em> assigned to the name it claims to be.
            Note that this <em>can</em> incur a significant
            performance penalty, however, because of all the name
            resolution requests being sent to a nameserver.</p>
          </li>
        </ol>
        <hr />
      </li>

      <li>
        <a id="user-authentication"
        name="user-authentication"><strong>How do I set up Apache
        to require a username and password to access certain
        documents?</strong></a> 

        <p>There are several ways to do this; some of the more
        popular ones are to use the <a
        href="../mod/mod_auth.html">mod_auth</a>, <a
        href="../mod/mod_auth_db.html">mod_auth_db</a>, or <a
        href="../mod/mod_auth_dbm.html">mod_auth_dbm</a>
        modules.</p>

        <p>For an explanation on how to implement these
        restrictions, see <a
        href="http://www.apacheweek.com/"><cite>Apache
        Week</cite></a>'s articles on <a
        href="http://www.apacheweek.com/features/userauth"><cite>Using
        User Authentication</cite></a> or <a
        href="http://www.apacheweek.com/features/dbmauth"><cite>DBM
        User Authentication</cite></a>, or see the <a
        href="../howto/auth.html">authentication tutorial</a> in the
        Apache documentation.</p>
        <hr />
      </li>

      <li>
        <a id="remote-auth-only"
        name="remote-auth-only"><strong>How do I set up Apache to
        allow access to certain documents only if a site is either
        a local site <em>or</em> the user supplies a password and
        username?</strong></a> 

        <p>Use the <a href="../mod/core.html#satisfy">Satisfy</a>
        directive, in particular the <code>Satisfy Any</code>
        directive, to require that only one of the access
        restrictions be met. For example, adding the following
        configuration to a <samp>.htaccess</samp> or server
        configuration file would restrict access to people who
        either are accessing the site from a host under domain.com
        or who can supply a valid username and password:</p>

        <dl>
          <dd><code>Deny from all<br />
           Allow from .domain.com<br />
           AuthType Basic<br />
           AuthUserFile /usr/local/apache/conf/htpasswd.users<br />
           AuthName "special directory"<br />
           Require valid-user<br />
           Satisfy any</code></dd>
        </dl>

        <p>See the <a href="#user-authentication">user
        authentication</a> question and the <a
        href="../mod/mod_access.html">mod_access</a> module for
        details on how the above directives work.</p>
        <hr />
      </li>

      <li>
        <a id="authauthoritative"
        name="authauthoritative"><strong>Why does my authentication
        give me a server error?</strong></a> 

        <p>Under normal circumstances, the Apache access control
        modules will pass unrecognized user IDs on to the next
        access control module in line. Only if the user ID is
        recognized and the password is validated (or not) will it
        give the usual success or "authentication failed"
        messages.</p>

        <p>However, if the last access module in line 'declines'
        the validation request (because it has never heard of the
        user ID or because it is not configured), the
        <samp>http_request</samp> handler will give one of the
        following, confusing, errors:</p>

        <ul>
          <li><samp>check access</samp></li>

          <li><samp>check user. No user file?</samp></li>

          <li><samp>check access. No groups file?</samp></li>
        </ul>

        <p>This does <em>not</em> mean that you have to add an
        '<samp>AuthUserFile&nbsp;/dev/null</samp>' line as some
        magazines suggest!</p>

        <p>The solution is to ensure that at least the last module
        is authoritative and <strong>CONFIGURED</strong>. By
        default, <samp>mod_auth</samp> is authoritative and will
        give an OK/Denied, but only if it is configured with the
        proper <samp>AuthUserFile</samp>. Likewise, if a valid
        group is required. (Remember that the modules are processed
        in the reverse order from that in which they appear in your
        compile-time <samp>Configuration</samp> file.)</p>

        <p>A typical situation for this error is when you are using
        the <samp>mod_auth_dbm</samp>, <samp>mod_auth_msql</samp>,
        <samp>mod_auth_mysql</samp>, <samp>mod_auth_anon</samp> or
        <samp>mod_auth_cookie</samp> modules on their own. These
        are by default <strong>not</strong> authoritative, and this
        will pass the buck on to the (non-existent) next
        authentication module when the user ID is not in their
        respective database. Just add the appropriate
        '<samp><em>XXX</em>Authoritative yes</samp>' line to the
        configuration.</p>

        <p>In general it is a good idea (though not terribly
        efficient) to have the file-based <samp>mod_auth</samp> a
        module of last resort. This allows you to access the web
        server with a few special passwords even if the databases
        are down or corrupted. This does cost a file
        open/seek/close for each request in a protected area.</p>
        <hr />
      </li>

      <li>
        <a id="auth-on-same-machine"
        name="auth-on-same-machine"><strong>Do I have to keep the
        (mSQL) authentication information on the same
        machine?</strong></a> 

        <p>Some organizations feel very strongly about keeping the
        authentication information on a different machine than the
        webserver. With the <samp>mod_auth_msql</samp>,
        <samp>mod_auth_mysql</samp>, and other SQL modules
        connecting to (R)DBMses this is quite possible. Just
        configure an explicit host to contact.</p>

        <p>Be aware that with mSQL and Oracle, opening and closing
        these database connections is very expensive and time
        consuming. You might want to look at the code in the
        <samp>auth_*</samp> modules and play with the compile time
        flags to alleviate this somewhat, if your RDBMS licences
        allow for it.</p>
        <hr />
      </li>

      <li>
        <a id="msql-slow" name="msql-slow"><strong>Why is my mSQL
        authentication terribly slow?</strong></a> 

        <p>You have probably configured the Host by specifying a
        FQHN, and thus the <samp>libmsql</samp> will use a full
        blown TCP/IP socket to talk to the database, rather than a
        fast internal device. The <samp>libmsql</samp>, the mSQL
        FAQ, and the <samp>mod_auth_msql</samp> documentation warn
        you about this. If you have to use different hosts, check
        out the <samp>mod_auth_msql</samp> code for some compile
        time flags which might - or might not - suit you.</p>
        <hr />
      </li>

      <li>
        <a id="passwdauth" name="passwdauth"><strong>Can I use my
        <samp>/etc/passwd</samp> file for Web page
        authentication?</strong></a> 

        <p>Yes, you can - but it's a <strong>very bad
        idea</strong>. Here are some of the reasons:</p>

        <ul>
          <li>The Web technology provides no governors on how often
          or how rapidly password (authentication failure) retries
          can be made. That means that someone can hammer away at
          your system's <samp>root</samp> password using the Web,
          using a dictionary or similar mass attack, just as fast
          as the wire and your server can handle the requests. Most
          operating systems these days include attack detection
          (such as <em>n</em> failed passwords for the same account
          within <em>m</em> seconds) and evasion (breaking the
          connection, disabling the account under attack, disabling
          <em>all</em> logins from that source, <em>et
          cetera</em>), but the Web does not.</li>

          <li>An account under attack isn't notified (unless the
          server is heavily modified); there's no "You have 19483
          login failures" message when the legitimate owner logs
          in.</li>

          <li>Without an exhaustive and error-prone examination of
          the server logs, you can't tell whether an account has
          been compromised. Detecting that an attack has occurred,
          or is in progress, is fairly obvious, though -
          <em>if</em> you look at the logs.</li>

          <li>Web authentication passwords (at least for Basic
          authentication) generally fly across the wire, and
          through intermediate proxy systems, in what amounts to
          plain text. "O'er the net we go/Caching all the way;/O
          what fun it is to surf/Giving my password away!"</li>

          <li>Since HTTP is stateless, information about the
          authentication is transmitted <em>each and every
          time</em> a request is made to the server. Essentially,
          the client caches it after the first successful access,
          and transmits it without asking for all subsequent
          requests to the same server.</li>

          <li>It's relatively trivial for someone on your system to
          put up a page that will steal the cached password from a
          client's cache without them knowing. Can you say
          "password grabber"?</li>
        </ul>

        <p>If you still want to do this in light of the above
        disadvantages, the method is left as an exercise for the
        reader. It'll void your Apache warranty, though, and you'll
        lose all accumulated UNIX guru points.</p>
        <hr />
      </li>

      <li>
        <a id="prompted-twice" name="prompted-twice"><strong>Why
        does Apache ask for my password twice before serving a
        file?</strong></a> 

        <p>If the hostname under which you are accessing the server
        is different than the hostname specified in the <a
        href="../mod/core.html#servername"><code>ServerName</code></a>
        directive, then depending on the setting of the <a
        href="../mod/core.html#usecanonicalname"><code>UseCanonicalName</code></a>
        directive, Apache will redirect you to a new hostname when
        constructing self-referential URLs. This happens, for
        example, in the case where you request a directory without
        including the trailing slash.</p>

        <p>When this happens, Apache will ask for authentication
        once under the original hostname, perform the redirect, and
        then ask again under the new hostname. For security
        reasons, the browser must prompt again for the password
        when the host name changes.</p>

        <p>To eliminate this problem you should</p>

        <ol>
          <li>Always use the trailing slash when requesting
          directories;</li>

          <li>Change the <code>ServerName</code> to match the name
          you are using in the URL; and/or</li>

          <li>Set <code>UseCanonicalName off</code>.</li>
        </ol>
        <hr />
      </li>

      <li>
        <a id="image-theft" name="image-theft"><strong>How can I prevent
        people from "stealing" the images from my web site?</strong></a> 

        <p>The goal here is to prevent people from inlining your images
        directly from their web site, but accessing them only if they
        appear inline in your pages.<p>

        <p>This can be accomplished with a combination of SetEnvIf and
        the Deny and Allow directives. However, it is important to 
        understand that any access restriction based on the REFERER
        header is intrinsically problematic due to the fact that 
        browsers can send an incorrect REFERER, either because they 
        want to circumvent your restriction or simply because they don't
        send the right thing (or anything at all).</p>

        <p>The following configuration will produce the desired effect
        if the browser passes correct REFERER headers.</p>

<pre>
SetEnvIf REFERER "www\.mydomain\.com" linked_from_here
SetEnvIf REFERER "^$" linked_from_here

&lt;Directory /www/images&gt;
    Order deny,allow
    Deny from all
    Allow from env=linked_from_here
&lt;/Directory&gt;
</pre>

<p>Further examples can be found in the <a 
href="../env.html#examples">Environment Variables</a> documentation.</p>

        <hr />
      </li>


    </ol>
    
    
  </body>
</html>


    








      
      
    

    <h3>H. URL Rewriting</h3>

    <ol>
      <li>
        <a id="rewrite-more-config"
        name="rewrite-more-config"><strong>Where can I find
        mod_rewrite rulesets which already solve particular
        URL-related problems?</strong></a> 

        <p>There is a collection of practical solutions that can be
        found in the
        <a href="rewriteguide.html">Apache 1.3 URL Rewriting Guide</a>.
        If you have more interesting rulesets
        which solve particular problems not currently covered in
        this document, send it to <a
        href="mailto:rse@apache.org">Ralf S. Engelschall</a> for
        inclusion. The other webmasters will thank you for avoiding
        the reinvention of the wheel.</p>
        <hr />
      </li>

      <li>
        <a id="rewrite-article"
        name="rewrite-article"><strong>Where can I find any
        published information about URL-manipulations and
        mod_rewrite?</strong></a> 

        <p>There is an article from <a
        href="mailto:rse@apache.org">Ralf S. Engelschall</a> about
        URL-manipulations based on <a
        href="../mod/mod_rewrite.html"><samp>mod_rewrite</samp></a>
        in the "iX Multiuser Multitasking Magazin" issue #12/96.
        The German (original) version can be read online at &lt;<a
        href="http://www.heise.de/ix/artikel/1996/12/149/">http://www.heise.de/ix/artikel/1996/12/149/</a>&gt;,
        the English (translated) version can be found at &lt;<a
        href="http://www.heise.de/ix/artikel/E/1996/12/149/">http://www.heise.de/ix/artikel/E/1996/12/149/</a>&gt;.</p>
        <hr />
      </li>

      <li>
        <a id="rewrite-complexity"
        name="rewrite-complexity"><strong>Why is mod_rewrite so
        difficult to learn and seems so complicated?</strong></a> 

        <p>Hmmm... there are a lot of reasons. First, mod_rewrite
        itself is a powerful module which can help you in really
        <strong>all</strong> aspects of URL rewriting, so it can be
        no trivial module per definition. To accomplish its hard
        job it uses software leverage and makes use of a powerful
        regular expression library by Henry Spencer which is an
        integral part of Apache since its version 1.2. And regular
        expressions itself can be difficult to newbies, while
        providing the most flexible power to the advanced
        hacker.</p>

        <p>On the other hand mod_rewrite has to work inside the
        Apache API environment and needs to do some tricks to fit
        there. For instance the Apache API as of 1.x really was not
        designed for URL rewriting at the <tt>.htaccess</tt> level
        of processing. Or the problem of multiple rewrites in
        sequence, which is also not handled by the API per design.
        To provide this features mod_rewrite has to do some special
        (but API compliant!) handling which leads to difficult
        processing inside the Apache kernel. While the user usually
        doesn't see anything of this processing, it can be
        difficult to find problems when some of your RewriteRules
        seem not to work.</p>
        <hr />
      </li>

      <li>
        <a id="rewrite-dontwork"
        name="rewrite-dontwork"><strong>What can I do if my
        RewriteRules don't work as expected?</strong></a> 

        <p>Use "<samp>RewriteLog somefile</samp>" and
        "<samp>RewriteLogLevel 9</samp>" and have a precise look at
        the steps the rewriting engine performs. This is really the
        only one and best way to debug your rewriting
        configuration.</p>
        <hr />
      </li>

      <li>
        <a id="rewrite-prefixdocroot"
        name="rewrite-prefixdocroot"><strong>Why don't some of my
        URLs get prefixed with DocumentRoot when using
        mod_rewrite?</strong></a> 

        <p>If the rule starts with <samp>/somedir/...</samp> make
        sure that really no <samp>/somedir</samp> exists on the
        filesystem if you don't want to lead the URL to match this
        directory, <em>i.e.</em>, there must be no root directory
        named <samp>somedir</samp> on the filesystem. Because if
        there is such a directory, the URL will not get prefixed
        with DocumentRoot. This behavior looks ugly, but is really
        important for some other aspects of URL rewriting.</p>
        <hr />
      </li>

      <li>
        <a id="rewrite-nocase" name="rewrite-nocase"><strong>How
        can I make all my URLs case-insensitive with
        mod_rewrite?</strong></a> 

        <p>You can't! The reasons are: first, that, case
        translations for arbitrary length URLs cannot be done
        <em>via</em> regex patterns and corresponding
        substitutions. One needs a per-character pattern like the
        sed/Perl <samp>tr|..|..|</samp> feature. Second, just
        making URLs always upper or lower case does not solve the
        whole problem of case-INSENSITIVE URLs, because URLs
        actually have to be rewritten to the correct case-variant
        for the file residing on the filesystem in order to allow
        Apache to access the file. And the Unix filesystem is
        always case-SENSITIVE.</p>

        <p>But there is a module named <code><a
        href="../mod/mod_speling.html">mod_speling.c</a></code> in
        the Apache distribution. Try this module to help correct
        people who use mis-cased URLs.</p>
        <hr />
      </li>

      <li>
        <a id="rewrite-virthost"
        name="rewrite-virthost"><strong>Why are RewriteRules in my
        VirtualHost parts ignored?</strong></a> 

        <p>Because you have to enable the engine for every virtual
        host explicitly due to security concerns. Just add a
        "RewriteEngine on" to your virtual host configuration
        parts.</p>
        <hr />
      </li>

      <li>
        <a id="rewrite-envwhitespace"
        name="rewrite-envwhitespace"><strong>How can I use strings
        with whitespaces in RewriteRule's ENV flag?</strong></a> 

        <p>There is only one ugly solution: You have to surround
        the complete flag argument by quotation marks
        (<samp>"[E=...]"</samp>). Notice: The argument to quote
        here is not the argument to the E-flag, it is the argument
        of the Apache config file parser, <em>i.e.</em>, the third
        argument of the RewriteRule here. So you have to write
        <samp>"[E=any text with whitespaces]"</samp>.</p>
        <hr />
      </li>
    </ol>
    
    
  </body>
</html>


    








      
      
    

    <h3>I. Features</h3>

    <ol>
      <li>
        <a id="proxy" name="proxy"><strong>Does or will Apache act
        as a Proxy server?</strong></a> 

        <p>Apache version 1.1 and above comes with a <a
        href="../mod/mod_proxy.html">proxy module</a>. If compiled
        in, this will make Apache act as a caching-proxy
        server.</p>
        <hr />
      </li>

      <li>
        <a id="multiviews" name="multiviews"><strong>What are
        "multiviews"?</strong></a> 

        <p>"Multiviews" is the general name given to the Apache
        server's ability to provide language-specific document
        variants in response to a request. This is documented quite
        thoroughly in the <a href="../content-negotiation.html"
        rel="Help">content negotiation</a> description page. In
        addition, <cite>Apache Week</cite> carried an article on
        this subject entitled "<a
        href="http://www.apacheweek.com/features/negotiation"
        rel="Help"><cite>Content Negotiation
        Explained</cite></a>".</p>
        <hr />
      </li>

      <li>
        <a id="putsupport" name="putsupport"><strong>Why can't I
        publish to my Apache server using PUT on Netscape Gold and
        other programs?</strong></a> 

        <p>Because you need to install and configure a script to
        handle the uploaded files. This script is often called a
        "PUT" handler. There are several available, but they may
        have security problems. Using FTP uploads may be easier and
        more secure, at least for now. For more information, see
        the <cite>Apache Week</cite> article <a
        href="http://www.apacheweek.com/features/put"><cite>Publishing
        Pages with PUT</cite></a>.</p>
        <hr />
      </li>

      <li>
        <a id="SSL-i" name="SSL-i"><strong>Why doesn't Apache
        include SSL?</strong></a> 

        <p>SSL (Secure Socket Layer) data transport requires
        encryption, and many governments have restrictions upon the
        import, export, and use of encryption technology. If Apache
        included SSL in the base package, its distribution would
        involve all sorts of legal and bureaucratic issues, and it
        would no longer be freely available. Also, some of the
        technology required to talk to current clients using SSL is
        patented by <a href="http://www.rsa.com/">RSA Data
        Security</a>, who restricts its use without a license.</p>

        <p>Some SSL implementations of Apache are available,
        however; see the "<a
        href="http://httpd.apache.org/related_projects.html">related
        projects</a>" page at the main Apache web site.</p>

        <p>You can find out more about this topic in the
        <cite>Apache Week</cite> article about <a
        href="http://www.apacheweek.com/features/ssl"
        rel="Help"><cite>Apache and Secure
        Transactions</cite></a>.</p>
        <hr />
      </li>

      <li>
        <a id="footer" name="footer"><strong>How can I attach a
        footer to my documents without using SSI?</strong></a> 

        <p>You can make arbitrary changes to static documents by
        configuring an <a
        href="../mod/mod_actions.html#action">Action</a> which
        launches a CGI script. The CGI is then responsible for
        setting a content-type and delivering the requested
        document (the location of which is passed in the
        <samp>PATH_TRANSLATED</samp> environment variable), along
        with whatever footer is needed.</p>

        <p>Busy sites may not want to run a CGI script on every
        request, and should consider using an Apache module to add
        the footer. There are several third party modules available
        through the <a href="http://modules.apache.org/">Apache
        Module Registry</a> which will add footers to documents.
        These include mod_trailer, PHP
        (<samp>php3_auto_append_file</samp>), mod_layout, and
        mod_perl (<samp>Apache::Sandwich</samp>).</p>
        <hr />
      </li>

      <li>
        <a id="search" name="search"><strong>Does Apache include a
        search engine?</strong></a> 

        <p>Apache does not include a search engine, but there are
        many good commercial and free search engines which can be
        used easily with Apache. Some of them are listed on the <a
        href="http://www.searchtools.com/tools/tools.html">Web Site
        Search Tools</a> page. Open source search engines that are
        often used with Apache include <a
        href="http://www.htdig.org/">ht://Dig</a> and <a
        href="http://sunsite.berkeley.edu/SWISH-E/">SWISH-E</a>.</p>
        <hr />
      </li>

      <li>
        <a id="rotate" name="rotate"><strong>How can I rotate my
        log files?</strong></a> 

        <p>The simple answer: by piping the transfer log into an
        appropriate log file rotation utility.</p>

        <p>The longer answer: In the src/support/ directory, you
        will find a utility called <a
        href="../programs/rotatelogs.html">rotatelogs</a> which can
        be used like this:</p>
<pre>
   TransferLog "|/path/to/rotatelogs /path/to/logs/access_log 86400"
</pre>

        <p>to enable daily rotation of the log files.<br />
         A more sophisticated solution of a logfile rotation
        utility is available under the name <code>cronolog</code>
        from Andrew Ford's site at <a
        href="http://www.cronolog.org/">http://www.cronolog.org/</a>.
        It can automatically create logfile subdirectories based on
        time and date, and can have a constant symlink point to the
        rotating logfiles. (As of version 1.6.1, cronolog is
        available under the <a href="../LICENSE">Apache
        License</a>). Use it like this:</p>
<pre>
   CustomLog "|/path/to/cronolog --symlink=/usr/local/apache/logs/access_log /usr/local/apache/logs/%Y/%m/access_log" combined
</pre>
        <hr />
      </li>

      <li>
        <a id="conditional-logging"
        name="conditional-logging"><strong>How do I keep certain
        requests from appearing in my logs?</strong></a> 

        <p>The maximum flexibility for removing unwanted
        information from log files is obtained by post-processing
        the logs, or using piped-logs to feed the logs through a
        program which does whatever you want. However, Apache does
        offer the ability to prevent requests from ever appearing
        in the log files. You can do this by using the <a
        href="../mod/mod_setenvif.html#setenvif"><code>SetEnvIf</code></a>
        directive to set an environment variable for certain
        requests and then using the conditional <a
        href="../mod/mod_log_config.html#customlog-conditional"><code>
        CustomLog</code></a> syntax to prevent logging when the
        environment variable is set.</p>
        <hr />
      </li>

      <li>
        <a id="dbinteg" name="dbinteg"><b>Does Apache support any
        sort of database integration?</b></a> 

        <p>No. Apache is a Web (HTTP) server, not an application
        server. The base package does not include any such
        functionality. See the <a href="http://www.php.net/">PHP
        project</a> and the <a
        href="http://perl.apache.org/">mod_perl project</a> for
        examples of modules that allow you to work with databases
        from within the Apache environment.</p>
        <hr />
      </li>

      <li>
        <a id="asp" name="asp"><b>Can I use Active Server Pages
        (ASP) with Apache?</b></a> 

        <p>The base Apache Web Server package does not include ASP
        support. However, a number of projects provide ASP or 
        ASP-like functionality for Apache. Some of these are:</p>
            <ul>
            <li><a
            href="http://www.apache-asp.org/">Apache::ASP</a></li>
            <li><a
            href="http://go-mono.com/archive/xsp-0.10.html">mod_mono</a></li>
            <li><a
            href="http://wwws.sun.com/software/chilisoft/">Chilisoft
            ASP</a></li>
            </ul>
        <p>See also the <a
        href="http://httpd.apache.org/related_projects.html">related
        projects</a> page to find out more.</p>
        <hr />
      </li>

      <li>
        <a id="java" name="java"><b>Does Apache come with Java
        support?</b></a> 

        <p>The base Apache Web server package does not include
        support for Java, Java Server Pages, Enterprise Java Beans,
        or Java servlets. Those features are available as add-ons
        from the Apache/Java project site, &lt;URL:<a
        href="http://jakarta.apache.org">http://jakarta.apache.org/</a>&gt;.</p>
        <hr />
      </li>
    </ol>
    
    
  </body>
</html>


        <hr />

    <h3 align="CENTER">Apache HTTP Server Version 1.3</h3>
    <a href="./"><img src="../images/index.gif" alt="Index" /></a>
    <a href="../"><img src="../images/home.gif" alt="Home" /></a>

  </body>
</html>


Man Man