Apache Server Frequently Asked
Questions

$Revision: 1.99 $ ($Date: 2010/12/10 10:13:45 $)

Please note that this document refers to a version of the
product which has been deprecated, and declared "end of life", in
favor of the more recent
version of the server. Information obtained here is likely to be
outdated and inaccurate.

The Answers

E. Configuration Questions

You are probably running into resource limitations in
your operating system. The most common limitation is the
per-process limit on file
descriptors, 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 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 separate 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 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.

As to what you can do about this:

Reduce the number of Listen
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.

Reduce the number of log files. You can use mod_log_config
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
src/support/split-logfile file.

Increase the number of file descriptors available to
the server (see your system's documentation on the
limit or ulimit commands).
For some systems, information on how to do this is
available in the performance
hints page. There is a specific note for FreeBSD below.

For Windows 95, try modifying your
C:\CONFIG.SYS file to include a line
like

FILES=300

Remember that you'll need to reboot your Windows 95
system in order for the new value to take effect.

"Don't do that" - try to run with fewer virtual
hosts

Spread your operation across multiple server
processes (using Listen
for example, but see the first point) and/or ports.

Since this is an operating-system limitation, there's
not much else available in the way of solutions.

On versions of FreeBSD before 3.0, the
FD_SETSIZE 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:

options FD_SETSIZE nnn

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.

After you deal with the appropriate changes above, you
can increase the setting of FD_SETSIZE at
Apache compilation time by adding
"-DFD_SETSIZE=nnn" to the
EXTRA_CFLAGS line in your
Configuration file.

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.

Apache does not automatically send a cookie on
every response, unless you have re-compiled it with the mod_usertrack
module, and specifically enabled it with the CookieTracking
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
mod_usertrack, do not compile it into
Apache.

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.

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.

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 your
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.

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:

Even though the registered MIME type for MIDI files is
audio/midi, some browsers are not set up to
recognize it as such; instead, they look for
audio/x-midi. There are two things you can do
to address this:

Configure your browser to treat documents of type
audio/midi 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.

Instruct Apache to send a different
Content-type header for these files by
adding the following line to your server's
configuration files:

AddType audio/x-midi .mid .midi
.kar

Note that this may break browsers that do
recognize the audio/midi MIME type unless
they're prepared to also handle
audio/x-midi the same way.

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.

Add a ServerName directive
to the config file to tell it what the domain name of the
server is.

The other thing that can occasionally cause this symptom is a
misunderstanding of the Alias directive,
resulting in an alias working with a trailing slash, and not
without one. The Alias directive is very literal,
and aliases what you tell it to. Consider the following
example:

Alias /example/ /home/www/example/

The above directive creates an alias for URLs starting with
/example/, but does not alias URLs
starting with /example. That is to say, a URL such
as http://servername.com/example/ will get the
desired content, but a URL such as
http://servername.com/example will result in a
"file not found" error.

The mod_info
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 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 User
directive), then mod_info cannot read them in
order to list their values. An entry will be made
in the error log in this event, however.

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
<VirtualHost> definitions were very
complex and not well documented.

Apache 1.3b2 introduced a new directive, NameVirtualHost,
which simplifies the rules quite a bit. However, changing
the rules like this means that your existing name-based
<VirtualHost> containers probably won't
work correctly immediately following the upgrade.

To correct this problem, add the following line to the
beginning of your server configuration file, before
defining any virtual hosts:

NameVirtualHost n.n.n.n

Replace the "n.n.n.n" 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.

Make sure that your name-based
<VirtualHost> blocks contain
ServerName and possibly
ServerAlias directives so Apache can be sure
to tell them apart correctly.

This is almost always due to your AllowOverride
directive being set incorrectly for the directory in
question. If it is set to None 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 Directory
container.

The underlying file system permissions do not allow
the User/Group under which Apache is running to access
the necessary files; or

The Apache configuration has some access restrictions
in place which forbid access to the files.

You can determine which case applies to your situation
by checking the error log.

In the case where file system permission are at fault,
remember that not only must the directory and files in
question be readable, but also all parent directories must
be at least searchable (i.e., chmod +x /directory/path)
by the web server in order for the content to be accessible.

Search your conf/httpd.conf file for this
exact string: <Files ~>. If you find it,
that's your problem -- that particular <Files>
container is malformed. Delete it or replace it with
<Files ~ "^\.ht"> and restart your
server and things should work as expected.

This error appears to be caused by a problem with the
version of linuxconf distributed with Redhat 6.x. It may
reappear if you use linuxconf again.

MS Internet Explorer (MSIE) and Netscape handle mime type
detection in different ways, and therefore will display the
document differently. In particular, IE sometimes relies on
the file extension or the contents of the file to determine
the mime type. This can happen when the server specifies a
mime type of application/octet-stream or
text/plain. This behavior violates the the HTTP
standard and makes it impossible to deliver plain text
documents to MSIE clients in some cases. More details are
available on MSIE's mime type detection behavior in an
MSDN article and a note
by Alan J. Flavell.

The best you can do as a server administrator is to
accurately configure the mime type of your documents by editing
the mime.types file or using an AddType
directive in the Apache configuration files. In some cases,
you may be able to fool MSIE into rendering text/plain documents
correctly by assuring they have a .txt filename
extension, but this will not work if MSIE thinks the content
looks like another file type.

Many sites map a variety of hostnames to the same content.
For example, www.example.com,
example.com and www.example.net may
all refer to the same site. It is best to make sure that,
regardless of the name clients use to access the site, they
will be redirected to a single, canonical hostname. This
makes the site easier to maintain and assures that there will
be only one version of the site in proxy caches and search
engines.

There are many possible reasons for this, and almost all
of them are related to the configuration of your network, not
the configuration of the Apache HTTP Server. One of the most
common problems is that a firewall blocks access to the
default HTTP port 80. In particular, many consumer ISPs
block access to this port. You can see if this is the case
by changing any Port and Listen
directives in httpd.conf to use port 8000 and
then request your site using
http://yourhost.example.com:8000/. (Of course,
a very restrictive firewall may block this port as well.)

If a client requests a URL that designates a directory and
the directory does not contain a filename that matches the DirectoryIndex
directive, then mod_autoindex can be
configured to present a listing of the directory contents.

To turn on automatic directory indexing, find the
Options directive that
applies to the directory and add the Indexes
keyword. For example:

<Directory /path/to/directory>
Options +Indexes
</Directory>

To turn off automatic directory indexing, remove
the Indexes keyword from the appropriate
Options line. To turn off directory listing
for a particular subdirectory, you can use
Options -Indexes. For example:

Directives placed in the configuration files are applied
in a very particular order, as described by How Directory, Location, and Files
sections work. In addition, each Options directive has the
effect of resetting the options to none before
adding the specified options (unless only "+" and "-" options
are used). The consequence is that Options set
in the main server or virtual host context (outside any
directory, location, or files section) will usually have no
effect, because they are overridden by more specific
Options directives. For example, in the following

Includes and ExecCGI will be
off in the /usr/local/apache/htdocs
directory.

You can usually avoid problems by either finding the
Options directive that already applies to a
specific directory and changing it, or by putting your
Options directive inside the most specific possible
<Directory> section.

When a client connects to Apache, part of the information returned in
the headers is the name "Apache" Additional information that can be sent
is the version number, such as "1.3.26", the operating system, and a
list of non-standard modules you have installed.

For example:

Server: Apache/1.3.26 (Unix) mod_perl/1.26

Frequently, people want to remove this information, under the mistaken
understanding that this will make the system more secure. This is
probably not the case, as the same exploits will likely be attempted
regardless of the header information you provide.

There are, however, two answers to this question: the correct answer,
and the answer that you are probably looking for.

The correct answer to this question is that you should use the
ServerTokens directive to alter the quantity of information which is
passed in the headers. Setting this directive to Prod will
pass the least possible amount of information:

Server: Apache

The answer you are probably looking for is how to make Apache lie
about what what it is, ie send something like:

Server: Bob's Happy HTTPd Server

In order to do this, you will need to modify the Apache source code and
rebuild Apache. This is not advised, as it is almost certain not to
provide you with the added security you think that you are gaining. The
exact method of doing this is left as an exercise for the reader, as we
are not keen on helping you do something that is intrinsically a bad
idea.

The question is: why did a request for
www.yahoo.com come to your server instead of
Yahoo's server? And why does the response have a status
code of 200 (success)?

This is usually the result of malicious clients trying to
exploit open proxy servers to access a website without
revealing their true location. If you find entries like this
in your log, the first thing to do is to make sure you have
properly configured your server not to proxy for unknown
clients. If you don't need to provide a proxy server at all,
you should simply assure that the ProxyRequests
directive is not set on.
If you do need to run a proxy server, then you must ensure
that you secure your
server properly so that only authorized clients can use
it.

If your server is configured properly, then the attempt to
proxy through your server will fail. If you see a status
code of 404 (file not found) in the log, then
you know that the request failed. If you see a status code
of 200 (success), that does not necessarily mean
that the attempt to proxy succeeded. RFC2616 section 5.1.2
mandates that Apache must accept requests with absolute URLs
in the request-URI, even for non-proxy requests. Since
Apache has no way to know all the different names that your
server may be known under, it cannot simply reject hostnames
it does not recognize. Instead, it will serve requests for
unknown sites locally by stripping off the hostname and using
the default server or virtual host. Therefore you can
compare the size of the file (1456 in the above example) to
the size of the corresponding file in your default server.
If they are the same, then the proxy attempt failed, since a
document from your server was delivered, not a document from
www.yahoo.com.

If you wish to prevent this type of request entirely, then
you need to let Apache know what hostnames to accept and what
hostnames to reject. You do this by configuring name-virtual
hosts, where the first listed host is the default host that
will catch and reject unknown hostnames. For example: