Apache Common Configuration Problems
A typical way to limit resources to particular clients or users is to use a <Limit> section, such as this
<Limit GET POST>
access restriction directives such as require or allow
The effect of the <Limit> section is to limit the restriction to only the listed methods - GET and POST in this example. This means that other methods, such as PUT, are not subject to the restriction. This can be a security problem. The correct solution is to remove the <Limit> and </Limit> lines, which will make the restriction apply to all request methods.
Note that while GET, POST and PUT are the commonly used methods today (along with HEAD which is treated like GET within Apache) other methods can be defined and used at any time. The above example configuration would allow these additional methods through as well. This is particularly important if the restricted area includes CGI scripts which do not bother to check the method with which they are called.
CGI Request Methods
CGI scripts should check the request method which they were invoked with. For example, if a CGI script is expected to be called by the GET method, it should check that the REQUEST_METHOD environment variable contains the word "GET" or "HEAD" and if not return an appropriate error status (such as 501 Method not implemented). If this is not done, the script could be invoked with other methods and either send the wrong data (e.g. invoked with POST and sent data by standard input), or access restrictions could be evaded as in the previous section.
CGIs should also check for the HEAD method, and if so do not need to output the body of the response, only the headers. However if the CGI does output the body, Apache will ignore it and only send the headers to the client. The request method names are case sensitive, so the method "get" is not the same as the method "GET" (the latter being the only one which is currently defined by HTTP).
Restrict by Hostname
The allow and deny directives are used to restrict access by the caller's hostname or IP address. When using hostnames, the text given on these directives matches the end of the callers hostname. So for example, the lines
deny from all
allow from apache.org
would allow requests from apache.org as expected, but also allow from www.apache.org and all other hosts with *.apache.org addresses. It would even allow access to people from domains unrelated to apache.org, such as otherapache.org. This may not be obvious from the directive, which appears to just restrict the host "apache.org". At the present time there is no way to specify that just the hostname "apache.org" should be restricted, and not its sub-domains. But it is possible to prevent domains such as otherapache.org by using
allow from .apache.org
Of course if a restriction to a single host is required it can be implemented by listing the full IP address or addresses of the host instead of the hostname. Using IP addresses also reduces the number of DNS lookups performed so should be more efficient.
Apache with NFS
Apache works fine on systems that mount disks via NFS. However there are some files which Apache uses which should not be stored on NFS mounts. The most important is the "lock file" which is used by Apache to efficiently let multiple processes access the same network socket. This default location for this file is the "logs" directory under the server root, unless changed by the LockFile directive. If the server root or the logs directory is NFS mounted, the location of the lock file must be changed. A directory such as /tmp or /var/tmp is often a good location. This lock file should not be NFS mounted because many implementations of NFS do not lock files properly.
While the lock file is the only file which should never be stored on a NFS mounted disk, for best performance other files which are heavily used by Apache should also be local rather than remote. For example, the log files (usually stored in the logs directory under the server root) are best stored on a local disk. Also the files accessed by browsers (under the document root and often from home directories) should be local for the better performance.
Apache Common Errors
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?
In Apache version 1.2, 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; the typical Apache setup has the server started as root to bind to port 80, after which it changes 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. As of Apache version 1.3, 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.
Why am I getting "Expected </Directory> but saw </Directory>" when I try to start Apache?
This is a known problem with certain versions of the AIX C compiler. IBM are working on a solution, and the issue is being tracked by problem report #2312.
I'm using RedHat Linux and I have problems with httpd dying randomly or not restarting properly
RedHat Linux versions 4.x (and possibly earlier) RPMs contain various nasty scripts which do not stop or restart Apache properly. These can affect you even if you're not running the RedHat supplied RPMs.
If you're using the default install then you're probably running Apache 1.1.3, which is outdated. From RedHat's ftp site you can pick up a more recent RPM for Apache 1.2.x. This will solve one of the problems.
If you're using a custom built Apache rather than the RedHat RPMs then you should rpm -e apache. In particular you want the mildly broken /etc/logrotate.d/apache script to be removed, and you want the broken /etc/rc.d/init.d/httpd (or httpd.init) script to be removed. The latter is actually fixed by the apache-1.2.5 RPMs but if you're building your own Apache then you probably don't want the RedHat files.
We can't stress enough how important it is for folks, especially vendors to follow the stopping Apache directions given in our documentation. In RedHat's defense, the broken scripts were necessary with Apache 1.1.x because the Linux support in 1.1.x was very poor, and there were various race conditions on all platforms. None of this should be necessary with Apache 1.2 and later.
I upgraded from an Apache version earlier than 1.2.0 and suddenly I have problems with Apache dying randomly or not restarting properly
It is entirely likely that your installation has start/stop/restart scripts which were built for an earlier version of Apache. Versions earlier than 1.2.0 had various race conditions that made it necessary to use kill -9 at times to take out all the httpd servers. But that should not be necessary any longer. You should follow how to stop and restart Apache.
As of Apache 1.3 there is a script src/support/apachectl which, after a bit of customization, is suitable for starting, stopping, and restarting your server.
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
in the file. Correct it if there one there with wrong information, or add one if you don't already have one.
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 for Windows, I get a message like "Unable To Locate WS2_32.DLL...". What should I do?
You need to install Winsock 2, available from http://www.microsoft.com/windows95/downloads/
Apache for Windows does not start. Error log contains this message: "[crit] (10045) The attempted operation is not supported for the type of object referenced: Parent: WSADuplicateSocket failed for socket ###". What does this mean?
We have seen this problem when Apache is run on systems along with Virtual Private Networking clients like Aventail Connect. Aventail Connect is a Layered Service Provider (LSP) that inserts itself, as a "shim," between the Winsock 2 API and Window's native Winsock 2 implementation. The Aventail Connect shim does not implement WSADuplicateSocket, which is the cause of the failure.
The shim is not unloaded when Aventail Connect is shut down. Once observed, the problem persists until the shim is either explicitly unloaded or the machine is rebooted. Another potential solution (not tested) is to add apache.exe to the Aventail "Connect Exclusion List".
Apache is affected in a similar way by any firewall program that isn't correctly configured. Assure you exclude your Apache server ports (usually port 80) from the list of ports to block. Refer to your firewall program's documentation for the how-to.
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:
The error you see will probably be one of those preceding this question in the FAQ.
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 do I have weird entries in my logs asking for default.ida and cmd.exe?
The host requesting pages from your website and creating those entries is a Windows machine running IIS that has been infected by an Internet worm such as Nimda or Code Red. You can safely ignore these error messages as they do not affect Apache. ApacheWeek has an article with more information.
Why am I getting server restart messages periodically, when I did not restart the server?
You are noticing restart messages in your error log, periodically, when you know you did not restart the server yourself:
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.
Apache uses the sendfile syscall on platforms where it is available in order to speed sending of responses. Unfortunately, on some systems, Apache will detect the presence of sendfile at compile-time, even when it does not work properly. This happens most frequently when using network or other non-standard file-system.
If you get error messages related to the AcceptEx syscall on win32, see the Win32DisableAcceptEx directive.
Premature end of script headers
Most problems with CGI scripts result in this message written in the error log together with an Internal Server Error delivered to the browser. A guide to helping debug this type of problem is available in the CGI tutorial