$Revision: 1.7 $ ($Date: 2001/02/28 03:35:59 $)
The latest version of this FAQ is always available from the main Apache web site, at <http://www.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.
ErrorDocument
401 work?
.htaccess files are being
ignored.
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:
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.
Since this is an operating-system limitation, there's not much else available in the way of solutions.
As of 1.2.1 we have made attempts to work around various limitations involving running with many descriptors. More information is available.
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.
ErrorDocument 401 work?
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:
BrowserMatch Java1.0 force-response-1.0
BrowserMatch JDK/1.0 force-response-1.0
More information about this issue can be found in the Java and HTTP/1.1 page at the Apache web site.
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:
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.
Apache provides a couple of different ways of doing this. The recommended method is to compile the mod_log_config module into your configuration and use the CustomLog directive.
You can either log the additional information in files other than your normal transfer log, or you can add them to the records already being written. For example:
CustomLog logs/access_log "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-Agent}i\""
This will add the values of the User-agent: and Referer: headers, which indicate the client and the referring page, respectively, to the end of each line in the access log.
You may want to check out the Apache Week article entitled: "Gathering Visitor Information: Customizing Your Logfiles".
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 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.
Please see the Apache Virtual Host documentation for further details about configuration.
RedHat messed up and forgot to put a content type for .htm
files into /etc/mime.types. Edit /etc/mime.types,
find the line containing html and add htm to it.
Then restart your httpd server:
kill -HUP `cat /var/run/httpd.pid`
Then clear your browsers' caches. (Many browsers won't re-examine the content type after they've reloaded a page.)
.htaccess files are being ignored.
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.
This message is generally caused because either
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 by the web server in order for the content to be accessible.
Internet Explorer (IE) 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 to determine the mime type. This
can happen when the server specifies a mime type of
application/octet-stream or text/plain.
(Unfortunately, this behavior makes it impossible to properly send plain
text in some situations unless the file extension is txt.)
There are more details available on IE's mime type detection behavior in an
MSDN
article.
In order to make all browsers work correctly, you should assure
that Apache sends the correct mime type for the file. This is
accomplished by editing the mime.types file or using
an AddType
directive in the Apache configuration files.