- Why can't I run more than <n> virtual
hosts?
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.
As of 1.2.1 we have made attempts to work around various limitations involving running
with many descriptors.
More
information is available.
-
Can I increase FD_SETSIZE
on FreeBSD?
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.
- Why doesn't my
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.
- Why does Apache send a cookie on every
response?
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.
- Why don't my cookies work, I even compiled in mod_cookies?
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.
-
Why do my Java app[let]s give
me plain text when I request an URL from an Apache server?
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.
- How do I get Apache to send a MIDI file so the browser
can play it?
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.
- How do I add browsers and referrers to my logs?
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".
-
Why does accessing directories only
work when I include the trailing "/" (e.g., http://foo.domain.com/~user/)
but not when I omit it (e.g., http://foo.domain.com/~user)?
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
-
Why doesn't mod_info list
any directives?
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.
- I upgraded to Apache 1.3 and now my virtual
hosts don't work!
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.
- I'm using RedHat Linux and my .htm files
are showing up as HTML source rather than being formatted!
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.)
-
My
.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.
- Why do I get a "Forbidden"
message whenever I try to access a particular directory?
This message is generally caused because either
- 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 by the web server in order for the content to be accessible.
- Why do I get a "Forbidden/You don't have
permission to access / on this server" message whenever I try to access my
server?
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.
-
Why do my files appear correctly
in Internet Explorer, but show up as source or trigger a save window with Netscape; or,
Why doesn't Internet Explorer render my text/plain document correctly?
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.
- My site is accessible under many different
hostnames; how do I redirect clients so that they see only a single name?
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:
- Use mod_rewrite as
described in the "Canonical Hostnames" section of the URL Rewriting Guide.
- Use name-based virtual
hosting:
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>
- Why can I access my website from the server or
from my local network, but I can't access it from elsewhere on the Internet?
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.)
- How do I turn automatic directory listings on or
off?
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>
- Why do my Options directives not have the desired
effect?
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.
- Why do I see requests for other sites
appearing in my log files?
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>
...
