Frequently Asked Questions

These are questions that have been asked over the years, on IRC, mailing lists, and various other less official channels.

Background

What is Apache?

The Apache HTTP Server

• is a powerful, flexible, HTTP/1.1 compliant web server
• implements the latest protocols, including HTTP/1.1 (RFC2616)
• is highly configurable and extensible with third-party modules
• can be customised by writing 'modules' using the Apache module API
• provides full source code and comes with an unrestrictive license
• runs on Windows 2000, Netware 5.x and above, OS/2, and most versions of Unix, as well as several other operating systems
• is actively being developed
• encourages user feedback through new ideas, bug reports and patches
• implements many frequently requested features, including:
  • DBM databases as well, as relational databases and LDAP for authentication
  • allows you to easily set up password-protected pages with enormous numbers of authorized users, without bogging down the server.
  • Customized responses to errors and problems
  • Allows you to set up files, or even CGI scripts, which are returned by the server in response to errors and problems, e.g. setup a script to intercept 500 Server Errors and perform on-the-fly diagnostics for both users and yourself.
  • Multiple DirectoryIndex directives - Allows you to say DirectoryIndex index.html index.cgi, which instructs the server to either send back index.html or run index.cgi when a directory URL is requested, whichever it finds in the directory.
  • Unlimited flexible URL rewriting and aliasing - Apache has no fixed limit on the numbers of Aliases and Redirects which may be declared in the config files. In addition, a powerful rewriting engine can be used to solve most URL manipulation problems.
  • Content negotiation - i.e. the ability to automatically serve clients of varying sophistication and HTML level compliance, with documents which offer the best representation of information that the client is capable of accepting.
  • Virtual Hosts - Allows the server to distinguish between requests made to different IP addresses or names (mapped to the same machine). Apache also offers dynamically configurable mass-virtual hosting.
  • Configurable Reliable Piped Logs - You can configure Apache to generate logs in the format that you want. In addition, on most Unix architectures, Apache can send log files to a pipe, allowing for log rotation, hit filtering, real-time splitting of multiple vhosts into separate logs, and asynchronous DNS resolving on the fly.
    

How and why was Apache HTTP Server created?

The About Apache document explains how the Apache project evolved from its beginnings as an outgrowth of the NCSA httpd project to its current status as one of the fastest, most efficient, and most functional web servers in existence.

Why the name "Apache"?

The name 'Apache' was chosen from respect for the Native American Indian tribe of Apache (Indé), well-known for their superior skills in warfare strategy and their inexhaustible endurance. For more information on the Apache Nation, we suggest searching Google, or AllTheWeb.

Secondarily, and more popularly (though incorrectly) accepted, it's a considered cute name which stuck. Apache is "A PAtCHy server". It was based on some existing code and a series of "patch files".

These days Apache as such means much more. It's first and foremost the Apache Software Foundation, under which there are dozens of projects.

How does Apache httpd performance compare to other servers?

Benchmarks tend to be a measure of configuration competance, rather than of server quality. That is, if you're an expert in IIS, you can probably get it to run faster than you can get Apache to run. You can therefore find comparisions of various HTTP servers that prove that each is faster than all the others. We tend to take server performance benchmarks with a grain of salt.

How thoroughly tested is Apache httpd?

Apache is run on over 120 million Internet servers (as of April 2010) (Source, Netcraft). It has been tested thoroughly by both developers and users. The Apache HTTP Server Project Management Committee maintains rigorous standards before releasing new versions of their server, and our server runs without a hitch on over one half 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.

What are the future plans for Apache httpd?

• to continue to be an "open source" no-charge-for-use HTTP server,
• to keep up with advances in HTTP protocol and web developments in general,
• to collect suggestions for fixes/improvements from its users,
• to respond to needs of large volume providers as well as occasional users.
  

Whom do I contact for support?

See http://httpd.apache.org/support.html.

Is there any more information available on Apache httpd?

Indeed there is. See the main Apache web server site. There are also many books about the Apache HTTP Server available.

Where can I get Apache httpd?

You can find out how to download the source for Apache at the main Apache web server site.

Why isn't there a current binary for my platform?

The occasional availability of binaries for one platform or another at http://httpd.apache.org/dist/httpd/binaries/ has been a source of confusion for the user community, particularly the large subset which uses the Windows platform and is not able to build httpd and prerequisites themselves.

Producing binaries for general use is not part of the httpd release process. By policy the group does not formally release binaries and is in no position to ensure their consistent availability. (No mechanisms exist to review, test, and approve them – we can only formally release source).

If you are unable to build a binary for your platform, consult the Users mailing list for recommendations.

Some sources for Windows binaries are documented at Using Apache HTTP Server on Microsoft Windows.

May I use the Apache logo on my product or Web site?

You may NOT use any original artwork from the Apache Software Foundation, nor make or use modified versions of such artwork, except under the conditions in the Apache Trademark Policy document.

General Technical Questions

"Why can't I ...? Why won't ... work?" What to do in case of problems

If you are having trouble with your Apache server software, you should take the following steps:

Check the errorlog!

Check the FAQ!

Check the Apache bug database

Ask in a user support group

If all else fails, report the problem in the bug database

If your problem involves the server crashing and generating a core dump, please include a backtrace (if possible). As an example,

• # cd ServerRoot
  # dbx httpd core
  (dbx) where
  

  
  

(Substitute the appropriate locations for your ServerRoot and your httpd and core files. You may have to use gdb instead of dbx.)

How do I submit a patch to Apache httpd?

Detailed information for submitting bug reports and patches may be found in the Apache HTTP Server developer documentation.

Why has Apache stolen my favourite site's Internet address?

The simple answer is: "It hasn't." This misconception is usually caused by the site in question having migrated to the Apache Web server software, but not having migrated the site's content yet. When Apache is installed, the default page that gets installed tells the Webmaster the installation was successful. The expectation is that this default page will be replaced with the site's real content. If it doesn't, complain to the Webmaster, not to the Apache project – we just make the software and aren't responsible for what people do (or don't do) with it.

Why am I getting spam mail from the Apache site?

The short answer is: "You aren't." Usually when someone thinks the Apache site is originating spam, it's because they've traced the spam to a Web site, and the Web site says it's using Apache. See the previous FAQ entry for more details on this phenomenon.

No marketing spam originates from the Apache site. The only mail that comes from the site goes only to addresses that have been requested to receive the mail.

May I include the Apache software on a CD or other package I'm distributing?

The detailed answer to this question can be found in the Apache license, which is included in the Apache distribution in the file LICENSE. You can also find it on the Web at http://www.apache.org/licenses/.

What's the best hardware/operating system/... How do I get the most out of my Apache Web server?

Check out the performance tuning page.

What are "regular expressions"?

Regular expressions are a way of describing a pattern - for example, "all the words that begin with the letter A" or "every 10-digit phone number" or even "Every sentence with two commas in it, and no capital letter Q". Regular expressions (aka "regex"s) are useful in Apache because they let you apply certain attributes against collections of files or resources in very flexible ways - for example, all .gif and .jpg files under any "images" directory could be written as /images/.*(jpg|gif)$. Note that httpd doesn't need the delimiting // so as to avoid "toothpicks" when matching URIs or paths, like: /\/foo\/bar\/?/

The best overview around is probably the one which comes with Perl. Apache's regular expressions use PCRE - Perl Compatible Regular Expressions.

Building Apache httpd

Why do I get an error about an undefined reference to "+inet_ntoa" or other +inet_* symbols?

If you have installed BIND-8 then this is normally due to a conflict between your include files and your libraries. BIND-8 installs its include files and libraries /usr/local/include/ and /usr/local/lib/, while the resolver that comes with your system is probably installed in /usr/include/ and /usr/lib/. If your system uses the header files in /usr/local/include/ before those in /usr/include/ but you do not use the new resolver library, then the two versions will conflict.

To resolve this, you can either make sure you use the include files and libraries that came with your system or make sure to use the new include files and libraries. Adding -lbind to the EXTRA_LDFLAGS line in your Configuration file, then re-running Configure, should resolve the problem. (Apache versions 1.2.* and earlier use EXTRA_LFLAGS instead.)

Note:As of BIND 8.1.1, the bind libraries and files are installed under /usr/local/bind by default, so you should not run into this problem. Should you want to use the bind resolvers you'll have to add the following to the respective lines:

EXTRA_CFLAGS=-I/usr/local/bind/include EXTRA_LDFLAGS=-L/usr/local/bind/lib EXTRA_LIBS=-lbind

I get an error about "configure failed for srclib/apr"

This only applies to Apache 2.4 and later

If you are building with the --with-included-apr option, you also need to download the *-deps tarball that matches the main release that you are trying to build, and extract it into the same directory.

Why won't Apache compile with my system's cc?

If the server won't compile on your system, it is probably due to one of the following causes:

The Configure script doesn't recognize your system environment.

Your system's C compiler is garbage.

Your include files may be confused.

Your operating system or compiler may be out of revision.

The Apache Group tests the ability to build the server on many different platforms. Unfortunately, we can't test all of the OS platforms there are. If you have verified that none of the above issues is the cause of your problem, and it hasn't been reported before, please submit a problem report. Be sure to include complete details, such as the compiler & OS versions and exact error messages.

Why do I get complaints about redefinition of "struct iovec" when compiling under Linux?

This is a conflict between your C library includes and your kernel includes. You need to make sure that the versions of both are matched properly. There are two workarounds, either one will solve the problem:

Remove the definition of struct iovec from your C library includes. It is located in /usr/include/sys/uio.h. Or, Add -DNO_WRITEV to the EXTRA_CFLAGS line in your Configuration and reconfigure/rebuild. This hurts performance and should only be used as a last resort.

I'm using gcc and I get some compilation errors, what is wrong?

GCC parses your system header files and produces a modified subset which it uses for compiling. This behavior ties GCC tightly to the version of your operating system. So, for example, if you were running IRIX 5.3 when you built GCC and then upgrade to IRIX 6.2 later, you will have to rebuild GCC. Similarly for Solaris 2.4, 2.5, or 2.5.1 when you upgrade to 2.6. Sometimes you can type "gcc -v" and it will tell you the version of the operating system it was built against.

If you fail to do this, then it is very likely that Apache will fail to build. One of the most common errors is with readv, writev, or uio.h. This is not a bug with Apache. You will need to re-install GCC.

Error Log Messages and Problems Starting Apache

Why do I get "setgid: Invalid argument" at startup?

Your Group directive (probably in conf/httpd.conf) needs to name a group that actually exists in the /etc/group file (or your system's equivalent). This problem is also frequently seen when a negative number is used in the Group directive (e.g., "Group #-1"). Using a group name – not group number – found in your system's group database should solve this problem in all cases.

Why am I getting "httpd: could not set socket option TCP_NODELAY" in my error log?

This message almost always indicates that the client disconnected before Apache reached the point of calling setsockopt() for the connection. It shouldn't occur for more than about 1% of the requests your server handles, and it's advisory only in any case.

Why am I getting "connection reset by peer" in my error log?

This is a normal message and nothing about which to be alarmed. It simply means that the client canceled the connection before it had been completely set up - such as by the end-user pressing the "Stop" button. People's patience being what it is, sites with response-time problems or slow network links may experience this more than high capacity ones or those with large pipes to the network.

The errorlog says Apache dumped core, but where's the dump file?

The error log message about dumped core includes the directory where the dump file should be located. However, many Unixes do not allow a process that has called setuid() to dump core for security reasons ('Is this still a problem?'); the typical Apache setup has the server started as root to bind to port 80, after which it uses setuid() to change UIDs to a non-privileged user to serve requests.

Dealing with this is extremely operating system-specific, and may require rebuilding your system kernel. Consult your operating system documentation or vendor for more information about whether your system does this and how to bypass it. If there is a documented way of bypassing it, it is recommended that you bypass it only for the httpd server process if possible.

The canonical location for Apache's core-dump files is the ServerRoot directory. The location can be set via the CoreDumpDirectory directive to a different directory. Make sure that this directory is writable by the user the server runs as (as opposed to the user the server is started as).

When I run it under Linux I get "shmget: function not found", what should I do?

Your kernel has been built without SysV IPC support. You will have to rebuild the kernel with that support enabled (it's under the "General Setup" submenu). Documentation for kernel building is beyond the scope of this FAQ; you should consult the Kernel HOWTO, or the documentation provided with your distribution, or a Linux newsgroup/mailing list. As a last-resort workaround, you can comment out the #define USE_SHMGET_SCOREBOARD definition in the LINUX section of src/conf.h and rebuild the server (prior to 1.3b4, simply removing #define HAVE_SHMGET would have sufficed). This will produce a server which is slower and less reliable.

Server hangs, or fails to start, and/or error log fills with "fcntl: F_SETLKW: No record locks available" or similar messages

These are symptoms of a file locking problem, which usually means that the server is trying to use a synchronization file on an NFS filesystem.

Because of its parallel-operation model, the Apache Web server needs to provide some form of synchronization when accessing certain resources. One of these synchronization methods involves taking out locks on a file, which means that the filesystem whereon the lockfile resides must support locking. In many cases this means it can't be kept on an NFS-mounted filesystem.

To cause the Web server to work around the NFS locking limitations, include a line such as the following in your server configuration files:

LockFile /var/run/apache-lock

The directory should not be generally writable (e.g., don't use /var/tmp). See the LockFile documentation for more information.

When I try to start Apache from a DOS window, I get a message like "Cannot determine host name. Use ServerName directive to set it manually." What does this mean?

It means what it says; the Apache software can't determine the hostname of your system. Edit your conf\httpd.conf file, look for the string "ServerName", and make sure there's an uncommented directive such as

ServerName localhost or

ServerName www.foo.com in the file. Correct it if there one there with wrong information, or add one if you don't already have one.

Also, make sure that your Windows system has DNS enabled. See the TCP/IP setup component of the Networking or Internet Options control panel.

After verifying that DNS is enabled and that you have a valid hostname in your ServerName directive, try to start the server again.

When I try to start Apache on Windows, I get a message like "System error 1067 has occurred. The process terminated unexpectedly." What does this mean?

This message means that the Web server was unable to start correctly for one reason or another. To find out why, execute the following commands in a DOS window:

• c: cd "\Program Files\Apache Group\Apache" apache
  

(If you don't get the prompt back, hit Control-C to cause Apache to exit.)

The error you see will probably be one of those preceding this question in the FAQ.

First check the Windows NT Event Log for Application errors using the Windows NT/2000 Event Viewer program. Any errors that occur prior to opening the Apache error log will be stored here, if Apache is run as a Service on NT or 2000. As with any error, also check your Apache error log.

On a SuSE Linux system, I try and configure access control using basic authentication. Although I follow the example exactly, authentication fails, and an error message "admin: not a valid FDN: ...." is logged.

In the SuSE distribution, additional 3rd party authentication modules have been added and activated by default. These modules interfere with the Apache standard modules and cause Basic authentication to fail. Our recommendation is to comment all those modules in /etc/httpd/suse_addmodule.conf and /etc/httpd/suse_loadmodule.conf which are not actually required for running your server.

Why am I getting server restart messages periodically, when I did not restart the server?

Problem: You are noticing restart messages in your error log, periodically, when you know you did not restart the server yourself:

  [Thu Jun  6 04:02:01 2002] [notice] SIGHUP received.  Attempting to restart
  [Thu Jun  6 04:02:02 2002] [notice] Apache configured -- resuming normal operations

Check your cron jobs to see when/if your server logs are being rotated. Compare the time of rotation to the error message time. If they are the same, you can somewhat safely assume that the restart is due to your server logs being rotated.

Why am I getting "module module-name is not compatible with this version of Apache" messages in my error log?

Module Magic Number (MMN) is a constant defined in Apache source that is associated with binary compatibility of modules. It is changed when internal Apache structures, function calls and other significant parts of API change in such a way that binary compatibility cannot be guaranteed any more. On MMN change, all third party modules have to be at least recompiled, sometimes even slightly changed in order to work with the new version of Apache.

If you're getting the above error messages, contact the vendor of the module for the new binary, or compile it if you have access to the source code.

I've downloaded a module from a source I trust, but my LoadModule line is a syntax error?

Have you checked for simple errors like a typo, or an incorrect path to the module?

Another reason you may be unable to load a module is if it relies on libraries (Unix-family .so or Windows .dll) that are not loaded into the server. Such libraries can be loaded using the LoadFile directive, which must appear before your LoadModule line in the configuration. The module's provider should document any such dependencies.

There's a particular Gotcha on Windows:

• httpd: Syntax error on line nn of C:/IBM/HTTP/conf/httpd.conf: Cannot load C:/IBM/HTTP/modules/mod_foo.so into server: The specified module could not be found.
  

  
  

Googling the error message tells us there's a missing library, but there doesn't appear to be, and the identical configuration works on one computer but fails with this message on another. What gives?

This error may happen because you need to install the Windows C Runtime Libraries on the target machine. Note that this doesn't mean you need to load them explicitly into HTTPD, just install them on the host machine! This is likely to affect users of IBM's httpd trying to load modules not supplied by IBM, and might arise in other circumstances where the server and the module are compiled using different build options.

Configuration Questions

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 1024 or 2048. 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

Reduce the number of log files

Increase the number of file descriptors available to the server

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

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 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?

Apache httpd passes on your Set-Cookie header, like any other header. 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.

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

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. That is a good thing. If you have access to edit the httpd.conf, you should not use .htaccess files, ever. If your customers do need support for .htaccess, make sure that AllowOverride is set to something sensible (i.e.: Not All). 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.

You can tell if this is your problem by adding nonsense text to your .htaccess file and reloading the page. If you do not get a server error, then Apache httpd is not reading your .htaccess file.

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, see (13) Permission Denied for more info.

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.

See http://httpd.apache.org/docs/current/rewrite/remapping.html#canonicalhost .

Use name-based virtual hosting:

• NameVirtualHost *:80
  <VirtualHost *:80>
    ServerName www.example.net
    ServerAlias example.com
    Redirect permanent / http://www.example.com/
  </VirtualHost>
  
  <VirtualHost *:80>
    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.

How can I change the information that Apache returns about itself in the headers?

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 "2.2.17", the operating system, and a list of non-standard modules you have installed.

For example:

Server: Apache/2.2.17 (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?

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 *:80

<VirtualHost *:80>
  ServerName default.only
  <Location />
    Order allow,deny
    Deny from all
  </Location>
</VirtualHost>

<VirtualHost *:80>
  ServerName realhost1.example.com
  ServerAlias alias1.example.com alias2.example.com
  DocumentRoot /path/to/site1
</VirtualHost>
...

Dynamic Content (CGI and SSI)

How do I enable CGI execution in directories other than the ScriptAlias?

Apache recognizes all files in a directory named as a ScriptAlias 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 "*.cgi" or "*.pl" or whatever. In other words, all files in a ScriptAlias directory are scripts, as far as Apache is concerned.

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 AddHandler directive.

In an appropriate section of your server configuration files, add a line such as AddHandler cgi-script .cgi The server will then recognize that all files in that location (and its logical descendants) that end in ".cgi" are script files, not documents.

Make sure that the directory location is covered by an Options declaration that includes the ExecCGI option. In some situations, you might not want to actually allow all files named "*.cgi" 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 mod_rewrite and the following steps:

Locally add to the corresponding .htaccess file a ruleset similar to this one:

RewriteEngine on
RewriteBase /~foo/bar/
RewriteRule ^quux\.cgi$ - [T=application/x-httpd-cgi]

Make sure that the directory location is covered by an Options declaration that includes the ExecCGI and FollowSymLinks option.

What does it mean when my CGIs fail with "Premature end of script headers"?

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.

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. Even if the CGI runs fine from the command line, remember that the environment and permissions may be different when running under the web server. The CGI can only access resources allowed for the User and Group specified in your Apache configuration. In addition, the environment will not be the same as the one provided on the command line, but it can be adjusted using the directives provided by mod_env.

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 print or write statements that send your HTTP headers:

{{{#!perl
{
my $current_file_handle = select (STDOUT);
local $| = 1;
#
# print your HTTP headers here
#
select ($current_file_handle);
}
}}}
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 off (with $| = 0 or the equivalent) after the statements that send the headers, as displayed above.

If your script isn't written in Perl, do the equivalent thing for whatever language you are using (e.g., for C, call fflush() after writing the headers).

Another cause for the "premature end of script headers" message are the RLimitCPU and RLimitMEM directives. You may get the message if the CGI script was killed due to a resource limit.

In addition, a configuration problem in suEXEC, mod_perl, or another third party module can often interfere with the execution of your CGI and cause the "premature end of script headers" message.

Why do I keep getting "Method Not Allowed" for form POST requests?

This is almost always due to Apache not being configured to treat the file you are trying to POST to as a CGI script. You can not POST to a normal HTML file; the operation has no meaning. See the FAQ entry on CGIs outside ScriptAliased directories for details on how to configure Apache to treat the file in question as a CGI.

How do I enable SSI (parsed HTML)?

SSI (an acronym for Server-Side Include) directives allow static HTML documents to be enhanced at run-time (e.g., when delivered to a client by Apache). The format of SSI directives is covered in the mod_include manual; suffice it to say that Apache supports not only SSI but xSSI (eXtended SSI) directives.

Processing a document at run-time is called parsing it; hence the term "parsed HTML" sometimes used for documents that contain SSI instructions. Parsing tends to be resource-consumptive compared to serving static files, 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 next question for more information about this.)

To enable SSI processing, you need to

• Build your server with the mod_include module. This is normally compiled in by default.
• Make sure your server configuration files have an Options directive which permits Includes.
• Make sure that the directory where you want the SSI documents to live is covered by the "INCLUDEES" content filter, either explicitly or in some ancestral location. That can be done with the following directives:
  

AddType text/html .shtml
AddOutputFilter INCLUDES .shtml

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.

For additional information, see the mod_include documentation.

Why don't my parsed files get cached?

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 Content-Length or Last-Modified headers. Caches commonly work by comparing the Last-Modified 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.

You can work around this in some cases by causing an Expires header to be generated. (See the mod_expires documentation for more details.) Another possibility is to use the XBitHack Full mechanism, which tells Apache to send (under certain circumstances detailed in the XBitHack directive description) a Last-Modified 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.

How can I have my script output parsed?

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.

SSIs don't work for VirtualHosts and/or user home directories.

This is almost always due to having some setting in your config file that sets "Options Includes" or some other setting for your DocumentRoot but not for other directories. If you set it inside a Directory section, then that setting will only apply to that directory.

Why is the environment variable REMOTE_USER not set?

This variable is set and thus available in SSI or CGI scripts if and only if the requested document was protected by access authentication. For an explanation on how to implement these restrictions, see Apache Week's articles on Using User Authentication or DBM User Authentication.

Hint: When using a CGI script to receive the data of a HTML FORM, notice that protecting the document containing the FORM is not sufficient to provide REMOTE_USER to the CGI script. You have to protect the CGI script, too. Or alternatively only the CGI script (then authentication happens only after filling out the form).

How do I allow each of my user directories to have a cgi-bin directory?

Remember that CGI execution does not need to be restricted only to cgi-bin directories. You can allow CGI script execution in arbitrary parts of your filesystem.

There are many ways to give each user directory a cgi-bin directory such that anything requested as http://example.com/~user/cgi-bin/program will be executed as a CGI script. Two alternatives are:

Place the cgi-bin directory next to the public_html directory:

ScriptAliasMatch ^/~([^/]*)/cgi-bin/(.*) /home/$1/cgi-bin/$2
Place the cgi-bin directory underneath the public_html directory:
<Directory /home/*/public_html/cgi-bin>
    Options ExecCGI
    SetHandler cgi-script
</Directory>

If you are using suexec, the first technique will not work because CGI scripts must be stored under the public_html directory.

Authentication and Access Restrictions

Why isn't restricting access by host or domain name working correctly?

Two of the most common causes of this are:

An error, inconsistency, or unexpected mapping in the DNS registration

This happens frequently: your configuration restricts access to Host.FooBar.Com, but you can't get in from that host. The usual reason for this is that Host.FooBar.Com is actually an alias for another name, and when Apache performs the address-to-name lookup it's getting the real name, not Host.FooBar.Com. You can verify this by checking the reverse lookup yourself. The easiest way to work around it is to specify the correct host name in your configuration.

Inadequate checking and verification in your configuration of Apache

If you intend to perform access checking and restriction based upon the client's host or domain name, you really need to configure Apache to double-check the origin information it's supplied. You do this by adding this to your configuration:

HostnameLookups Double

This will cause Apache to be very paranoid about making sure a particular host address is really assigned to the name it claims to be. Note that this can incur a significant performance penalty, however, because of all the name resolution requests being sent to a nameserver.

How do I set up Apache to require a username and password to access certain documents?

There are several ways to do this; some of the more popular ones are to use the mod_authn_file, mod_authn_dbd, or mod_authnz_ldap modules.

For an explanation on how to implement these restrictions, see the authentication tutorial in the Apache HTTP Server documentation.

How do I set up Apache to allow access to certain documents only if a site is either a local site or the user supplies a password and username?

Use the Satisfy directive, in particular the Satisfy Any directive, to require that only one of the access restrictions be met. For example, adding the following configuration to a .htaccess or server configuration file would restrict access to people who either are accessing the site from a host under domain.com or who can supply a valid username and password:

Deny from all
Allow from .domain.com
AuthType Basic
AuthUserFile /usr/local/apache/conf/htpasswd.users
AuthName "special directory"
Require valid-user
Satisfy any

See the user authentication question and the mod_authnz_host module for details on how the above directives work.

Why does my authentication give me a server error?

Under normal circumstances, the Apache access control modules will pass unrecognized user IDs on to the next access control module in line. Only if the user ID is recognized and the password is validated (or not) will it give the usual success or "authentication failed" messages.

However, if the last access module in line 'declines' the validation request (because it has never heard of the user ID or because it is not configured), the http_request handler will give one of the following, confusing, errors:

• check access
• check user. No user file?
• check access. No groups file?
  

This does not mean that you have to add an 'AuthUserFile /dev/null' line as some magazines suggest!

The solution is to ensure that at least the last module is authoritative and CONFIGURED. By default, mod_auth is authoritative and will give an OK/Denied, but only if it is configured with the proper AuthUserFile. Likewise, if a valid group is required. (Remember that the modules are processed in the reverse order from that in which they appear in your compile-time Configuration file.)

A typical situation for this error is when you are using the mod_auth_dbm, mod_auth_msql, mod_auth_mysql, mod_auth_anon or mod_auth_cookie modules on their own. These are by default not authoritative, and this will pass the buck on to the (non-existent) next authentication module when the user ID is not in their respective database. Just add the appropriate 'XXXAuthoritative yes' line to the configuration.

In general it is a good idea (though not terribly efficient) to have the file-based mod_auth a module of last resort. This allows you to access the web server with a few special passwords even if the databases are down or corrupted. This does cost a file open/seek/close for each request in a protected area.

Do I have to keep the (SQL) authentication information on the same machine?

Some organizations feel very strongly about keeping the authentication information on a different machine than the webserver. With the mod_auth_msql, mod_auth_mysql, and other SQL modules connecting to (R)DBMses this is quite possible. Just configure an explicit host to contact.

Be aware that with mSQL and Oracle, opening and closing these database connections is very expensive and time consuming. You might want to look at the code in the auth_* modules and play with the compile time flags to alleviate this somewhat, if your RDBMS licences allow for it.

Can I use my /etc/passwd file for Web page authentication?

Yes, you can - but it's a very bad idea. Here are some of the reasons:

• The Web technology provides no governors on how often or how rapidly password (authentication failure) retries can be made. That means that someone can hammer away at your system's root password using the Web, using a dictionary or similar mass attack, just as fast as the wire and your server can handle the requests. Most operating systems these days include attack detection (such as n failed passwords for the same account within m seconds) and evasion (breaking the connection, disabling the account under attack, disabling all logins from that source, et cetera), but the Web does not.
• An account under attack isn't notified (unless the server is heavily modified); there's no "You have 19483 login failures" message when the legitimate owner logs in.
• Without an exhaustive and error-prone examination of the server logs, you can't tell whether an account has been compromised. Detecting that an attack has occurred, or is in progress, is fairly obvious, though - if you look at the logs.
• Web authentication passwords (at least for Basic authentication) generally fly across the wire, and through intermediate proxy systems, in what amounts to plain text. "O'er the net we go/Caching all the way;/O what fun it is to surf/Giving my password away!"
• Since HTTP is stateless, information about the authentication is transmitted each and every time a request is made to the server. Essentially, the client caches it after the first successful access, and transmits it without asking for all subsequent requests to the same server.
• It's relatively trivial for someone on your system to put up a page that will steal the cached password from a client's cache without them knowing. Can you say "password grabber"?
  

If you still want to do this in light of the above disadvantages, the method is left as an exercise for the reader. It'll void your Apache warranty, though, and you'll lose all accumulated UNIX guru points.

Why does Apache ask for my password twice before serving a file?

If the hostname under which you are accessing the server is different than the hostname specified in the ServerName directive, then depending on the setting of the UseCanonicalName directive, Apache will redirect you to a new hostname when constructing self-referential URLs. This happens, for example, in the case where you request a directory without including the trailing slash.

When this happens, Apache will ask for authentication once under the original hostname, perform the redirect, and then ask again under the new hostname. For security reasons, the browser must prompt again for the password when the host name changes.

To eliminate this problem you should

• Always use the trailing slash when requesting directories;
• Change the ServerName to match the name you are using in the URL;
• and/or Set UseCanonicalName off.
  

How can I prevent people from "stealing" the images from my web site?

The goal here is to prevent people from inlining your images directly from their web site, but accessing them only if they appear inline in your pages.

This can be accomplished with a combination of SetEnvIf and the Deny and Allow directives. However, it is important to understand that any access restriction based on the REFERER header is intrinsically problematic due to the fact that browsers can send an incorrect REFERER, either because they want to circumvent your restriction or simply because they don't send the right thing (or anything at all).

The following configuration will produce the desired effect if the browser passes correct REFERER headers.

SetEnvIf REFERER "www\.mydomain\.com" linked_from_here
SetEnvIf REFERER "^$" linked_from_here

<Directory /www/images>
    Order deny,allow
    Deny from all
    Allow from env=linked_from_here
</Directory>

Further examples can be found in the Environment Variables documentation.

URL Rewriting

Where can I find mod_rewrite rulesets which already solve particular URL-related problems?

There is a collection of practical solutions that can be found in the URL Rewriting Guide. If you have more interesting rulesets which solve particular problems not currently covered in this document, open a doc suggestion in bugzilla to add it. The other webmasters will thank you for avoiding the reinvention of the wheel.

Where can I find any published information about URL-manipulations and mod_rewrite?

There is an article from Ralf S. Engelschall about URL-manipulations based on mod_rewrite in the "iX Multiuser Multitasking Magazin" issue #12/96. The German (original) version can be read online at <http://www.heise.de/ix/artikel/1996/12/149/>, the English (translated) version can be found at <http://www.heise.de/ix/artikel/E/1996/12/149/>.

Why is mod_rewrite so difficult to learn and seems so complicated?

Hmmm... there are a lot of reasons. First, mod_rewrite itself is a powerful module which can help you in really all aspects of URL rewriting, so it can be no trivial module per definition. To accomplish its hard job it uses software leverage and makes use of a powerful regular expression library by Henry Spencer. And regular expressions itself can be difficult to newbies, while providing the most flexible power to the advanced hacker.

On the other hand mod_rewrite has to work inside the Apache API environment and needs to do some tricks to fit there. For instance the Apache API really was not designed for URL rewriting at the .htaccess level of processing. Or the problem of multiple rewrites in sequence, which is also not handled by the API per design. To provide this features mod_rewrite has to do some special (but API compliant!) handling which leads to difficult processing inside the Apache kernel. While the user usually doesn't see anything of this processing, it can be difficult to find problems when some of your RewriteRules seem not to work.

What can I do if my RewriteRules don't work as expected?

Use "RewriteLog somefile" and "RewriteLogLevel 9" and have a precise look at the steps the rewriting engine performs. This is really the only one and best way to debug your rewriting configuration.

Why don't some of my URLs get prefixed with DocumentRoot when using mod_rewrite?

If the rule starts with /somedir/... make sure that really no /somedir exists on the filesystem if you don't want to lead the URL to match this directory, i.e., there must be no root directory named somedir on the filesystem. Because if there is such a directory, the URL will not get prefixed with DocumentRoot. This behavior looks ugly, but is really important for some other aspects of URL rewriting.

How can I make all my URLs case-insensitive with mod_rewrite?

You can't! The reasons are: first, that, case translations for arbitrary length URLs cannot be done via regex patterns and corresponding substitutions. One needs a per-character pattern like the sed/Perl tr|..|..| feature. Second, just making URLs always upper or lower case does not solve the whole problem of case-INSENSITIVE URLs, because URLs actually have to be rewritten to the correct case-variant for the file residing on the filesystem in order to allow Apache to access the file. And the Unix filesystem is always case-SENSITIVE.

But there is a module named mod_speling.c in the Apache distribution. Try this module to help correct people who use mis-cased URLs.

Why are RewriteRules in my VirtualHost parts ignored?

Because you have to enable the engine for every virtual host explicitly due to security concerns. Just add a "RewriteEngine on" to your virtual host configuration parts.

How can I use strings with whitespaces in RewriteRule's ENV flag?

There is only one ugly solution: You have to surround the complete flag argument by quotation marks ("[E=...]"). Notice: The argument to quote here is not the argument to the E-flag, it is the argument of the Apache config file parser, i.e., the third argument of the RewriteRule here. So you have to write "[E=any text with whitespaces]".

Features

Does or will Apache act as a Proxy server?

mod_proxy provides proxying functionality for a variety of protocols.

What are "multiviews"?

"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 content negotiation description page. In addition, Apache Week carried an article on this subject entitled "Content Negotiation Explained".

Why can't I publish to my Apache server using PUT on Netscape Gold and other programs?

Because you need to install and configure a script to handle the uploaded files. This script is often called a "PUT" handler. There are several available, but they may have security problems. Using FTP uploads may be easier and more secure, at least for now. For more information, see the Apache Week article Publishing Pages with PUT.

How can I attach a footer to my documents without using SSI?

You can make arbitrary changes to static documents by configuring an Action which launches a CGI script. The CGI is then responsible for setting a content-type and delivering the requested document (the location of which is passed in the PATH_TRANSLATED environment variable), along with whatever footer is needed.

Busy sites may not want to run a CGI script on every request, and should consider using an Apache module to add the footer. There are several third party modules available through the Apache Module Registry which will add footers to documents. These include mod_trailer, PHP (php3_auto_append_file), mod_layout, and mod_perl (Apache::Sandwich).

Does Apache include a search engine?

Apache does not include a search engine, but there are many good commercial and free search engines which can be used easily with Apache. Some of them are listed on the Web Site Search Tools page. Open source search engines that are often used with Apache include ht://Dig and SWISH-E.

How can I rotate my log files?

The simple answer: by piping the transfer log into an appropriate log file rotation utility.

The longer answer: In the src/support/ directory, you will find a utility called rotatelogs which can be used like this:

   TransferLog "|/path/to/rotatelogs /path/to/logs/access_log 86400

to enable daily rotation of the log files. A more sophisticated solution of a logfile rotation utility is available under the name cronolog from Andrew Ford's site at http://www.cronolog.org/. It can automatically create logfile subdirectories based on time and date, and can have a constant symlink point to the rotating logfiles. (As of version 1.6.1, cronolog is available under the Apache License). Use it like this:

   CustomLog "|/path/to/cronolog --symlink=/usr/local/apache/logs/access_log /usr/local/apache/logs/%Y/%m/access_log" combined

How do I keep certain requests from appearing in my logs?

The maximum flexibility for removing unwanted information from log files is obtained by post-processing the logs, or using piped-logs to feed the logs through a program which does whatever you want. However, Apache does offer the ability to prevent requests from ever appearing in the log files. You can do this by using the SetEnvIf directive to set an environment variable for certain requests and then using the conditional CustomLog syntax to prevent logging when the environment variable is set.

Does Apache support any sort of database integration?

No. Apache is a Web (HTTP) server, not an application server. The base package does not include any such functionality. See the PHP project and the mod_perl project for examples of modules that allow you to work with databases from within the Apache environment.

Can I use Active Server Pages (ASP) with Apache?

The base Apache Web Server package does not include ASP support. However, a number of projects provide ASP or ASP-like functionality for Apache. Some of these are:

• Apache::ASP
• mod_mono
  

See also the related projects page to find out more.

Does Apache come with Java support?

The base Apache Web server package does not include support for Java, Java Server Pages, Enterprise Java Beans, or Java servlets. Those features are available as add-ons from other Apache projects such as Geronimo and Tomcat.