346N/A<!--#if expr="$FAQMASTER" --> 346N/A <!--#set var="STANDALONE" value="" --> 346N/A <!--#set var="INCLUDED" value="YES" --> 346N/A <!--#if expr="$QUERY_STRING = TOC" --> 346N/A <!--#set var="TOC" value="YES" --> 346N/A <!--#set var="CONTENT" value="" --> 346N/A <!--#set var="TOC" value="" --> 346N/A <!--#set var="CONTENT" value="YES" --> 346N/A <!--#set var="STANDALONE" value="YES" --> 346N/A <!--#set var="INCLUDED" value="" --> 346N/A <!--#set var="TOC" value="" --> 346N/A <!--#set var="CONTENT" value="" --> 346N/A<!--#if expr="$STANDALONE" --> 346N/A<!
DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
346N/A <
TITLE>Apache Server Frequently Asked Questions</
TITLE>
5425N/A<!-- Background white, links blue (unvisited), navy (visited), red (active) --> 1244N/A <
H1 ALIGN="CENTER">Apache Server Frequently Asked Questions</
H1>
844N/A The latest version of this FAQ is always available from the main
4162N/A<!-- Notes about changes: --> 844N/A<!-- - If adding a relative link to another part of the --> 4162N/A<!-- documentation, *do* include the ".html" portion. There's a --> 618N/A<!-- good chance that the user will be reading the documentation --> 4194N/A<!-- on his own system, which may not be configured for --> 346N/A<!-- - When adding items, make sure they're put in the right place --> 346N/A<!-- - verify that the numbering matches up. --> 346N/A<!-- - *Don't* use <PRE></PRE> blocks - they don't appear --> 346N/A<!-- correctly in a reliable way when this is converted to text --> 4162N/A<!-- with Lynx. Use <DL><DD><CODE>xxx<BR>xx</CODE></DD></DL> --> 844N/A<!-- blocks inside a <P></P> instead. This is necessary to get --> 4162N/A<!-- the horizontal and vertical indenting right. --> 618N/A<!-- - Don't forget to include an HR tag after the last /P tag --> 4194N/A<!-- but before the /LI in an item. --> 346N/A If you are reading a text-only version of this FAQ, you may find numbers
3083N/A enclosed in brackets (such as "[12]"). These refer to the list of
3083N/A reference URLs to be found at the end of the document. These references
5680N/A do not appear, and are not needed, for the hypertext version.
5680N/A<!--#if expr="$TOC || $STANDALONE" --> 6453N/A <
LI value="2"><
STRONG>General Technical Questions</
STRONG>
346N/A <
LI><
A HREF="#what2do">"Why can't I ...? Why won't ...
346N/A work?" What to do in case of problems</
A>
1358N/A <
LI><
A HREF="#compatible">How compatible is Apache with my existing
346N/A <
LI><
A HREF="#year2000">Is Apache Year 2000 compliant?</
A>
346N/A <
LI><
A HREF="#submit_patch">How do I submit a patch to the Apache Group?</
A>
351N/A <
LI><
A HREF="#domination">Why has Apache stolen my favourite site's
4162N/A <
LI><
A HREF="#apspam">Why am I getting spam mail from the Apache site?</
A>
351N/A <
LI><
A HREF="#redist">May I include the Apache software on a CD or other
4162N/A package I'm distributing?</
A>
6453N/A I get the most out of my Apache Web server?</
A>
6453N/A <
LI><
A HREF="#regex">What are "regular expressions"?</
A>
6453N/A <
li><
a href="#binaries">Why isn't there a binary for my platform?</
a></
li>
6453N/A<!--#if expr="$STANDALONE" --> 2497N/A <
H3>B. General Technical Questions</
H3>
3958N/A <
STRONG>"Why can't I ...? Why won't ... work?" What to
3958N/A do in case of problems</
STRONG>
4760N/A If you are having trouble with your Apache server software, you should
5680N/A <
LI><
STRONG>Check the errorlog!</
STRONG>
4337N/A Apache tries to be helpful when it encounters a problem. In many
6453N/A cases, it will provide some details by writing one or messages to
3817N/A the server error log. Sometimes this is enough for you to diagnose
3817N/A & fix the problem yourself (such as file permissions or the like).
6453N/A The default location of the error log is
3817N/A directive in your config files for the location on your server.
The latest version of the Apache Frequently-Asked Questions list can
always be found at the main Apache web site.
<
LI><
STRONG>Check the Apache bug database</
STRONG>
Most problems that get reported to The Apache Group are recorded in
<
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
newsgroup (as appropriate for the platform you use).</
STRONG>
A lot of common problems never make it to the bug database because
there's already high Q&A traffic about them in the
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.
<
LI><
STRONG>If all else fails, report the problem in the bug
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
If your problem involves the server crashing and generating a core
dump, please include a backtrace (if possible). As an example,
<
DD><
CODE># cd <
EM>ServerRoot</
EM><
BR>
(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>.)
<
LI><
A NAME="compatible">
<
STRONG>How compatible is Apache with my existing NCSA 1.3
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.
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.
Friendly interaction between Apache and NCSA developers should ensure
that fundamental feature enhancements stay consistent between the two
servers for the foreseeable future.
<
STRONG>Is Apache Year 2000 compliant?</
STRONG>
Yes, Apache is Year 2000 compliant.
Apache internally never stores years as two digits.
On the HTTP protocol level RFC1123-style addresses are generated
generate. To be compatible with older applications Apache
recognizes ANSI C's <
CODE>asctime()</
CODE> and
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>.
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
The Apache HTTP Server project is an open-source software product of
the Apache Software Foundation. The project and the Foundation
<
b>cannot</
b> offer legal assurances regarding any suitability
of the software for your application. There are several commercial
Apache support organizations and derivative server products available
that may be able to stand behind the software and provide you with
any assurances you may require. You may find links to some of these
The Apache HTTP server software is distributed with the following
disclaimer, found in the software license:
THIS SOFTWARE IS PROVIDED BY THE APACHE GROUP ``AS IS'' AND ANY
EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE GROUP OR
ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
OF THE POSSIBILITY OF SUCH DAMAGE.
<
LI><
A NAME="submit_patch">
<
STRONG>How do I submit a patch to the Apache Group?</
STRONG></
A>
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 Improvements, modifications, and additions should follow the
In general, the first course of action is to be a member of the
<
SAMP>dev@httpd.apache.org</
SAMP> mailing list. This indicates to
the Group that you are closely following the latest Apache
developments. Your patch file should be generated using either
'<
CODE>diff -c</
CODE>' or '<
CODE>diff -u</
CODE>' against
the latest CVS tree. To submit your patch, send email to
<
SAMP>dev@httpd.apache.org</
SAMP> with a <
SAMP>Subject:</
SAMP> line
that starts with <
SAMP>[PATCH]</
SAMP> and includes a general
description of the patch. In the body of the message, the patch
should be clearly described and then included at the end of the
message. If the patch-file is long, you can note a URL to the file
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.
<
LI><
A NAME="domination"><
STRONG>Why has Apache stolen my favourite site's
Internet address?</
STRONG></
A>
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.
<
LI><
A NAME="apspam"><
STRONG>Why am I getting spam mail from the
Apache site?</
STRONG></
A>
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
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.
<
LI><
A NAME="redist"><
STRONG>May I include the Apache software on a
CD or other package I'm distributing?</
STRONG></
A>
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
I get the most out of my Apache Web server?</
STRONG>
<
STRONG>What are "regular expressions"?</
STRONG></
A>
Regular expressions are a way of describing a pattern - for example, "all
the words that begin with the letter A" or "every 10-digit phone number"
or even "Every sentence with two commas in it, and no capital letter Q".
Regular expressions (aka "regex"s) are useful in Apache because they
let you apply certain attributes against collections of files or resources
in very flexible ways - for example, all .gif and .jpg files under
any "images" directory could be written as /\/images\/.*(jpg|gif)$/.
The best overview around is probably the one which comes with Perl.
We implement a simple subset of Perl's regex support, but it's
still a good way to learn what they mean. You can start by going
>CPAN page on regular expressions</
A>, and branching out from
<
b>Why isn't there a binary for my platform?</
b></
a>
The developers make sure that the software builds and works
correctly on the platforms available to them; this does
<
i>not</
i> necessarily mean that <
i>your</
i> platform
is one of them. In addition, the Apache HTTP server project
is primarily source oriented, meaning that distributing
valid and buildable source code is the purpose of a release,
not making sure that there is a binary package for all of the
If you don't see a kit for your platform listed in the
it means either that the platform isn't available to any of
the developers, or that they just haven't gotten around to
preparing a binary for it. As this is a voluntary project,
they are under no obligation to do so. Users are encouraged
and expected to build the software themselves.
The sole exception to these practices is the Windows package.
Unlike most Unix and Unix-like platforms, Windows systems
do not come with a bundled software development environment,
so we <
i>do</
i> prepare binary kits for Windows when we make
a release. Again, however, it's a voluntary thing and only
a limited number of the developers have the capability to build
the InstallShield package, so the Windows release may lag
somewhat behind the source release. This lag should be
no more than a few days at most.
<!--#if expr="$STANDALONE" --> <!-- Don't forget to add HR tags at the end of each list item.. -->