docs/manual/misc/FAQ-E.html - httpd - Git at Google

 <!--#if expr="$FAQMASTER" -->
  <!--#set var="STANDALONE" value="" -->
  <!--#set var="INCLUDED" value="YES" -->
  <!--#if expr="$QUERY_STRING = TOC" -->
   <!--#set var="TOC" value="YES" -->
   <!--#set var="CONTENT" value="" -->
  <!--#else -->
   <!--#set var="TOC" value="" -->
   <!--#set var="CONTENT" value="YES" -->
  <!--#endif -->
 <!--#else -->
  <!--#set var="STANDALONE" value="YES" -->
  <!--#set var="INCLUDED" value="" -->
  <!--#set var="TOC" value="" -->
  <!--#set var="CONTENT" value="" -->
 <!--#endif -->
 <!--#if expr="$STANDALONE" -->
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
 <HTML>
  <HEAD>
   <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"
  >
   <!--#include virtual="header.html" -->
   <H1 ALIGN="CENTER">Apache Server Frequently Asked Questions</H1>
   <P>
   $Revision: 1.4 $ ($Date: 1999/07/04 16:33:00 $)
   </P>
   <P>
   The latest version of this FAQ is always available from the main
   Apache web site, at
   &lt;<A
        HREF="http://www.apache.org/docs/misc/FAQ.html"
        REL="Help"
       ><SAMP>http://www.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 &quot;[12]&quot;).  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>
 <OL TYPE="A">
 <!--#endif -->
 <!--#if expr="$TOC || $STANDALONE" -->
  <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 &quot;/&quot;
         (<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
         &quot;<SAMP>Forbidden</SAMP>&quot; message whenever I try to
         access a particular directory?</A>
   </OL>
  </LI>
 <!--#endif -->
 <!--#if expr="$STANDALONE" -->
 </OL>

 <HR>

   <H2>The Answers</H2>
 <!--#endif -->
 <!--#if expr="! $TOC" -->

   <H3>E. Configuration Questions</H3>
 <OL>

  <LI><A 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>&quot;Don't do that&quot; - 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 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 &quot;<SAMP>-DFD_SETSIZE=<EM>nnn</EM></SAMP>&quot; to the
   <SAMP>EXTRA_CFLAGS</SAMP> line in your <SAMP>Configuration</SAMP>
   file.
   </P>
   <HR>
  </LI>

  <LI><A 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
   &quot;<SAMP>/foo/bar</SAMP>&quot; and not one with a method and
   hostname such as &quot;<SAMP>http://host/foo/bar</SAMP>&quot;.  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 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 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 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 &quot;HTTP/1.0&quot; and do not correctly interpret
   the &quot;HTTP/1.1&quot; 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 &quot;fake&quot; 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>
   <P>
   <DL>
    <DD><CODE>BrowserMatch Java1.0 force-response-1.0
     <BR>
     BrowserMatch JDK/1.0 force-response-1.0</CODE>
    </DD>
   </DL>
   <P></P>
   <P>
   More information about this issue can be found in the
   <A HREF="http://www.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 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:
     <P>
     <DL>
      <DD><CODE>AddType audio/x-midi .mid .midi .kar</CODE>
      </DD>
     </DL>
     <P></P>
     <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 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:
   &quot;<A HREF="http://www.apacheweek.com/features/logfiles" REL="Help"
         ><CITE>Gathering Visitor Information: Customizing Your
          Logfiles</CITE></A>&quot;.
   </P>
   <HR>
  </LI>

  <LI><A NAME="set-servername">
       <STRONG>Why does accessing directories only work when I include
       the trailing &quot;/&quot;
       (<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 &quot;/&quot;, 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>
   <HR>
  </LI>

  <LI><A 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 &quot;current&quot; 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 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 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="http://www.apache.org/docs/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 &quot;<SAMP>n.n.n.n</SAMP>&quot; 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="http://www.apache.org/docs/vhosts/">Apache
   Virtual Host documentation</A> for further details about configuration.
   </P>
   <HR>
  </LI>

  <LI><A 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 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 NAME="forbidden">
        <STRONG>Why do I get a &quot;<SAMP>Forbidden</SAMP>&quot; 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>The Apache configuration has some access restrictions in
      place which forbid access to the files.
    </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 by the
    web server in order for the content to be accessible.
    </P>
    <HR>
   </LI>
 </OL>
 <!--#endif -->
 <!--#if expr="$STANDALONE" -->
   <!-- Don't forget to add HR tags at the end of each list item.. -->

 <!--#include virtual="footer.html" -->
 </BODY>
 </HTML>
 <!--#endif -->
	<!--#if expr="$FAQMASTER" -->
	<!--#set var="STANDALONE" value="" -->
	<!--#set var="INCLUDED" value="YES" -->
	<!--#if expr="$QUERY_STRING = TOC" -->
	<!--#set var="TOC" value="YES" -->
	<!--#set var="CONTENT" value="" -->
	<!--#else -->
	<!--#set var="TOC" value="" -->
	<!--#set var="CONTENT" value="YES" -->
	<!--#endif -->
	<!--#else -->
	<!--#set var="STANDALONE" value="YES" -->
	<!--#set var="INCLUDED" value="" -->
	<!--#set var="TOC" value="" -->
	<!--#set var="CONTENT" value="" -->
	<!--#endif -->
	<!--#if expr="$STANDALONE" -->
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
	<HTML>
	<HEAD>
	<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"
	>
	<!--#include virtual="header.html" -->
	<H1 ALIGN="CENTER">Apache Server Frequently Asked Questions</H1>
	<P>
	$Revision: 1.4 $ ($Date: 1999/07/04 16:33:00 $)
	</P>
	<P>
	The latest version of this FAQ is always available from the main
	Apache web site, at
	<<A
	HREF="http://www.apache.org/docs/misc/FAQ.html"
	REL="Help"
	><SAMP>http://www.apache.org/docs/misc/FAQ.html</SAMP></A>>.
	</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>
	<OL TYPE="A">
	<!--#endif -->
	<!--#if expr="$TOC \|\| $STANDALONE" -->
	<LI VALUE="5"><STRONG>Configuration Questions</STRONG>
	<OL>
	<LI><A HREF="#fdlim">Why can't I run more than <<EM>n</EM>>
	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>, <SAMP>http://foo.domain.com/~user/</SAMP>) but
	not when I omit it
	(<EM>e.g.</EM>, <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>
	</OL>
	</LI>
	<!--#endif -->
	<!--#if expr="$STANDALONE" -->
	</OL>

	<HR>

	<H2>The Answers</H2>
	<!--#endif -->
	<!--#if expr="! $TOC" -->

	<H3>E. Configuration Questions</H3>
	<OL>

	<LI><A NAME="fdlim">
	<STRONG>Why can't I run more than <<EM>n</EM>>
	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 <<EM>n</EM>> 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 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 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 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 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 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>
	<P>
	<DL>
	<DD><CODE>BrowserMatch Java1.0 force-response-1.0
	<BR>
	BrowserMatch JDK/1.0 force-response-1.0</CODE>
	</DD>
	</DL>
	<P></P>
	<P>
	More information about this issue can be found in the
	<A HREF="http://www.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 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:
	<P>
	<DL>
	<DD><CODE>AddType audio/x-midi .mid .midi .kar</CODE>
	</DD>
	</DL>
	<P></P>
	<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 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 logs/access_log "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{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 NAME="set-servername">
	<STRONG>Why does accessing directories only work when I include
	the trailing "/"
	(<EM>e.g.</EM>, <SAMP>http://foo.domain.com/~user/</SAMP>)
	but not when I omit it
	(<EM>e.g.</EM>, <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>
	<HR>
	</LI>

	<LI><A 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 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 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><VirtualHost></SAMP> definitions were very complex and not
	well documented.
	</P>
	<P>
	Apache 1.3b2 introduced a new directive,
	<A HREF="http://www.apache.org/docs/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><VirtualHost></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><VirtualHost></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="http://www.apache.org/docs/vhosts/">Apache
	Virtual Host documentation</A> for further details about configuration.
	</P>
	<HR>
	</LI>

	<LI><A 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 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 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>The Apache configuration has some access restrictions in
	place which forbid access to the files.
	</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 by the
	web server in order for the content to be accessible.
	</P>
	<HR>
	</LI>
	</OL>
	<!--#endif -->
	<!--#if expr="$STANDALONE" -->
	<!-- Don't forget to add HR tags at the end of each list item.. -->

	<!--#include virtual="footer.html" -->
	</BODY>
	</HTML>
	<!--#endif -->