![[APACHE DOCUMENTATION]](../images/sub.gif)
The latest version of this FAQ is always available from the main Apache web site, at <http://httpd.apache.org/docs/misc/FAQ.html>.
If you are reading a text-only version of this FAQ, you may find numbers enclosed in brackets (such as "[12]"). These refer to the list of reference URLs to be found at the end of the document. These references do not appear, and are not needed, for the hypertext version.
struct iovec" when compiling under Linux?crypt function when I attempt to build Apache 1.2.System error 1067 has occurred. The process terminated unexpectedly." What does this mean?admin: not a valid FDN: ...." is logged.default.ida and cmd.exe?ErrorDocument 401 work?.htaccess files are being ignored.ErrorDocument and SSI to simplify customized error messages?The Apache httpd server
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.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.
A cute name which stuck. Apache is "A PAtCHy server". It was based on some existing code and a series of "patch files".
For many developers it is also a reverent connotation to the Native American Indian tribe of Apache, well-known for their superior skills in warfare strategy and inexhaustible endurance. For more information on the Apache Nation, we suggest searching Google, Northernlight, or AllTheWeb.
For an independent assessment, see Web Compare.
Apache has been shown to be substantially faster, more stable, and more feature-full than many other web servers. Although certain commercial servers have claimed to surpass Apache's speed (it has not been demonstrated that any of these "benchmarks" are a good way of measuring WWW server speed at any rate), we feel that it is better to have a mostly-fast free server than an extremely-fast server that costs thousands of dollars. Apache is run on sites that get millions of hits per day, and they have experienced no performance difficulties.
Apache is run on over 6 million Internet servers (as of February 2000). It has been tested thoroughly by both developers and users. The Apache Group 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.
There is no official support for Apache. None of the developers want to be swamped by a flood of trivial questions that can be resolved elsewhere. Bug reports and suggestions should be sent via the bug report page. Other questions should be directed to the Apache HTTP Server Users List or the comp.infosystems.www.servers.unix or comp.infosystems.www.servers.ms-windows newsgroup (as appropriate for the platform you use), where some of the Apache team lurk, in the company of many other httpd gurus who should be able to help.
Commercial support for Apache is, however, available from a number of third parties.
Indeed there is. See the main Apache web site. There is also a regular electronic publication called Apache Week available. Links to relevant Apache Week articles are included below where appropriate. There are also some Apache-specific books available.
You can find out how to download the source for Apache at the project's main web page.
You may NOT use any original artwork from the Apache Software Foundation, nor make or use modified versions of such artwork, except under the following conditions:
If you are having trouble with your Apache server software, you should take the following steps:
Apache tries to be helpful when it encounters a problem. In many cases, it will provide some details by writing one or messages to the server error log. Sometimes this is enough for you to diagnose & fix the problem yourself (such as file permissions or the like). The default location of the error log is /usr/local/apache/logs/error_log, but see the ErrorLog directive in your config files for the location on your server.
The latest version of the Apache Frequently-Asked Questions list can always be found at the main Apache web site.
Most problems that get reported to The Apache Group are recorded in the bug database. Please check the existing reports, open and closed, before adding one. If you find that your issue has already been reported, please don't add a "me, too" report. If the original report isn't closed yet, we suggest that you check it periodically. You might also consider contacting the original submitter, because there may be an email exchange going on about the issue that isn't getting recorded in the database.
A lot of common problems never make it to the bug database because there's already high Q&A traffic about them in the Users mailing list or comp.infosystems.www.servers.unix and related newsgroups. These newsgroups are also available via Google. Many Apache users, and some of the developers, can be found roaming their virtual halls, so it is suggested that you seek wisdom there. The chances are good that you'll get a faster answer there than from the bug database, even if you don't see your question already posted.
If you've gone through those steps above that are appropriate and have obtained no relief, then please do let The Apache Group know about the problem by logging a bug report.
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.)
Apache attempts to offer all the features and configuration options of NCSA httpd 1.3, as well as many of the additional features found in NCSA httpd 1.4 and NCSA httpd 1.5.
NCSA httpd appears to be moving toward adding experimental features which are not generally required at the moment. Some of the experiments will succeed while others will inevitably be dropped. The Apache philosophy is to add what's needed as and when it is needed.
Friendly interaction between Apache and NCSA developers should ensure that fundamental feature enhancements stay consistent between the two servers for the foreseeable future.
Yes, Apache is Year 2000 compliant.
Apache internally never stores years as two digits. On the HTTP protocol level RFC1123-style addresses are generated which is the only format a HTTP/1.1-compliant server should generate. To be compatible with older applications Apache recognizes ANSI C's asctime() and RFC850-/RFC1036-style date formats, too. The asctime() format uses four-digit years, but the RFC850 and RFC1036 date formats only define a two-digit year. If Apache sees such a date with a value less than 70 it assumes that the century is 20 rather than 19.
Although Apache is Year 2000 compliant, you may still get problems if the underlying OS has problems with dates past year 2000 (e.g., OS calls which accept or return year numbers). Most (UNIX) systems store dates internally as signed 32-bit integers which contain the number of seconds since 1st January 1970, so the magic boundary to worry about is the year 2038 and not 2000. But modern operating systems shouldn't cause any trouble at all.
Users of Apache 1.2.x should upgrade to a current version of Apache 1.3 (see year-2000 improvements in Apache 1.3 for details).
The Apache HTTP Server project is an open-source software product of the Apache Software Foundation. The project and the Foundation cannot offer legal assurances regarding any suitability of the software for your application. There are several commercial Apache support organizations and derivative server products available that may be able to stand behind the software and provide you with any assurances you may require. You may find links to some of these vendors at <http://www.apache.org/info/support.cgi>.
The Apache HTTP server software is distributed with the following disclaimer, found in the software license:
THIS SOFTWARE IS PROVIDED BY THE APACHE GROUP ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE GROUP OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The Apache Group encourages patches from outside developers. There are 2 main "types" of patches: small bugfixes and general improvements. Bugfixes should be submitting using the Apache bug report page. Improvements, modifications, and additions should follow the instructions below.
In general, the first course of action is to be a member of the dev@httpd.apache.org mailing list. This indicates to the Group that you are closely following the latest Apache developments. Your patch file should be generated using either 'diff -c' or 'diff -u' against the latest CVS tree. To submit your patch, send email to dev@httpd.apache.org with a Subject: line that starts with [PATCH] and includes a general description of the patch. In the body of the message, the patch should be clearly described and then included at the end of the message. If the patch-file is long, you can note a URL to the file instead of the file itself. Use of MIME enclosures/attachments should be avoided.
Be prepared to respond to any questions about your patches and possibly defend your code. If your patch results in a lot of discussion, you may be asked to submit an updated patch that incorporate all changes and suggestions.
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.
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.
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/LICENSE.txt>.
Check out Dean Gaudet's performance tuning page.
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)$/.
The best overview around is probably the one which comes with Perl. We implement a simple subset of Perl's regex support, but it's still a good way to learn what they mean. You can start by going to the CPAN page on regular expressions, and branching out from there.
The developers make sure that the software builds and works correctly on the platforms available to them; this does not necessarily mean that your platform is one of them. In addition, the Apache HTTP server project is primarily source oriented, meaning that distributing valid and buildable source code is the purpose of a release, not making sure that there is a binary package for all of the supported platforms.
If you don't see a kit for your platform listed in the binary distribution area (<URL:http://httpd.apache.org/dist/httpd/binaries/>), it means either that the platform isn't available to any of the developers, or that they just haven't gotten around to preparing a binary for it. As this is a voluntary project, they are under no obligation to do so. Users are encouraged and expected to build the software themselves.
The sole exception to these practices is the Windows package. Unlike most Unix and Unix-like platforms, Windows systems do not come with a bundled software development environment, so we do prepare binary kits for Windows when we make a release. Again, however, it's a voluntary thing and only a limited number of the developers have the capability to build the InstallShield package, so the Windows release may lag somewhat behind the source release. This lag should be no more than a few days at most.
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=-lbindIf the server won't compile on your system, it is probably due to one of the following causes:
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.
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:
struct iovec from your C library includes. It is located in /usr/include/sys/uio.h. Or,-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.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.
crypt function when I attempt to build Apache 1.2.
glibc puts the crypt function into a separate library. Edit your src/Configuration file and set this:
EXTRA_LIBS=-lcryptThen re-run src/Configure and re-execute the make.
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.
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.
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 experiences this more than high-capacity ones or those with large pipes to the network.
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).
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.
These are symptoms of a fine 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-lockThe directory should not be generally writable (e.g., don't use /var/tmp). See the LockFile documentation for more information.
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.
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.
You should read the previous note about problems with RedHat installations. 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 the directions on 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.
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 localhostor
ServerName www.foo.comin 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.
Short answer: You need to install Winsock 2, available from http://www.microsoft.com/windows95/downloads/
Detailed answer: Prior to version 1.3.9, Apache for Windows used Winsock 1.1. Beginning with version 1.3.9, Apache began using Winsock 2 features (specifically, WSADuplicateSocket()). WS2_32.DLL implements the Winsock 2 API. Winsock 2 ships with Windows NT 4.0 and Windows 98. Some of the earlier releases of Windows 95 did not include Winsock 2.
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. Instructions for temporarily removing the Aventail Connect V3.x shim can be found here: "How to Remove Aventail Connect v3.x from the LSP Order for Testing Purposes."
Another potential solution (not tested) is to add apache.exe to the Aventail "Connect Exclusion List". See this link for details: "How to Add an Application to Aventail Connect's Application 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.
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.
As of Apache 1.3.14, 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.
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.
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.
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 menage time. If they are the same, you can somewhat safely assume that the restart is due to your server logs being rotated.
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 compatiblity 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.
You are probably running into resource limitations in your operating system. The most common limitation is the per-process limit on file descriptors, which is almost always the cause of problems seen when adding virtual hosts. Apache often does not give an intuitive error message because it is normally some library routine (such as gethostbyname()) which needs file descriptors and doesn't complain intelligibly when it can't get them.
Each log file requires a file descriptor, which means that if you are using separate access and error logs for each virtual host, each virtual host needs two file descriptors. Each Listen directive also needs a file descriptor.
Typical values for <n> that we've seen are in the neighborhood of 128 or 250. When the server bumps into the file descriptor limit, it may dump core with a SIGSEGV, it might just hang, or it may limp along and you'll see (possibly meaningful) errors in the error log. One common problem that occurs when you run into a file descriptor limit is that CGI scripts stop being executed properly.
As to what you can do about this:
limit or ulimit commands). For some systems, information on how to do this is available in the performance hints page. There is a specific note for FreeBSD below.
For Windows 95, try modifying your C:\CONFIG.SYS file to include a line like
FILES=300Remember that you'll need to reboot your Windows 95 system in order for the new value to take effect.
Since this is an operating-system limitation, there's not much else available in the way of solutions.
As of 1.2.1 we have made attempts to work around various limitations involving running with many descriptors. More information is available.
On versions of FreeBSD before 3.0, the FD_SETSIZE define defaults to 256. This means that you will have trouble usefully using more than 256 file descriptors in Apache. This can be increased, but doing so can be tricky.
If you are using a version prior to 2.2, you need to recompile your kernel with a larger FD_SETSIZE. This can be done by adding a line such as:
options FD_SETSIZE nnnto your kernel config file. Starting at version 2.2, this is no longer necessary.
If you are using a version of 2.1-stable from after 1997/03/10 or 2.2 or 3.0-current from before 1997/06/28, there is a limit in the resolver library that prevents it from using more file descriptors than what FD_SETSIZE is set to when libc is compiled. To increase this, you have to recompile libc with a higher FD_SETSIZE.
In FreeBSD 3.0, the default FD_SETSIZE has been increased to 1024 and the above limitation in the resolver library has been removed.
After you deal with the appropriate changes above, you can increase the setting of FD_SETSIZE at Apache compilation time by adding "-DFD_SETSIZE=nnn" to the EXTRA_CFLAGS line in your Configuration file.
ErrorDocument 401 work?
You need to use it with a URL in the form "/foo/bar" and not one with a method and hostname such as "http://host/foo/bar". See the ErrorDocument documentation for details. This was incorrectly documented in the past.
Apache does not automatically send a cookie on every response, unless you have re-compiled it with the mod_usertrack module, and specifically enabled it with the CookieTracking directive. This module has been in Apache since version 1.2. This module may help track users, and uses cookies to do this. If you are not using the data generated by mod_usertrack, do not compile it into Apache.
Firstly, you do not need to compile in mod_cookies in order for your scripts to work (see the previous question for more about mod_cookies). Apache passes on your Set-Cookie header fine, with or without this module. If cookies do not work it will be because your script does not work properly or your browser does not use cookies or is not set-up to accept them.
As of version 1.2, Apache is an HTTP/1.1 (HyperText Transfer Protocol version 1.1) server. This fact is reflected in the protocol version that's included in the response headers sent to a client when processing a request. Unfortunately, low-level Web access classes included in the Java Development Kit (JDK) version 1.0.2 expect to see the version string "HTTP/1.0" and do not correctly interpret the "HTTP/1.1" value Apache is sending (this part of the response is a declaration of what the server can do rather than a declaration of the dialect of the response). The result is that the JDK methods do not correctly parse the headers, and include them with the document content by mistake.
This is definitely a bug in the JDK 1.0.2 foundation classes from Sun, and it has been fixed in version 1.1. However, the classes in question are part of the virtual machine environment, which means they're part of the Web browser (if Java-enabled) or the Java environment on the client system - so even if you develop your classes with a recent JDK, the eventual users might encounter the problem. The classes involved are replaceable by vendors implementing the Java virtual machine environment, and so even those that are based upon the 1.0.2 version may not have this problem.
In the meantime, a workaround is to tell Apache to "fake" an HTTP/1.0 response to requests that come from the JDK methods; this can be done by including a line such as the following in your server configuration files:
BrowserMatch Java1.0 force-response-1.0
BrowserMatch JDK/1.0 force-response-1.0More information about this issue can be found in the Java and HTTP/1.1 page at the Apache web site.
Even though the registered MIME type for MIDI files is audio/midi, some browsers are not set up to recognize it as such; instead, they look for audio/x-midi. There are two things you can do to address this:
AddType audio/x-midi .mid .midi .karNote that this may break browsers that do recognize the audio/midi MIME type unless they're prepared to also handle audio/x-midi the same way.
Apache provides a couple of different ways of doing this. The recommended method is to compile the mod_log_config module into your configuration and use the CustomLog directive.
You can either log the additional information in files other than your normal transfer log, or you can add them to the records already being written. For example:
CustomLog logs/access_log "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-Agent}i\""
This will add the values of the User-agent: and Referer: headers, which indicate the client and the referring page, respectively, to the end of each line in the access log.
You may want to check out the Apache Week article entitled: "Gathering Visitor Information: Customizing Your Logfiles".
When you access a directory without a trailing "/", Apache needs to send what is called a redirect to the client to tell it to add the trailing slash. If it did not do so, relative URLs would not work properly. When it sends the redirect, it needs to know the name of the server so that it can include it in the redirect. There are two ways for Apache to find this out; either it can guess, or you can tell it. If your DNS is configured correctly, it can normally guess without any problems. If it is not, however, then you need to tell it.
Add a ServerName directive to the config file to tell it what the domain name of the server is.
The mod_info module allows you to use a Web browser to see how your server is configured. Among the information it displays is the list modules and their configuration directives. The "current" values for the directives are not necessarily those of the running server; they are extracted from the configuration files themselves at the time of the request. If the files have been changed since the server was last reloaded, the display will not match the values actively in use. If the files and the path to the files are not readable by the user as which the server is running (see the User directive), then mod_info cannot read them in order to list their values. An entry will be made in the error log in this event, however.
In versions of Apache prior to 1.3b2, there was a lot of confusion regarding address-based virtual hosts and (HTTP/1.1) name-based virtual hosts, and the rules concerning how the server processed <VirtualHost> definitions were very complex and not well documented.
Apache 1.3b2 introduced a new directive, NameVirtualHost, which simplifies the rules quite a bit. However, changing the rules like this means that your existing name-based <VirtualHost> containers probably won't work correctly immediately following the upgrade.
To correct this problem, add the following line to the beginning of your server configuration file, before defining any virtual hosts:
NameVirtualHost n.n.n.nReplace the "n.n.n.n" with the IP address to which the name-based virtual host names resolve; if you have multiple name-based hosts on multiple addresses, repeat the directive for each address.
Make sure that your name-based <VirtualHost> blocks contain ServerName and possibly ServerAlias directives so Apache can be sure to tell them apart correctly.
Please see the Apache Virtual Host documentation for further details about configuration.
RedHat messed up and forgot to put a content type for .htm files into /etc/mime.types. Edit /etc/mime.types, find the line containing html and add htm to it. Then restart your httpd server:
kill -HUP `cat /var/run/httpd.pid`Then clear your browsers' caches. (Many browsers won't re-examine the content type after they've reloaded a page.)
.htaccess files are being ignored.
This is almost always due to your AllowOverride directive being set incorrectly for the directory in question. If it is set to None then .htaccess files will not even be looked for. If you do have one that is set, then be certain it covers the directory you are trying to use the .htaccess file in. This is normally accomplished by ensuring it is inside the proper Directory container.
This message is generally caused because either
You can determine which case applies to your situation by checking the error log.
In the case where file system permission are at fault, remember that not only must the directory and files in question be readable, but also all parent directories must be at least searchable by the web server in order for the content to be accessible.
Search your conf/httpd.conf file for this exact string: <Files ~>. If you find it, that's your problem -- that particular <Files> container is malformed. Delete it or replace it with <Files ~ "^\.ht"> and restart your server and things should work as expected.
This error appears to be caused by a problem with the version of linuxconf distributed with Redhat 6.x. It may reappear if you use linuxconf again.
If you don't find this string, check out the previous question.
MS Internet Explorer (MSIE) and Netscape handle mime type detection in different ways, and therefore will display the document differently. In particular, IE sometimes relies on the file extension or the contents of the file to determine the mime type. This can happen when the server specifies a mime type of application/octet-stream or text/plain. This behavior violates the the HTTP standard and makes it impossible to deliver plain text documents to MSIE clients in some cases. More details are available on MSIE's mime type detection behavior in an MSDN article and a note by Alan J. Flavell.
The best you can do as a server administrator is to accurately configure the mime type of your documents by editing the mime.types file or using an AddType directive in the Apache configuration files. In some cases, you may be able to fool MSIE into rendering text/plain documents correctly by assuring they have a .txt filename extension, but this will not work if MSIE thinks the content looks like another file type.
Many sites map a variety of hostnames to the same content. For example, www.example.com, example.com and www.example.net may all refer to the same site. It is best to make sure that, regardless of the name clients use to access the site, they will be redirected to a single, canonical hostname. This makes the site easier to maintain and assures that there will be only one version of the site in proxy caches and search engines.
There are two techniques to implement canonical hostnames:
NameVirtualHost *
<VirtualHost *>
ServerName www.example.net
ServerAlias example.com
Redirect permanent / http://www.example.com/
</VirtualHost>
<VirtualHost *>
ServerName www.example.com
DocumentRoot /usr/local/apache/htdocs
</VirtualHost>There are many possible reasons for this, and almost all of them are related to the configuration of your network, not the configuration of the Apache HTTP Server. One of the most common problems is that a firewall blocks access to the default HTTP port 80. In particular, many consumer ISPs block access to this port. You can see if this is the case by changing any Port and Listen directives in httpd.conf to use port 8000 and then request your site using http://yourhost.example.com:8000/. (Of course, a very restrictive firewall may block this port as well.)
If a client requests a URL that designates a directory and the directory does not contain a filename that matches the DirectoryIndex directive, then mod_autoindex can be configured to present a listing of the directory contents.
To turn on automatic directory indexing, find the Options directive that applies to the directory and add the Indexes keyword. For example:
<Directory /path/to/directory>
Options +Indexes
</Directory>To turn off automatic directory indexing, remove the Indexes keyword from the appropriate Options line. To turn off directory listing for a particular subdirectory, you can use Options -Indexes. For example:
<Directory /path/to/directory>
Options -Indexes
</Directory>Directives placed in the configuration files are applied in a very particular order, as described by How Directory, Location, and Files sections work. In addition, each Options directive has the effect of resetting the options to none before adding the specified options (unless only "+" and "-" options are used). The consequence is that Options set in the main server or virtual host context (outside any directory, location, or files section) will usually have no effect, because they are overridden by more specific Options directives. For example, in the following
<Directory /usr/local/apache/htdocs>
Options Indexes
</Directory>
Options Includes ExecCGI
Includes and ExecCGI will be off in the /usr/local/apache/htdocs directory.
You can usually avoid problems by either finding the Options directive that already applies to a specific directory and changing it, or by putting your Options directive inside the most specific possible <Directory> section.
When a client connects to Apache, part of the information returned in the headers is the name "Apache" Additional information that can be sent is the version number, such as "1.3.26", the operating system, and a list of non-standard modules you have installed.
For example:
Server: Apache/1.3.26 (Unix) mod_perl/1.26Frequently, 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: ApacheThe 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 ServerIn order to do this, you will need to modify the Apache source code and rebuild Apache. This is not advised, as it is almost certain not to provide you with the added security you think that you are gaining. The exact method of doing this is left as an exercise for the reader, as we are not keen on helping you do something that is intrinsically a bad idea.
A an access_log entry showing this situation could look like this:
63.251.56.142 - - [25/Jul/2002:12:48:04 -0700] "GET http://www.yahoo.com/ HTTP/1.0" 200 1456The 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>
...
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.
AddHandler cgi-script .cgiThe server will then recognize that all files in that location (and its logical descendants) that end in ".cgi" are script files, not documents.
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:
RewriteEngine on
RewriteBase /~foo/bar/
RewriteRule ^quux\.cgi$ - [T=application/x-httpd-cgi]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:
{
local ($oldbar) = $|;
$cfh = select (STDOUT);
$| = 1;
#
# print your HTTP headers here
#
$| = $oldbar;
select ($cfh);
}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.
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.
As of Apache 1.3, CGI scripts are essentially not buffered. Every time your script does a "flush" to output data, that data gets relayed on to the client. Some scripting languages, for example Perl, have their own buffering for output - this can be disabled by setting the $| special variable to 1. Of course this does increase the overall number of packets being transmitted, which can result in a sense of slowness for the end user.
Prior to 1.3, you needed to use "nph-" scripts to accomplish non-buffering. Today, the only difference between nph scripts and normal scripts is that nph scripts require the full HTTP headers to be sent.
The Common Gateway Interface (CGI) specification can be found at the original NCSA site < http://hoohoo.ncsa.uiuc.edu/cgi/interface.html>. This version hasn't been updated since 1995, and there have been some efforts to update it.
A new draft is being worked on with the intent of making it an informational RFC; you can find out more about this project at <http://web.golux.com/coar/cgi/>.
The simple answer is that it was becoming too difficult to keep the version being included with Apache synchronized with the master copy at the FastCGI web site. When a new version of Apache was released, the version of the FastCGI module included with it would soon be out of date.
You can still obtain the FastCGI module for Apache from the master FastCGI web site.
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
AddHandler server-parsed .shtmlThis 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 Apache Week article on Using Server Side Includes.
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.
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.
This is a feature The Apache Group hopes to add in the next major release after 1.3.
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.
ErrorDocument and SSI to simplify customized error messages?
Have a look at this document. It shows in example form how you can a combination of XSSI and negotiation to tailor a set of ErrorDocuments to your personal taste, and returning different internationalized error responses based on the client's native language.
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).
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:
ScriptAliasMatch ^/~([^/]*)/cgi-bin/(.*) /home/$1/cgi-bin/$2<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.
Two of the most common causes of this are:
EXTRA_CFLAGS=-DMAXIMUM_DNSThis 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.
There are several ways to do this; some of the more popular ones are to use the mod_auth, mod_auth_db, or mod_auth_dbm modules.
For an explanation on how to implement these restrictions, see Apache Week's articles on Using User Authentication or DBM User Authentication.
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 anySee the user authentication question and the mod_access module for details on how the above directives work.
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:
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.
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.
You have probably configured the Host by specifying a FQHN, and thus the libmsql will use a full blown TCP/IP socket to talk to the database, rather than a fast internal device. The libmsql, the mSQL FAQ, and the mod_auth_msql documentation warn you about this. If you have to use different hosts, check out the mod_auth_msql code for some compile time flags which might - or might not - suit you.
Yes, you can - but it's a very bad idea. Here are some of the reasons:
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.
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
ServerName to match the name you are using in the URL; and/orUseCanonicalName off.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.
There is a collection of Practical Solutions for URL-Manipulation where you can find all typical solutions the author of mod_rewrite currently knows of. If you have more interesting rulesets which solve particular problems not currently covered in this document, send it to Ralf S. Engelschall for inclusion. The other webmasters will thank you for avoiding the reinvention of the wheel.
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/9612149/>, the English (translated) version can be found at <http://www.heise.de/ix/artikel/E/9612149/>.
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 which is an integral part of Apache since its version 1.2. 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 as of 1.x 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.
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.
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.
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.
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.
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]".
Apache version 1.1 and above comes with a proxy module. If compiled in, this will make Apache act as a caching-proxy server.
"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".
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.
SSL (Secure Socket Layer) data transport requires encryption, and many governments have restrictions upon the import, export, and use of encryption technology. If Apache included SSL in the base package, its distribution would involve all sorts of legal and bureaucratic issues, and it would no longer be freely available. Also, some of the technology required to talk to current clients using SSL is patented by RSA Data Security, who restricts its use without a license.
Some SSL implementations of Apache are available, however; see the "related projects" page at the main Apache web site.
You can find out more about this topic in the Apache Week article about Apache and Secure Transactions.
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).
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.
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
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.
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.
The base Apache Web server package does not include ASP support. However, there are a couple of after-market solutions that let you add this functionality; see the related projects page to find out more.
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 the Apache/Java project site, <URL:http://jakarta.apache.org/>.
