--- /dev/null
+<!--#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.1 $ ($Date: 1999/06/24 15:02:51 $)
+ </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="1"><STRONG>Background</STRONG>
+ <OL>
+ <LI><A HREF="#what">What is Apache?</A>
+ </LI>
+ <LI><A HREF="#why">Why was Apache created?</A>
+ </LI>
+ <LI><A HREF="#relate">How does The Apache Group's work relate to
+ other servers?</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>
+ </OL>
+ </LI>
+<!--#endif -->
+<!--#if expr="$STANDALONE" -->
+</OL>
+
+<HR>
+
+ <H2>The Answers</H2>
+<!--#endif -->
+<!--#if expr="! $TOC" -->
+ <H3>A. Background</H3>
+<OL>
+ <LI><A NAME="what">
+ <STRONG>What is Apache?</STRONG>
+ </A>
+ <P>
+ Apache was originally based on code and ideas found in the most
+ popular HTTP server of the time.. NCSA httpd 1.3 (early 1995). It has
+ since evolved into a far superior system which can rival (and probably
+ surpass) almost any other UNIX based HTTP server in terms of functionality,
+ efficiency and speed.
+ </P>
+ <P>
+ Since it began, it has been completely rewritten, and includes many new
+ features. Apache is, as of January 1997, the most popular WWW server on
+ the Internet, according to the
+ <A HREF="http://www.netcraft.com/Survey/">Netcraft Survey</A>.
+ </P>
+ <HR>
+ </LI>
+
+ <LI><A NAME="why">
+ <STRONG>Why was Apache created?</STRONG>
+ </A>
+ <P>
+ To address the concerns of a group of WWW providers and part-time httpd
+ programmers that httpd didn't behave as they wanted it to behave.
+ Apache is an entirely volunteer effort, completely funded by its
+ members, not by commercial sales.
+ </P>
+ <HR>
+ </LI>
+
+ <LI><A NAME="relate">
+ <STRONG>How does The Apache Group's work relate to other
+ server efforts, such as NCSA's?</STRONG>
+ </A>
+ <P>
+ We, of course, owe a great debt to NCSA and their programmers for
+ making the server Apache was based on. We now, however, have our own
+ server, and our project is mostly our own. The Apache Project is an
+ entirely independent venture.
+ </P>
+ <HR>
+ </LI>
+
+ <LI><A NAME="name">
+ <STRONG>Why the name "Apache"?</STRONG>
+ </A>
+ <P>
+ A 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 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/chart.html">Web Compare</A>'s
+ comparison chart.
+ </P>
+ <P>
+ Apache has been shown to be substantially faster than many other
+ free 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 NAME="tested">
+ <STRONG>How thoroughly tested is Apache?</STRONG>
+ </A>
+ <P>
+ Apache is run on over 1.2 million Internet servers (as of July 1998). 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>
+ <P>
+ The Apache project's web site includes a page with a partial list of
+ <A HREF="http://www.apache.org/info/apache_users.html">sites running
+ Apache</A>.
+ </P>
+ <HR>
+ </LI>
+
+ <LI><A NAME="future">
+ <STRONG>What are the future plans for Apache?</STRONG>
+ </A>
+ <P>
+ <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>
+ <P></P>
+ <HR>
+ </LI>
+
+ <LI><A 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://www.apache.org/bug_report.html">the bug report page</A>.
+ Other questions should be directed to 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 NAME="more">
+ <STRONG>Is there any more information available on
+ Apache?</STRONG>
+ </A>
+ <P>
+ Indeed there is. See the main
+ <A HREF="http://www.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://www.apache.org/info/apache_books.html"
+ >Apache-specific books</A> available.
+ </P>
+ <HR>
+ </LI>
+
+ <LI><A 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://www.apache.org/">main web page</A>.
+ </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 -->
--- /dev/null
+<!--#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.1 $ ($Date: 1999/06/24 15:02:51 $)
+ </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="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>
+ </OL>
+ </LI>
+<!--#endif -->
+<!--#if expr="$STANDALONE" -->
+</OL>
+
+<HR>
+
+ <H2>The Answers</H2>
+<!--#endif -->
+<!--#if expr="! $TOC" -->
+
+ <H3>B. General Technical Questions</H3>
+<OL>
+
+ <LI><A 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
+ & 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://www.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 the <SAMP>comp.infosystems.www.servers.unix</SAMP>
+ or <SAMP>comp.infosystems.www.servers.ms-windows</SAMP> USENET
+ newsgroup (as appropriate for the platform you use).</STRONG>
+ <P>
+ A lot of common problems never make it to the bug database because
+ there's already high Q&A traffic about them in the
+ <A HREF="news:comp.infosystems.www.servers.unix"
+ ><SAMP>comp.infosystems.www.servers.unix</SAMP></A>
+ newsgroup. Many Apache users, and some of the developers, can be
+ found roaming its 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://www.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>
+ <P>
+ <DL>
+ <DD><CODE># cd <EM>ServerRoot</EM><BR>
+ # dbx httpd core<BR>
+ (dbx) where</CODE>
+ </DD>
+ </DL>
+ <P></P>
+ <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 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 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>
+ <HR>
+ </LI>
+
+ <LI><A 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://www.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>new-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 -c</CODE>' or '<CODE>diff -u</CODE>' against
+ the latest CVS tree. To submit your patch, send email to
+ <SAMP>new-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
+ incorporate all changes and suggestions.
+ </P>
+ <HR>
+ </LI>
+
+ <LI><A 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 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 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><<A HREF="http://www.apache.org/LICENSE.txt"
+ >http://www.apache.org/LICENSE.txt</A>></SAMP>.
+ </P>
+ <HR>
+ </LI>
+
+ <LI><A 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="http://www.apache.org/docs/misc/perf-tuning.html"
+ >performance tuning page</A>.
+ </P>
+ <HR>
+ </LI>
+
+ <LI><A 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 "regexp"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 regexp 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/CPAN-local/doc/manual/html/pod/perlre.html#Version_8_Regular_Expresions"
+ >CPAN page on regular expressions</A>, and branching out from
+ there.
+ </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 -->
--- /dev/null
+<!--#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.1 $ ($Date: 1999/06/24 15:02:51 $)
+ </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="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>
+<!--#endif -->
+<!--#if expr="$STANDALONE" -->
+</OL>
+
+<HR>
+
+ <H2>The Answers</H2>
+<!--#endif -->
+<!--#if expr="! $TOC" -->
+
+ <H3>C. Building Apache</H3>
+<OL>
+
+ <LI><A 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>
+ <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>
+ <P></P>
+ <HR>
+ </LI>
+
+ <LI><A 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://www.apache.org/bug_report.html">problem report</A>.
+ Be sure to include <EM>complete</EM> details, such as the compiler
+ & OS versions and exact error messages.
+ </P>
+ <HR>
+ </LI>
+
+ <LI><A 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>
+ <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>
+ <P></P>
+ <HR>
+ </LI>
+
+ <LI><A 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 behaviour 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 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>
+<!--#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 -->
--- /dev/null
+<!--#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.1 $ ($Date: 1999/06/24 15:02:51 $)
+ </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="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 </Directory>
+ but saw </Directory></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>
+ </OL>
+ </LI>
+<!--#endif -->
+<!--#if expr="$STANDALONE" -->
+</OL>
+
+<HR>
+
+ <H2>The Answers</H2>
+<!--#endif -->
+<!--#if expr="! $TOC" -->
+
+ <H3>D. Error Log Messages and Problems Starting Apache</H3>
+<OL>
+
+ <LI><A 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 #-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 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 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 experiences this more than
+ high-capacity ones or those with large pipes to the network.
+ </P>
+ <HR>
+ </LI>
+
+ <LI><A 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 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.linuxhq.com/HOWTO/Kernel-HOWTO.html" >Kernel
+ HOWTO</A>, or the documentation provided with your distribution, or
+ a <A HREF="http://www.linuxhq.com/HOWTO/META-FAQ.html" >Linux
+ newsgroup/mailing list</A>. As a last-resort workaround, you can
+ comment out the <CODE>#define 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 HAVE_SHMGET</CODE> would have
+ sufficed). This will produce a server which is slower and less
+ reliable.
+ </P>
+ <HR>
+ </LI>
+
+ <LI><A 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 NAME="aixccbug"><STRONG>Why am I getting "<SAMP>Expected
+ </Directory> but saw </Directory></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 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 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>
+</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 -->
--- /dev/null
+<!--#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.1 $ ($Date: 1999/06/24 15:02:52 $)
+ </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>
+ </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>
+</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 -->
--- /dev/null
+<!--#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.1 $ ($Date: 1999/06/24 15:02:52 $)
+ </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="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>
+ </OL>
+ </LI>
+<!--#endif -->
+<!--#if expr="$STANDALONE" -->
+</OL>
+
+<HR>
+
+ <H2>The Answers</H2>
+<!--#endif -->
+<!--#if expr="! $TOC" -->
+
+ <H3>F. Dynamic Content (CGI and SSI)</H3>
+<OL>
+
+ <LI><A 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>
+ <P>
+ <OL>
+ <LI>In an appropriate section of your server configuration files, add
+ a line such as
+ <P>
+ <DL>
+ <DD><CODE>AddHandler cgi-script .cgi</CODE>
+ </DD>
+ </DL>
+ <P></P>
+ <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></P>
+ <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>
+ <P>
+ <OL>
+ <LI>Locally add to the corresponding <SAMP>.htaccess</SAMP> file a ruleset
+ similar to this one:
+ <P>
+ <DL>
+ <DD><CODE>RewriteEngine on
+ <BR>
+ RewriteBase /~foo/bar/
+ <BR>
+ RewriteRule ^quux\.cgi$ - [T=application/x-httpd-cgi]</CODE>
+ </DD>
+ </DL>
+ <P></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> and
+ <SAMP>FollowSymLinks</SAMP> option.
+ </LI>
+ </OL>
+ <P></P>
+ <HR>
+ </LI>
+
+ <LI><A 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.
+ </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>
+ <P>
+ <DL>
+ <DD><CODE>{<BR>
+ local ($oldbar) = $|;<BR>
+ $cfh = select (STDOUT);<BR>
+ $| = 1;<BR>
+ #<BR>
+ # print your HTTP headers here<BR>
+ #<BR>
+ $| = $oldbar;<BR>
+ select ($cfh);<BR>
+ }</CODE>
+ </DD>
+ </DL>
+ <P></P>
+ <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>
+ <HR>
+ </LI>
+
+ <LI><A 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 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 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
+ <<A HREF="http://hoohoo.ncsa.uiuc.edu/cgi/interface.html">
+ <SAMP>http://hoohoo.ncsa.uiuc.edu/cgi/interface.html</SAMP></A>>.
+ 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
+ <<A HREF="http://web.golux.com/coar/cgi/"
+ ><SAMP>http://web.golux.com/coar/cgi/</SAMP></A>>.
+ </P>
+ <HR>
+ </LI>
+
+ <LI><A 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 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 <EM>extremely</EM>
+ resource-consumptive, 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:
+ <P>
+ <DL>
+ <DD><CODE>AddHandler server-parsed .shtml</CODE>
+ </DD>
+ </DL>
+ <P></P>
+ <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 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 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 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 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 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>
+
+</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 -->
--- /dev/null
+<!--#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.1 $ ($Date: 1999/06/24 15:02:52 $)
+ </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="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>
+ </OL>
+ </LI>
+<!--#endif -->
+<!--#if expr="$STANDALONE" -->
+</OL>
+
+<HR>
+
+ <H2>The Answers</H2>
+<!--#endif -->
+<!--#if expr="! $TOC" -->
+ <H3>G. Authentication and Access Restrictions</H3>
+<OL>
+
+ <LI><A 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:
+ <P>
+ <DL>
+ <DD><CODE>EXTRA_CFLAGS=-DMAXIMUM_DNS</CODE>
+ </DD>
+ </DL>
+ <P></P>
+ <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 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>.
+ </P>
+ <HR>
+ </LI>
+
+ <LI><A 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>
+ <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></P>
+ <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 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 /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 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 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 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>
+</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 -->
--- /dev/null
+<!--#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.1 $ ($Date: 1999/06/24 15:02:52 $)
+ </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="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>
+<!--#endif -->
+<!--#if expr="$STANDALONE" -->
+</OL>
+
+<HR>
+
+ <H2>The Answers</H2>
+<!--#endif -->
+<!--#if expr="! $TOC" -->
+
+ <H3>H. URL Rewriting</H3>
+<OL>
+
+ <LI><A 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
+ <A HREF="http://www.engelschall.com/pw/apache/rewriteguide/"
+ >Practical Solutions for URL-Manipulation</A>
+ where you can
+ find all typical solutions the author of
+ <A HREF="../mod/mod_rewrite.html"><SAMP>mod_rewrite</SAMP></A>
+ currently knows of. 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 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
+ <<A HREF="http://www.heise.de/ix/artikel/9612149/"
+ >http://www.heise.de/ix/artikel/9612149/</A>>,
+ the English (translated) version can be found at
+ <<A HREF="http://www.heise.de/ix/artikel/E/9612149/"
+ >http://www.heise.de/ix/artikel/E/9612149/</A>>.
+ </P>
+ <HR>
+ </LI>
+
+ <LI><A 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 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 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 behaviour looks ugly, but is
+ really important for some other aspects of URL rewriting.
+ </P>
+ <HR>
+ </LI>
+
+ <LI><A NAME="rewrite-nocase">
+ <STRONG>How can I make all my URLs case-insensitive with mod_rewrite?
+ </STRONG>
+ </A>
+ <P>
+ You can't! The reason is: First, case translations for arbitrary
+ length URLs cannot be done <EM>via</EM> regex patterns and
+ corresponding substitutions. One need a per-character pattern like
+ sed/Perl <SAMP>tr|..|..|</SAMP> feature. Second, just making URLs
+ always upper or lower case will not resolve the complete problem of
+ case-INSENSITIVE URLs, because actually the URLs had to be rewritten
+ to the correct case-variant residing on the filesystem because in
+ later processing Apache needs to access the file. And Unix
+ filesystem is always case-SENSITIVE.
+ </P>
+ <P>
+ But there is a module named <CODE>mod_speling.c</CODE> (yes, it is named
+ this way!) out there on the net. Try this one.
+ </P>
+ <HR>
+ </LI>
+
+ <LI><A 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 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>
+<!--#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 -->
--- /dev/null
+<!--#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.1 $ ($Date: 1999/06/24 15:02:52 $)
+ </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><STRONG>I. 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>
+ </OL>
+ </LI>
+<!--#endif -->
+<!--#if expr="$STANDALONE" -->
+</OL>
+
+<HR>
+
+ <H2>The Answers</H2>
+<!--#endif -->
+<!--#if expr="! $TOC" -->
+
+ <H3>I. Features</H3>
+<OL>
+
+ <LI><A 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 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 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 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://www.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>
+</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 -->
<HTML>
<HEAD>
<TITLE>Apache Server Frequently Asked Questions</TITLE>
+<!--#set var="FAQMASTER" value="YES" -->
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
<!--#include virtual="header.html" -->
<H1 ALIGN="CENTER">Apache Server Frequently Asked Questions</H1>
<P>
- $Revision: 1.144 $ ($Date: 1999/05/27 16:49:26 $)
+ $Revision: 1.145 $ ($Date: 1999/06/24 15:02:53 $)
</P>
<P>
The latest version of this FAQ is always available from the main
<!-- - '400 malformed request' on Win32 might mean stale proxy; see -->
<!-- PR #2300. -->
<!-- - how do I tell what version of Apache I am running? -->
-<UL>
- <LI><STRONG>A. Background</STRONG>
- <OL>
- <LI><A HREF="#what">What is Apache?</A>
- </LI>
- <LI><A HREF="#why">Why was Apache created?</A>
- </LI>
- <LI><A HREF="#relate">How does The Apache Group's work relate to
- other servers?</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>
- </OL>
- </LI>
- <LI><STRONG>B. 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>
- </OL>
- </LI>
- <LI><STRONG>C. 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>
-
- <LI><STRONG>D. 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 </Directory>
- but saw </Directory></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>
- </OL>
- </LI>
-
- <LI><STRONG>E. 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>
- </OL>
- </LI>
-
- <LI><STRONG>F. 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>
- </OL>
- </LI>
- <LI><STRONG>G. 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>
- </OL>
- </LI>
- <LI><STRONG>H. 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>
- <LI><STRONG>I. 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>
- </OL>
- </LI>
-</UL>
+<OL TYPE="A">
+<!--#include virtual="FAQ-A.html?TOC" -->
+<!--#include virtual="FAQ-B.html?TOC" -->
+<!--#include virtual="FAQ-C.html?TOC" -->
+<!--#include virtual="FAQ-D.html?TOC" -->
+<!--#include virtual="FAQ-E.html?TOC" -->
+<!--#include virtual="FAQ-F.html?TOC" -->
+<!--#include virtual="FAQ-G.html?TOC" -->
+<!--#include virtual="FAQ-H.html?TOC" -->
+<!--#include virtual="FAQ-I.html?TOC" -->
+</OL>
<HR>
<H2>The Answers</H2>
- <H3>A. Background</H3>
-<OL>
- <LI><A NAME="what">
- <STRONG>What is Apache?</STRONG>
- </A>
- <P>
- Apache was originally based on code and ideas found in the most
- popular HTTP server of the time.. NCSA httpd 1.3 (early 1995). It has
- since evolved into a far superior system which can rival (and probably
- surpass) almost any other UNIX based HTTP server in terms of functionality,
- efficiency and speed.
- </P>
- <P>
- Since it began, it has been completely rewritten, and includes many new
- features. Apache is, as of January 1997, the most popular WWW server on
- the Internet, according to the
- <A HREF="http://www.netcraft.com/Survey/">Netcraft Survey</A>.
- </P>
- <HR>
- </LI>
-
- <LI><A NAME="why">
- <STRONG>Why was Apache created?</STRONG>
- </A>
- <P>
- To address the concerns of a group of WWW providers and part-time httpd
- programmers that httpd didn't behave as they wanted it to behave.
- Apache is an entirely volunteer effort, completely funded by its
- members, not by commercial sales.
- </P>
- <HR>
- </LI>
-
- <LI><A NAME="relate">
- <STRONG>How does The Apache Group's work relate to other
- server efforts, such as NCSA's?</STRONG>
- </A>
- <P>
- We, of course, owe a great debt to NCSA and their programmers for
- making the server Apache was based on. We now, however, have our own
- server, and our project is mostly our own. The Apache Project is an
- entirely independent venture.
- </P>
- <HR>
- </LI>
-
- <LI><A NAME="name">
- <STRONG>Why the name "Apache"?</STRONG>
- </A>
- <P>
- A 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 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/chart.html">Web Compare</A>'s
- comparison chart.
- </P>
- <P>
- Apache has been shown to be substantially faster than many other
- free 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 NAME="tested">
- <STRONG>How thoroughly tested is Apache?</STRONG>
- </A>
- <P>
- Apache is run on over 1.2 million Internet servers (as of July 1998). 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>
- <P>
- The Apache project's web site includes a page with a partial list of
- <A HREF="http://www.apache.org/info/apache_users.html">sites running
- Apache</A>.
- </P>
- <HR>
- </LI>
-
- <LI><A NAME="future">
- <STRONG>What are the future plans for Apache?</STRONG>
- </A>
- <P>
- <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>
- <P></P>
- <HR>
- </LI>
-
- <LI><A 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://www.apache.org/bug_report.html">the bug report page</A>.
- Other questions should be directed to 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 NAME="more">
- <STRONG>Is there any more information available on
- Apache?</STRONG>
- </A>
- <P>
- Indeed there is. See the main
- <A HREF="http://www.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://www.apache.org/info/apache_books.html"
- >Apache-specific books</A> available.
- </P>
- <HR>
- </LI>
-
- <LI><A 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://www.apache.org/">main web page</A>.
- </P>
- <HR>
- </LI>
-</OL>
-
- <H3>B. General Technical Questions</H3>
-<OL>
-
- <LI><A 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
- & 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://www.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 the <SAMP>comp.infosystems.www.servers.unix</SAMP>
- or <SAMP>comp.infosystems.www.servers.ms-windows</SAMP> USENET
- newsgroup (as appropriate for the platform you use).</STRONG>
- <P>
- A lot of common problems never make it to the bug database because
- there's already high Q&A traffic about them in the
- <A HREF="news:comp.infosystems.www.servers.unix"
- ><SAMP>comp.infosystems.www.servers.unix</SAMP></A>
- newsgroup. Many Apache users, and some of the developers, can be
- found roaming its 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://www.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>
- <P>
- <DL>
- <DD><CODE># cd <EM>ServerRoot</EM><BR>
- # dbx httpd core<BR>
- (dbx) where</CODE>
- </DD>
- </DL>
- <P></P>
- <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 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 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>
- <HR>
- </LI>
-
- <LI><A 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://www.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>new-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 -c</CODE>' or '<CODE>diff -u</CODE>' against
- the latest CVS tree. To submit your patch, send email to
- <SAMP>new-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
- incorporate all changes and suggestions.
- </P>
- <HR>
- </LI>
-
- <LI><A 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 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 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><<A HREF="http://www.apache.org/LICENSE.txt"
- >http://www.apache.org/LICENSE.txt</A>></SAMP>.
- </P>
- <HR>
- </LI>
-
- <LI><A 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="http://www.apache.org/docs/misc/perf-tuning.html"
- >performance tuning page</A>.
- </P>
- <HR>
- </LI>
-
- <LI><A 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 "regexp"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 regexp 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/CPAN-local/doc/manual/html/pod/perlre.html#Version_8_Regular_Expresions"
- >CPAN page on regular expressions</A>, and branching out from
- there.
- </P>
- <HR>
- </LI>
-</OL>
-
- <H3>C. Building Apache</H3>
-<OL>
-
- <LI><A 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>
- <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>
- <P></P>
- <HR>
- </LI>
-
- <LI><A 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://www.apache.org/bug_report.html">problem report</A>.
- Be sure to include <EM>complete</EM> details, such as the compiler
- & OS versions and exact error messages.
- </P>
- <HR>
- </LI>
-
- <LI><A 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>
- <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>
- <P></P>
- <HR>
- </LI>
-
- <LI><A 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 behaviour 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 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>
-
-
- <H3>D. Error Log Messages and Problems Starting Apache</H3>
-<OL>
-
- <LI><A 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 #-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 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 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 experiences this more than
- high-capacity ones or those with large pipes to the network.
- </P>
- <HR>
- </LI>
-
- <LI><A 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 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.linuxhq.com/HOWTO/Kernel-HOWTO.html" >Kernel
- HOWTO</A>, or the documentation provided with your distribution, or
- a <A HREF="http://www.linuxhq.com/HOWTO/META-FAQ.html" >Linux
- newsgroup/mailing list</A>. As a last-resort workaround, you can
- comment out the <CODE>#define 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 HAVE_SHMGET</CODE> would have
- sufficed). This will produce a server which is slower and less
- reliable.
- </P>
- <HR>
- </LI>
-
- <LI><A 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 NAME="aixccbug"><STRONG>Why am I getting "<SAMP>Expected
- </Directory> but saw </Directory></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 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 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>
-
-</OL>
-
- <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>
-</OL>
-
- <H3>F. Dynamic Content (CGI and SSI)</H3>
-<OL>
-
- <LI><A 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>
- <P>
- <OL>
- <LI>In an appropriate section of your server configuration files, add
- a line such as
- <P>
- <DL>
- <DD><CODE>AddHandler cgi-script .cgi</CODE>
- </DD>
- </DL>
- <P></P>
- <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></P>
- <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>
- <P>
- <OL>
- <LI>Locally add to the corresponding <SAMP>.htaccess</SAMP> file a ruleset
- similar to this one:
- <P>
- <DL>
- <DD><CODE>RewriteEngine on
- <BR>
- RewriteBase /~foo/bar/
- <BR>
- RewriteRule ^quux\.cgi$ - [T=application/x-httpd-cgi]</CODE>
- </DD>
- </DL>
- <P></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> and
- <SAMP>FollowSymLinks</SAMP> option.
- </LI>
- </OL>
- <P></P>
- <HR>
- </LI>
-
- <LI><A 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.
- </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>
- <P>
- <DL>
- <DD><CODE>{<BR>
- local ($oldbar) = $|;<BR>
- $cfh = select (STDOUT);<BR>
- $| = 1;<BR>
- #<BR>
- # print your HTTP headers here<BR>
- #<BR>
- $| = $oldbar;<BR>
- select ($cfh);<BR>
- }</CODE>
- </DD>
- </DL>
- <P></P>
- <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>
- <HR>
- </LI>
-
- <LI><A 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 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 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
- <<A HREF="http://hoohoo.ncsa.uiuc.edu/cgi/interface.html">
- <SAMP>http://hoohoo.ncsa.uiuc.edu/cgi/interface.html</SAMP></A>>.
- 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
- <<A HREF="http://web.golux.com/coar/cgi/"
- ><SAMP>http://web.golux.com/coar/cgi/</SAMP></A>>.
- </P>
- <HR>
- </LI>
-
- <LI><A 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 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 <EM>extremely</EM>
- resource-consumptive, 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:
- <P>
- <DL>
- <DD><CODE>AddHandler server-parsed .shtml</CODE>
- </DD>
- </DL>
- <P></P>
- <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 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 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 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 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 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>
-
-</OL>
-
- <H3>G. Authentication and Access Restrictions</H3>
-<OL>
-
- <LI><A 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:
- <P>
- <DL>
- <DD><CODE>EXTRA_CFLAGS=-DMAXIMUM_DNS</CODE>
- </DD>
- </DL>
- <P></P>
- <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 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>.
- </P>
- <HR>
- </LI>
-
- <LI><A 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>
- <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></P>
- <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 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 /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 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 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 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>
-</OL>
-
- <H3>H. URL Rewriting</H3>
-<OL>
-
- <LI><A 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
- <A HREF="http://www.engelschall.com/pw/apache/rewriteguide/"
- >Practical Solutions for URL-Manipulation</A>
- where you can
- find all typical solutions the author of
- <A HREF="../mod/mod_rewrite.html"><SAMP>mod_rewrite</SAMP></A>
- currently knows of. 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 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
- <<A HREF="http://www.heise.de/ix/artikel/9612149/"
- >http://www.heise.de/ix/artikel/9612149/</A>>,
- the English (translated) version can be found at
- <<A HREF="http://www.heise.de/ix/artikel/E/9612149/"
- >http://www.heise.de/ix/artikel/E/9612149/</A>>.
- </P>
- <HR>
- </LI>
-
- <LI><A 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 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 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 behaviour looks ugly, but is
- really important for some other aspects of URL rewriting.
- </P>
- <HR>
- </LI>
-
- <LI><A NAME="rewrite-nocase">
- <STRONG>How can I make all my URLs case-insensitive with mod_rewrite?
- </STRONG>
- </A>
- <P>
- You can't! The reason is: First, case translations for arbitrary
- length URLs cannot be done <EM>via</EM> regex patterns and
- corresponding substitutions. One need a per-character pattern like
- sed/Perl <SAMP>tr|..|..|</SAMP> feature. Second, just making URLs
- always upper or lower case will not resolve the complete problem of
- case-INSENSITIVE URLs, because actually the URLs had to be rewritten
- to the correct case-variant residing on the filesystem because in
- later processing Apache needs to access the file. And Unix
- filesystem is always case-SENSITIVE.
- </P>
- <P>
- But there is a module named <CODE>mod_speling.c</CODE> (yes, it is named
- this way!) out there on the net. Try this one.
- </P>
- <HR>
- </LI>
-
- <LI><A 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 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>
-
- <H3>I. Features</H3>
-<OL>
-
- <LI><A 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 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 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 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://www.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>
-</OL>
- <!-- Don't forget to add HR tags at the end of each list item.. -->
+<!--#include virtual="FAQ-A.html?" -->
+<!--#include virtual="FAQ-B.html?" -->
+<!--#include virtual="FAQ-C.html?" -->
+<!--#include virtual="FAQ-D.html?" -->
+<!--#include virtual="FAQ-E.html?" -->
+<!--#include virtual="FAQ-F.html?" -->
+<!--#include virtual="FAQ-G.html?" -->
+<!--#include virtual="FAQ-H.html?" -->
+<!--#include virtual="FAQ-I.html?" -->
<!--#include virtual="footer.html" -->
</BODY>
projects / thirdparty / apache / httpd.git / commitdiff
