Newer
Older
<!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>
$Revision: 1.63.2.14 $ ($Date: 1997/08/03 08:47:57 $)
</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"
REL="Help"
><SAMP>http://www.apache.org/docs/misc/FAQ</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. Leave off the ".html" extension for absolute -->
<!-- links to sites which are known to run multiviews (e.g., -->
<!-- apache.org or apacheweek.com). -->
<!-- - 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>
<!-- Stuff to Add: -->
<!-- - can't bind to port 80 -->
<!-- - permission denied -->
<!-- - address already in use -->
<!-- - mod_auth & passwd lines "user:pw:.*" - ++1st colon onward is -->
<!-- treated as pw, not just ++1st to --2nd. -->
<!-- - SSL: -->
<!-- - Can I use Apache-SSL for free in Canada? -->
<!-- - Why can't I use Apache-SSL in the U.S.? -->
<!-- - How can I found out how many visitors my site gets? -->
<!-- - How do I add a counter? -->
<!-- - How do I configure Apache as a proxy? -->
<!-- - What browsers support HTTP/1.1? -->
<!-- - What's the point of vhosts-by-name is there aren't any -->
<!-- - Is there an Apache for W95/WNT? -->
<!-- - Why does Apache die when a vhost can't be DNS-resolved? -->
<!-- - Why do I get "send lost connection" messages in my error -->
<!-- log? -->
<!-- - specifically consider .pdf files which seem to cause this -->
<!-- a lot when accessed via the plugin ... and also mention -->
<!-- how range-requests can cause bytes served < file size -->
<!-- - Why do directory indexes appear as garbage? (A: -lucb) -->
<!-- - How do I add a footer to all pages offered by my server? -->
<!-- - Fix midi question; a bigger problem than midi vs. x-midi is -->
<!-- the simple fact that older versions of Apache (and new ones -->
<!-- that have been upgraded without upgrading the mime.types -->
<!-- file) don't have the type listed at all. -->
<!-- - Why is my .htaccess ignored? -->
<!-- - RewriteRule /~fraggle/* /cgi-bin/fraggle.pl does not work -->
<UL>
<LI><STRONG>Background</STRONG>
<OL START=1>
<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>Technical Questions</STRONG>
<OL START=11>
<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="#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="#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="#proxy">Does or will Apache act as a Proxy server?</A>
</LI>
<LI><A HREF="#multiviews">What are "multiviews"?</A>
</LI>
<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 FD_SETSIZE on FreeBSD?</A>
</LI>
<LI><A HREF="#limitGET">Why do I keep getting "access denied" for
form POST requests?</A>
</LI>
<LI><A HREF="#passwdauth">Can I use my <SAMP>/etc/passwd</SAMP> file
for Web page authentication?</A>
</LI>
<LI><A HREF="#errordoc401">Why doesn't my <CODE>ErrorDocument
401</CODE> work?</A>
<LI><A HREF="#setgid">Why do I get "<SAMP>setgid: Invalid
argument</SAMP>" at startup?</A>
<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><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="#putsupport">Why can't I publish to my Apache server
using PUT on Netscape Gold and other programs?</A>
<LI><A HREF="#fastcgi">Why isn't FastCGI included with Apache any
more?</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="#nph-scripts">How can I get my script's output without
Apache buffering it?</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="#wheres-the-dump">The errorlog says Apache dumped core,
but where's the dump file?</A>
</LI>
<LI><A HREF="#dnsauth">Why isn't restricting access by host or domain name
working correctly?</A>
</LI>
<LI><A HREF="#SSL-i">Why doesn't Apache include SSL?</A>
</LI>
<LI><A HREF="#HPUX-core">Why do I get core dumps under HPUX using
HP's ANSI C compiler?</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="#cantbuild">Why won't Apache compile with my
system's <SAMP>cc</SAMP>?</A>
</LI>
<LI><A HREF="#addlog">How do I add browsers and referrers to my
logs?</A>
</LI>
<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="#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><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-user-var">Why is the environment variable
<SAMP>REMOTE_USER</SAMP> not set?</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="#no-info-directives">Why doesn't mod_info list any
directives?</A>
<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="#authauthoritative">Why does my authentication give
me a server error?</A>
<LI><A HREF="#auth-on-same-machine">Do I have to keep the (mSQL)
authentication information on the same machine?</A>
<LI><A HREF="#msql-slow">Why is my mSQL authentication terribly slow?</A>
<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
<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
</LI>
<LI><A HREF="#rewrite-virthost">Why are RewriteRules in my VirtualHost
</LI>
<LI><A HREF="#rewrite-envwhitespace">How can I use strings with whitespaces
in RewriteRule's ENV flag?</A>
</LI>
<LI><A HREF="#cgi-spec">Where can I find the "CGI
specification"?</A>
</OL>
</LI>
</UL>
<HR>
<H2>The Answers</H2>
<H3>
Background
</H3>
<OL START=1>
<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>
<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.iworld.com/compare/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>
Apache is run on over 500,000 Internet servers (as of July 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.
</P>
<P>
The Apache project's web site includes a page with a partial list of
HREF="http://www.apache.org/info/apache_users"
>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 as a public domain HTTP server,
</LI>
<LI>to keep up with advances in HTTP protocol and web developments in
</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>
<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"
>the bug report page</A>.
Other questions should be directed to the
<A
HREF="news:comp.infosystems.www.servers.unix"
><SAMP>comp.infosystems.www.servers.unix</SAMP></A>
newsgroup, 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>
Indeed there is. See the main
<A
HREF="http://www.apache.org/"
>Apache web site</A>.
There is also a regular electronic publication called
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.
</P>
<HR>
</LI>
<LI><A NAME="where">
<STRONG>Where can I get Apache?</STRONG>
</A>
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>
Technical Questions
</H3>
<OL START=11>
<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/etc/httpd/logs/error_log</SAMP>, but see the
><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
<A
HREF="http://www.apache.org/bugdb.cgi"
>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>
USENET newsgroup</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/bugdb.cgi"
>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>
<DL>
<DD><CODE># cd <EM>ServerRoot</EM><BR>
# dbx httpd core<BR>
(dbx) where</CODE>
</DD>
</DL>
(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="CGIoutsideScriptAlias">
<STRONG>How do I enable CGI execution in directories other than
the ScriptAlias?</STRONG>
</A>
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>
<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>
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.
</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>
In some situations it can be not conform to your local policy 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
via
<A
HREF="../mod/mod_rewrite.html"
><SAMP>mod_rewrite</SAMP></A>
and the following steps:
</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>
</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><A NAME="premature-script-headers">
<STRONG>What does it mean when my CGIs fail with
"<SAMP>Premature end of script headers</SAMP>"?</STRONG>
<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:
<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>
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>
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>
<HR>
</LI>
<LI><A NAME="ssi-part-i">
<STRONG>How do I enable SSI (parsed HTML)?</STRONG>
</A>
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>
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>
<P>
<DL>
<DD><CODE>AddHandler server-parsed .shtml</CODE>
</DD>
</DL>
</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.
</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>
This is a feature The Apache Group hopes to add in the next major
release after 1.2.
</P>
<HR>
</LI>
<LI><A NAME="proxy">
<STRONG>Does or will Apache act as a Proxy server?</STRONG>
</A>
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
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="fdlim">
<STRONG>Why can't I run more than <<EM>n</EM>>
virtual hosts?</STRONG>
</A>
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>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.
<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.
</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>
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><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.
If you are using a version prior to 2.2, you need to recompile your
kernel with a larger FD_SETSIZE. 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.
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 FD_SETSIZE is set to when libc is compiled. To increase
this, you have to recompile libc with a higher FD_SETSIZE.
In FreeBSD 3.0, the default FD_SETSIZE 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="limitGET">
<STRONG>Why do I keep getting "access denied" for form POST
requests?</STRONG>
</A>
<P>
The most common cause of this is a <SAMP><Limit></SAMP> section
that only names the <SAMP>GET</SAMP> method. Look in your
configuration files for something that resembles the following and
would affect the location where the POST-handling script resides:
</P>