$Revision: 1.27 $ ($Date: 1997/04/20 15:40:06 $)
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.
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.
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 Netcraft Survey.
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.
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.
A cute name which stuck. Apache is "A PAtCHy server". It was based on some existing code and a series of "patch files".
For an independent assessment, see Web Compare's comparison chart.
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.
Apache is run on over 400,000 Internet servers (as of April 1997). 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 third 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.
The Apache project's web site includes a page with a partial list of sites running Apache.
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 comp.infosystems.www.servers.unix newsgroup, 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.
Indeed there is. See the main Apache web site. There is also a regular electronic publication called Apache Week available.
You can find out how to download the source for Apache at the project's main web page.
If you are having trouble with your Apache server software, you should take the following steps:
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 (see the ErrorLog directive). Somethimes this is enough for you to diagnose & fix the problem yourself (such as file permissions or the like).
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 submittor, because there may be an email exchange going on about the issue that isn't getting recorded in the database.
A lot of common problems never make it to the bug database because there's already high Q&A traffic about them in the comp.infosystems.www.servers.unix 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 don't see your question already posted.
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,
(Substitute the appropiate locations for your ServerRoot and your httpd and core files. You may have to use gdb instead of dbx.)
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 enhancments stay consistent between the two servers for the foreseeable future.
Apache recognises all files in a directory named as a ScriptAlias 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 "*.cgi" or "*.pl" or whatever. In other words, all files in a ScriptAlias directory are scripts, as far as Apache is concerned.
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 recognise them - and also that it's okey to execute them. For this, you need to use something like the AddHandler directive.
AddHandler cgi-script .cgi
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. The most common cause of this is Perl scripts which haven't disabled buffering; if you insert the following statements before your first print statement, this will probably go away.
If your script isn't written in Perl, do the equivalent thing for whatever language you are using (e.g., for C, call fflush() after writing the headers).
SSI (an acronym for Server-Side Include) directives allow static HTML documents to be enhanced at run-time (e.g., when delivered to a client by Apache). The format of SSI directives is covered elsewhere; suffice it to say that Apache supports not only SSI but xSSI (eXtended SSI) directives.
Processing a document at run-time is called parsing it; hence the term "parsed HTML" sometimes used for documents that contain SSI instructions. Parsing tends to be extremely resource-consumptive, and is not enabled by default.
To enable SSI processing, you need to
mod_include
module. This is normally compiled in by default.
AddHandler server-parsed .shtml
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 Content-Length or
Last-Modified headers. Caches commonly work by comparing
the Last-Modified 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.
You can work around this in some cases by causing an
Expires header to be generated. (See the
mod_expires
documentation for more details.) Another possibility is to use the
XBitHack Full
mechanism, which tells Apache to send (under certain circumstances
detailed in the XBitHack directive description) a
Last-Modified 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.
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 has been regarded as a security liability, and the basic solution is for your script itself to do what the SSIs would be doing. After all, it's generating the rest of the content.
Apache version 1.1 and above comes with a proxy module. If compiled in, this will make Apache act as a caching-proxy server.
"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 content negotiation description page.
The Apache server can behave unpredictably when it encounters some resource limitations. One of these is the per-process limit on file descriptors, and that's almost always the cause of problems seen when adding virtual hosts. In this case, it is often not actually Apache that's encountering the problem, but some library routine (such as gethostbyname()) which needs file descriptors and doesn't complain intelligibly when it can't get them.
Each log file requires a file descriptor, which means that if you are using seperate access and error logs for each virtual host each virtual host needs two file descriptors. Each Listen directive also needs a file descriptor.
Typical values for <n> that we've seen are in the neighbourhoods of 128 or 250. When the server bumps into the file descriptor limit, it may dump core with a SIGSEGV, or 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 at times.
As to what you can do about this:
mod_log_config
to log all requests to a single log file while including the name
of the virtual host in the log file.
Since this is an operating-system limitation, there's not much else available in the way of solutions.
The most common cause of this is a <Limit> section that only names the GET method. Look in your configuration files for something that resembles the following and would affect the location where the POST-handling script resides:
Change that to <Limit GET POST> and the problem will probably go away.
Yes, you can - but it's a very bad idea. Here are some of the reasons:
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.
You need to use it with a URL in the form "/foo/bar" and not one with a method and hostname such as "http://host/foo/bar". See the ErrorDocument documentation for details. This was incorrectly documented in the past.
Your Group directive (probably in conf/httpd.conf) needs to name a group that actually exists in the /etc/group file (or your system's equivalent).
Apache does not send automatically send a cookie on every
response, unless you have re-compiled it with the
mod_cookies
module.
This module was distributed with Apache prior to 1.2.
This module may help track users, and uses cookies to do this. If
you are not using the data generated by mod_cookies, do not compile
it into Apache. Note that in 1.2 this module was renamed to the
more correct name
mod_usertrack,
and cookies
have to be specifically enabled with the
CookieTracking
directive.
Firstly, you do not need to compile in mod_cookies in order for your scripts to work (see the previous question for more about mod_cookies). Apache passes on your Set-Cookie 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.