Apache HTTP Server Version 1.3

Apache Server Frequently Asked Questions

The latest version of this FAQ is always available from the main Apache web site, at <http://httpd.apache.org/docs/misc/FAQ.html>.

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.

The Questions

Background
General Technical Questions
Building Apache
Error Log Messages and Problems Starting Apache
Configuration Questions
Dynamic Content (CGI and SSI)
Authentication and Access Restrictions
URL Rewriting
Features

The Answers

A. Background

What is Apache?
The Apache httpd server
- is a powerful, flexible, HTTP/1.1 compliant web server
- implements the latest protocols, including HTTP/1.1 (RFC2616)
- is highly configurable and extensible with third-party modules
- can be customised by writing 'modules' using the Apache module API
- provides full source code and comes with an unrestrictive license
- runs on Windows NT/9x, Netware 5.x and above, OS/2, and most versions of Unix, as well as several other operating systems
- is actively being developed
- encourages user feedback through new ideas, bug reports and patches
- implements many frequently requested features, including:
  
  DBM databases for authentication
  
  allows you to easily set up password-protected pages with enormous numbers of authorized users, without bogging down the server.
  
  Customized responses to errors and problems
  
  Allows you to set up files, or even CGI scripts, which are returned by the server in response to errors and problems, e.g. setup a script to intercept 500 Server Errors and perform on-the-fly diagnostics for both users and yourself.
  
  Multiple DirectoryIndex directives
  
  Allows you to say DirectoryIndex index.html index.cgi, which instructs the server to either send back index.html or run index.cgi when a directory URL is requested, whichever it finds in the directory.
  
  Unlimited flexible URL rewriting and aliasing
  
  Apache has no fixed limit on the numbers of Aliases and Redirects which may be declared in the config files. In addition, a powerful rewriting engine can be used to solve most URL manipulation problems.
  
  Content negotiation
  
  i.e. the ability to automatically serve clients of varying sophistication and HTML level compliance, with documents which offer the best representation of information that the client is capable of accepting.
  
  Virtual Hosts
  
  A much requested feature, sometimes known as multi-homed servers. This allows the server to distinguish between requests made to different IP addresses or names (mapped to the same machine). Apache also offers dynamically configurable mass-virtual hosting.
  
  Configurable Reliable Piped Logs
  
  You can configure Apache to generate logs in the format that you want. In addition, on most Unix architectures, Apache can send log files to a pipe, allowing for log rotation, hit filtering, real-time splitting of multiple vhosts into separate logs, and asynchronous DNS resolving on the fly.
How and why was Apache created?
The About Apache document explains how the Apache project evolved from its beginnings as an outgrowth of the NCSA httpd project to its current status as one of the fastest, most efficient, and most functional web servers in existence.
Why the name "Apache"?
A cute name which stuck. Apache is "A PAtCHy server". It was based on some existing code and a series of "patch files".

For many developers it is also a reverent connotation to the Native American Indian tribe of Apache, well-known for their superior skills in warfare strategy and inexhaustible endurance. For more information on the Apache Nation, we suggest searching Google, Northernlight, or AllTheWeb.
OK, so how does Apache compare to other servers?
For an independent assessment, see Web Compare.

Apache has been shown to be substantially faster, more stable, and more feature-full than many other web servers. Although certain commercial servers have claimed to surpass Apache's speed (it has not been demonstrated that any of these "benchmarks" are a good way of measuring WWW server speed at any rate), we feel that it is better to have a mostly-fast free server than an extremely-fast server that costs thousands of dollars. Apache is run on sites that get millions of hits per day, and they have experienced no performance difficulties.
How thoroughly tested is Apache?
Apache is run on over 6 million Internet servers (as of February 2000). It has been tested thoroughly by both developers and users. The Apache Group maintains rigorous standards before releasing new versions of their server, and our server runs without a hitch on over one half of all WWW servers available on the Internet. When bugs do show up, we release patches and new versions as soon as they are available.
What are the future plans for Apache?
- to continue to be an "open source" no-charge-for-use HTTP server,
- to keep up with advances in HTTP protocol and web developments in general,
- to collect suggestions for fixes/improvements from its users,
- to respond to needs of large volume providers as well as occasional users.
Whom do I contact for support?
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 via the bug report page. Other questions should be directed to the Apache HTTP Server Users List or the comp.infosystems.www.servers.unix or comp.infosystems.www.servers.ms-windows 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.

Commercial support for Apache is, however, available from a number of third parties.
Is there any more information available on Apache?
Indeed there is. See the main Apache web site. There is also a regular electronic publication called Apache Week available. Links to relevant Apache Week articles are included below where appropriate. There are also some Apache-specific books available.
Where can I get Apache?
You can find out how to download the source for Apache at the project's main web page.
May I use the Apache logo on my product or Web site?
You may NOT use any original artwork from the Apache Software Foundation, nor make or use modified versions of such artwork, except under the following conditions:
- You may use the 'Powered by Apache' graphic on a Web site that is being served by the Apache HTTP server software.
- You may use the aforementioned 'Powered by Apache' graphic or the Apache Software Foundation logo in product description and promotional material IF and ONLY IF such use can in no way be interpreted as anything other than an attribution. Using the Apache name and artwork in a manner that implies endorsement of a product or service is strictly forbidden.

B. General Technical Questions

"Why can't I ...? Why won't ... work?" What to do in case of problems
If you are having trouble with your Apache server software, you should take the following steps:
1. Check the errorlog!
  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 /usr/local/apache/logs/error_log, but see the ErrorLog directive in your config files for the location on your server.
2. Check the FAQ!
  The latest version of the Apache Frequently-Asked Questions list can always be found at the main Apache web site.
3. Check the Apache bug database
  Most problems that get reported to The Apache Group are recorded in the bug database. Please check the existing reports, open and closed, before adding one. If you find that your issue has already been reported, please don't 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.
4. Ask in a user support group.
  A lot of common problems never make it to the bug database because there's already high Q&A traffic about them in the Users mailing list or comp.infosystems.www.servers.unix and related newsgroups. These newsgroups are also available via Google. Many Apache users, and some of the developers, can be found roaming their virtual halls, so it is suggested that you seek wisdom there. The chances are good that you'll get a faster answer there than from the bug database, even if you don't see your question already posted.
5. If all else fails, report the problem in the bug database
  If you've gone through those steps above that are appropriate and have obtained no relief, then please do let The Apache Group know about the problem by logging a bug report.
  
  If your problem involves the server crashing and generating a core dump, please include a backtrace (if possible). As an example,
  
  # cd ServerRoot # dbx httpd core (dbx) where
  
  (Substitute the appropriate locations for your ServerRoot and your httpd and core files. You may have to use gdb instead of dbx.)
How compatible is Apache with my existing NCSA 1.3 setup?
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.
Is Apache Year 2000 compliant?
Yes, Apache is Year 2000 compliant.

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 asctime() and RFC850-/RFC1036-style date formats, too. The asctime() 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 20 rather than 19.

Although Apache is Year 2000 compliant, you may still get problems if the underlying OS has problems with dates past year 2000 (e.g., 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^st 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.

Users of Apache 1.2.x should upgrade to a current version of Apache 1.3 (see year-2000 improvements in Apache 1.3 for details).

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

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.
 
```
How do I submit a patch to the Apache Group?
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 bug report page. Improvements, modifications, and additions should follow the instructions below.

In general, the first course of action is to be a member of the dev@httpd.apache.org mailing list. This indicates to the Group that you are closely following the latest Apache developments. Your patch file should be generated using either 'diff -c' or 'diff -u' against the latest CVS tree. To submit your patch, send email to dev@httpd.apache.org with a Subject: line that starts with [PATCH] 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.

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.
Why has Apache stolen my favourite site's Internet address?
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 pagrovide 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 /usr/local/apache/logs/error_log, but see the ErrorLog directive in your config files for the location on your