$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 latest version of this FAQ is available on the HTTP Server Wiki, at <http://httpd.apache.org/docs/1.3/misc/FAQ.html>. This version is no longer maintained, and contains inaccurate and grossly outdated information.
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=300Remember 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 nnnto 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.0More 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
.karNote 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 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 following Alias, on the other hand, will
work for both cases:
Alias /example /home/www/example
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.nReplace 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 (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.
If you don't find this string, check out the previous question.
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 two techniques to implement canonical hostnames:
NameVirtualHost *
<VirtualHost *>
ServerName www.example.net
ServerAlias example.com
Redirect permanent / http://www.example.com/
</VirtualHost>
<VirtualHost *>
ServerName www.example.com
DocumentRoot /usr/local/apache/htdocs
</VirtualHost>
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:
<Directory /path/to/directory>
Options -Indexes
</Directory>
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
<Directory /usr/local/apache/htdocs>
Options Indexes
</Directory>
Options Includes ExecCGI
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.
A an access_log entry showing this situation could look like this:
63.251.56.142 - -
[25/Jul/2002:12:48:04 -0700] "GET http://www.yahoo.com/
HTTP/1.0" 200 1456 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:
NameVirtualHost *
<VirtualHost *>
ServerName default.only
<Location />
Order allow,deny
Deny from all
</Location>
</VirtualHost>
<VirtualHost *>
ServerName realhost1.example.com
ServerAlias alias1.example.com alias2.example.com
DocumentRoot /path/to/site1
</VirtualHost>
...