<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <TITLE>Apache Server Frequently Asked Questions</TITLE> </HEAD> <!-- Background white, links blue (unvisited), navy (visited), red (active) --> <BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#000080" ALINK="#FF0000" > <!--#include virtual="header.html" --> <H1 ALIGN="CENTER">Apache Server Frequently Asked Questions</H1> <P> $Revision: 1.83 $ ($Date: 1997/07/08 15:56:30 $) </P> <P> The latest version of this FAQ is always available from the main Apache web site, at <<A HREF="http://www.apache.org/docs/misc/FAQ" REL="Help" ><SAMP>http://www.apache.org/docs/misc/FAQ</SAMP></A>>. </P> <!-- Notes about changes: --> <!-- - If adding a relative link to another part of the --> <!-- documentation, *do* include the ".html" portion. There's a --> <!-- good chance that the user will be reading the documentation --> <!-- on his own system, which may not be configured for --> <!-- multiviews. Leave off the ".html" extension for absolute --> <!-- links to sites which are known to run multiviews (e.g., --> <!-- apache.org or apacheweek.com). --> <!-- - When adding items, make sure they're put in the right place --> <!-- - verify that the numbering matches up. --> <!-- - *Don't* use <PRE></PRE> blocks - they don't appear --> <!-- correctly in a reliable way when this is converted to text --> <!-- with Lynx. Use <DL><DD><CODE>xxx<BR>xx</CODE></DD></DL> --> <!-- blocks inside a <P></P> instead. This is necessary to get --> <!-- the horizontal and vertical indenting right. --> <!-- - Don't forget to include an HR tag after the last /P tag --> <!-- but before the /LI in an item. --> <P> 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. </P> <H2>The Questions</H2> <!-- Stuff to Add: --> <!-- - can't bind to port 80 --> <!-- - permission denied --> <!-- - address already in use --> <!-- - mod_auth & passwd lines "user:pw:.*" - ++1st colon onward is --> <!-- treated as pw, not just ++1st to --2nd. --> <!-- - SSL: --> <!-- - Can I use Apache-SSL for free in Canada? --> <!-- - Why can't I use Apache-SSL in the U.S.? --> <!-- - How can I found out how many visitors my site gets? --> <!-- - How do I add a counter? --> <!-- - How do I configure Apache as a proxy? --> <!-- - What browsers support HTTP/1.1? --> <!-- - What's the point of vhosts-by-name is there aren't any --> <!-- HTTP/1.1 browsers? --> <!-- - Is there an Apache for W95/WNT? --> <!-- - Why does Apache die when a vhost can't be DNS-resolved? --> <!-- - Why do I get "send lost connection" messages in my error --> <!-- log? --> <!-- - specifically consider .pdf files which seem to cause this --> <!-- a lot when accessed via the plugin ... and also mention --> <!-- how range-requests can cause bytes served < file size --> <!-- - Why do directory indexes appear as garbage? (A: -lucb) --> <!-- - How do I add a footer to all pages offered by my server? --> <!-- - Fix midi question; a bigger problem than midi vs. x-midi is --> <!-- the simple fact that older versions of Apache (and new ones --> <!-- that have been upgraded without upgrading the mime.types --> <!-- file) don't have the type listed at all. --> <UL> <LI><STRONG>Background</STRONG> <OL START=1> <LI><A HREF="#what">What is Apache?</A> </LI> <LI><A HREF="#why">Why was Apache created?</A> </LI> <LI><A HREF="#relate">How does The Apache Group's work relate to other servers?</A> </LI> <LI><A HREF="#name">Why the name "Apache"?</A> </LI> <LI><A HREF="#compare">OK, so how does Apache compare to other servers?</A> </LI> <LI><A HREF="#tested">How thoroughly tested is Apache?</A> </LI> <LI><A HREF="#future">What are the future plans for Apache?</A> </LI> <LI><A HREF="#support">Whom do I contact for support?</A> </LI> <LI><A HREF="#more">Is there any more information on Apache?</A> </LI> <LI><A HREF="#where">Where can I get Apache?</A> </LI> </OL> </LI> <LI><STRONG>Technical Questions</STRONG> <OL START=11> <LI><A HREF="#what2do">"Why can't I ...? Why won't ... work?" What to do in case of problems</A> </LI> <LI><A HREF="#compatible">How compatible is Apache with my existing NCSA 1.3 setup?</A> </LI> <LI><A HREF="#CGIoutsideScriptAlias">How do I enable CGI execution in directories other than the ScriptAlias?</A> </LI> <LI><A HREF="#premature-script-headers">What does it mean when my CGIs fail with "<SAMP>Premature end of script headers</SAMP>"?</A> </LI> <LI><A HREF="#ssi-part-i">How do I enable SSI (parsed HTML)?</A> </LI> <LI><A HREF="#ssi-part-ii">Why don't my parsed files get cached?</A> </LI> <LI><A HREF="#ssi-part-iii">How can I have my script output parsed?</A> </LI> <LI><A HREF="#proxy">Does or will Apache act as a Proxy server?</A> </LI> <LI><A HREF="#multiviews">What are "multiviews"?</A> </LI> <LI><A HREF="#fdlim">Why can't I run more than <<EM>n</EM>> virtual hosts?</A> </LI> <LI><A HREF="#freebsd-setsize">Can I increase FD_SETSIZE on FreeBSD?</A> </LI> <LI><A HREF="#limitGET">Why do I keep getting "access denied" for form POST requests?</A> </LI> <LI><A HREF="#passwdauth">Can I use my <SAMP>/etc/passwd</SAMP> file for Web page authentication?</A> </LI> <LI><A HREF="#errordoc401">Why doesn't my <CODE>ErrorDocument 401</CODE> work?</A> </LI> <LI><A HREF="#setgid">Why do I get "<SAMP>setgid: Invalid argument</SAMP>" at startup?</A> </LI> <LI><A HREF="#cookies1">Why does Apache send a cookie on every response?</A> </LI> <LI><A HREF="#cookies2">Why don't my cookies work, I even compiled in <SAMP>mod_cookies</SAMP>?</A> </LI> <LI><A HREF="#jdk1-and-http1.1">Why do my Java app[let]s give me plain text when I request an URL from an Apache server?</A> </LI> <LI><A HREF="#putsupport">Why can't I publish to my Apache server using PUT on Netscape Gold and other programs?</A> </LI> <LI><A HREF="#fastcgi">Why isn't FastCGI included with Apache any more?</A> </LI> <LI><A HREF="#nodelay">Why am I getting "<SAMP>httpd: could not set socket option TCP_NODELAY</SAMP>" in my error log?</A> </LI> <LI><A HREF="#peerreset">Why am I getting "<SAMP>connection reset by peer</SAMP>" in my error log?</A> </LI> <LI><A HREF="#nph-scripts">How can I get my script's output without Apache buffering it?</A> </LI> <LI><A HREF="#linuxiovec">Why do I get complaints about redefinition of "<CODE>struct iovec</CODE>" when compiling under Linux?</A> </LI> <LI><A HREF="#wheres-the-dump">The errorlog says Apache dumped core, but where's the dump file?</A> </LI> <LI><A HREF="#dnsauth">Why isn't restricting access by host or domain name working correctly?</A> </LI> <LI><A HREF="#SSL-i">Why doesn't Apache include SSL?</A> </LI> <LI><A HREF="#HPUX-core">Why do I get core dumps under HPUX using HP's ANSI C compiler?</A> </LI> <LI><A HREF="#midi">How do I get Apache to send a MIDI file so the browser can play it?</A> </LI> <LI><A HREF="#cantbuild">Why won't Apache compile with my system's <SAMP>cc</SAMP>?</A> </LI> <LI><A HREF="#addlog">How do I add browsers and referrers to my logs?</A> </LI> <LI><A HREF="#bind8.1">Why do I get an error about an undefined reference to "<SAMP>__inet_ntoa</SAMP>" or other <SAMP>__inet_*</SAMP> symbols?</A> </LI> <LI><A HREF="#set-servername">Why does accessing directories only work when I include the trailing "/" (<EM>e.g.</EM>, <SAMP>http://foo.domain.com/~user/</SAMP>) but not when I omit it (<EM>e.g.</EM>, <SAMP>http://foo.domain.com/~user</SAMP>)?</A> </LI> <LI><A HREF="#user-authentication">How do I set up Apache to require a username and password to access certain documents?</A> </LI> <LI><A HREF="#remote-auth-only">How do I set up Apache to allow access to certain documents only if a site is either a local site <EM>or</EM> the user supplies a password and username?</A> </LI> <LI><A HREF="#no-info-directives">Why doesn't mod_info list any directives?</A> <LI><A HREF="#linux-shmget">When I run it under Linux I get "shmget: function not found", what should I do?</A> </LI> <LI><A HREF="#authauthoritative">Why does my authentification give me a server error?</A> <LI><A HREF="#auth-on-same-machine">Do I have to keep the (mSQL) authentification information on the same machine?</A> </LI> <LI><A HREF="#msql-slow">Why is my mSQL authentification terribly slow?</A> </LI> </OL> </LI> </UL> <HR> <H2>The Answers</H2> <H3> Background </H3> <OL START=1> <LI><A NAME="what"> <STRONG>What is Apache?</STRONG> </A> <P> Apache was originally based on code and ideas found in the most popular HTTP server of the time.. NCSA httpd 1.3 (early 1995). It has since evolved into a far superior system which can rival (and probably surpass) almost any other UNIX based HTTP server in terms of functionality, efficiency and speed. </P> <P> Since it began, it has been completely rewritten, and includes many new features. Apache is, as of January 1997, the most popular WWW server on the Internet, according to the <A HREF="http://www.netcraft.com/Survey/" >Netcraft Survey</A>. </P> <HR> </LI> <LI><A NAME="why"> <STRONG>Why was Apache created?</STRONG> </A> <P> To address the concerns of a group of WWW providers and part-time httpd programmers that httpd didn't behave as they wanted it to behave. Apache is an entirely volunteer effort, completely funded by its members, not by commercial sales. </P> <HR> </LI> <LI><A NAME="relate"> <STRONG>How does The Apache Group's work relate to other server efforts, such as NCSA's?</STRONG> </A> <P> We, of course, owe a great debt to NCSA and their programmers for making the server Apache was based on. We now, however, have our own server, and our project is mostly our own. The Apache Project is an entirely independent venture. </P> <HR> </LI> <LI><A NAME="name"> <STRONG>Why the name "Apache"?</STRONG> </A> <P> A cute name which stuck. Apache is "<STRONG>A PA</STRONG>t<STRONG>CH</STRONG>y server". It was based on some existing code and a series of "patch files". </P> <HR> </LI> <LI><A NAME="compare"> <STRONG>OK, so how does Apache compare to other servers?</STRONG> </A> <P> For an independent assessment, see <A HREF="http://webcompare.iworld.com/compare/chart.html" >Web Compare</A>'s comparison chart. </P> <P> Apache has been shown to be substantially faster than many other free 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. </P> <HR> </LI> <LI><A NAME="tested"> <STRONG>How thoroughly tested is Apache?</STRONG> </A> <P> Apache is run on over 400,000 Internet servers (as of April 1997). 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 third 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. </P> <P> The Apache project's web site includes a page with a partial list of <A HREF="http://www.apache.org/info/apache_users" >sites running Apache</A>. </P> <HR> </LI> <LI><A NAME="future"> <STRONG>What are the future plans for Apache?</STRONG> </A> <P> <UL> <LI>to continue as a public domain HTTP server, </LI> <LI>to keep up with advances in HTTP protocol and web developments in general, </LI> <LI>to collect suggestions for fixes/improvements from its users, </LI> <LI>to respond to needs of large volume providers as well as occasional users. </LI> </UL> </P> <HR> </LI> <LI><A NAME="support"> <STRONG>Whom do I contact for support?</STRONG> </A> <P> 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 <EM>via</EM> <A HREF="http://www.apache.org/bug_report" >the bug report page</A>. Other questions should be directed to the <A HREF="news:comp.infosystems.www.servers.unix" ><SAMP>comp.infosystems.www.servers.unix</SAMP></A> newsgroup, where some of the Apache team lurk, in the company of many other httpd gurus who should be able to help. </P> <P> Commercial support for Apache is, however, available from a number of third parties. </P> <HR> </LI> <LI><A NAME="more"> <STRONG>Is there any more information available on Apache?</STRONG> </A> <P> Indeed there is. See the main <A HREF="http://www.apache.org/" >Apache web site</A>. There is also a regular electronic publication called <A HREF="http://www.apacheweek.com/" REL="Help" ><CITE>Apache Week</CITE></A> available. Links to relevant <CITE>Apache Week</CITE> articles are included below where appropriate. </P> <HR> </LI> <LI><A NAME="where"> <STRONG>Where can I get Apache?</STRONG> </A> <P> You can find out how to download the source for Apache at the project's <A HREF="http://www.apache.org/" >main web page</A>. </P> <HR> </LI> </OL> <H3> Technical Questions </H3> <OL START=11> <LI><A NAME="what2do"> <STRONG>"Why can't I ...? Why won't ... work?" What to do in case of problems</STRONG> </A> <P> If you are having trouble with your Apache server software, you should take the following steps: </P> <OL> <LI><STRONG>Check the errorlog!</STRONG> <P> 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 <SAMP>/usr/local/etc/httpd/logs/error_log</SAMP>, but see the <A HREF="../mod/core.html#errorlog" ><SAMP>ErrorLog</SAMP></A> directive in your config files for the location on your server. </P> </LI> <LI><STRONG>Check the <A HREF="http://www.apache.org/docs/misc/FAQ.html" >FAQ</A>!</STRONG> <P> The latest version of the Apache Frequently-Asked Questions list can always be found at the main Apache web site. </P> </LI> <LI><STRONG>Check the Apache bug database</STRONG> <P> Most problems that get reported to The Apache Group are recorded in the <A HREF="http://www.apache.org/bugdb.cgi" >bug database</A>. <EM><STRONG>Please</STRONG> check the existing reports, open <STRONG>and</STRONG> closed, before adding one.</EM> If you find that your issue has already been reported, please <EM>don't</EM> 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. </P> </LI> <LI><STRONG>Ask in the <SAMP>comp.infosystems.www.servers.unix</SAMP> USENET newsgroup</STRONG> <P> A lot of common problems never make it to the bug database because there's already high Q&A traffic about them in the <A HREF="news:comp.infosystems.www.servers.unix" ><SAMP>comp.infosystems.www.servers.unix</SAMP></A> newsgroup. Many Apache users, and some of the developers, can be found roaming its 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 <EM>don't</EM> see your question already posted. </P> </LI> <LI><STRONG>If all else fails, report the problem in the bug database</STRONG> <P> If you've gone through those steps above that are appropriate and have obtained no relief, then please <EM>do</EM> let The Apache Group know about the problem by <A HREF="http://www.apache.org/bugdb.cgi" >logging a bug report</A>. </P> <P> If your problem involves the server crashing and generating a core dump, please include a backtrace (if possible). As an example, </P> <P> <DL> <DD><CODE># cd <EM>ServerRoot</EM><BR> # dbx httpd core<BR> (dbx) where</CODE> </DD> </DL> </P> <P> (Substitute the appropriate locations for your <SAMP>ServerRoot</SAMP> and your <SAMP>httpd</SAMP> and <SAMP>core</SAMP> files. You may have to use <CODE>gdb</CODE> instead of <CODE>dbx</CODE>.) </P> </LI> </OL> <HR> </LI> <LI><A NAME="compatible"> <STRONG>How compatible is Apache with my existing NCSA 1.3 setup?</STRONG> </A> <P> 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. </P> <P> 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. </P> <P> Friendly interaction between Apache and NCSA developers should ensure that fundamental feature enhancements stay consistent between the two servers for the foreseeable future. </P> <HR> </LI> <LI><A NAME="CGIoutsideScriptAlias"> <STRONG>How do I enable CGI execution in directories other than the ScriptAlias?</STRONG> </A> <P> Apache recognizes all files in a directory named as a <A HREF="../mod/mod_alias.html#scriptalias" ><SAMP>ScriptAlias</SAMP></A> 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 "<SAMP>*.cgi</SAMP>" or "<SAMP>*.pl</SAMP>" or whatever. In other words, <EM>all</EM> files in a ScriptAlias directory are scripts, as far as Apache is concerned. </P> <P> 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 <A HREF="../mod/mod_mime.html#addhandler" ><SAMP>AddHandler</SAMP></A> directive. </P> <OL> <LI>In an appropriate section of your server configuration files, add a line such as <P> <DL> <DD><CODE>AddHandler cgi-script .cgi</CODE> </DD> </DL> </P> <P> The server will then recognize that all files in that location (and its logical descendants) that end in "<SAMP>.cgi</SAMP>" are script files, not documents. </P> </LI> <LI>Make sure that the directory location is covered by an <A HREF="../mod/core.html#options" ><SAMP>Options</SAMP></A> declaration that includes the <SAMP>ExecCGI</SAMP> option. <P> </P> </LI> </OL> <HR> </LI> <LI><A NAME="premature-script-headers"> <STRONG>What does it mean when my CGIs fail with "<SAMP>Premature end of script headers</SAMP>"?</STRONG> </A> <P> 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. </P> <P> 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. </P> <P> 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 <CODE>print</CODE> or <CODE>write</CODE> statements that send your HTTP headers: </P> <P> <DL> <DD><CODE>{<BR> local ($oldbar) = $|;<BR> $cfh = select (STDOUT);<BR> $| = 1;<BR> #<BR> # print your HTTP headers here<BR> #<BR> $| = $oldbar;<BR> select ($cfh);<BR> }</CODE> </DD> </DL> </P> <P> 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 maximise performance, you should turn buffer-flushing back <EM>off</EM> (with <CODE>$| = 0</CODE> or the equivalent) after the statements that send the headers, as displayed above. </P> <P> If your script isn't written in Perl, do the equivalent thing for whatever language you <EM>are</EM> using (<EM>e.g.</EM>, for C, call <CODE>fflush()</CODE> after writing the headers). </P> <HR> </LI> <LI><A NAME="ssi-part-i"> <STRONG>How do I enable SSI (parsed HTML)?</STRONG> </A> <P> SSI (an acronym for Server-Side Include) directives allow static HTML documents to be enhanced at run-time (<EM>e.g.</EM>, when delivered to a client by Apache). The format of SSI directives is covered in the <A HREF="../mod/mod_include.html">mod_include manual</A>; suffice it to say that Apache supports not only SSI but xSSI (eXtended SSI) directives. </P> <P> Processing a document at run-time is called <EM>parsing</EM> it; hence the term "parsed HTML" sometimes used for documents that contain SSI instructions. Parsing tends to be <EM>extremely</EM> resource-consumptive, 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 <A HREF="#ssi-part-ii" >next question</A> for more information about this.) </P> <P> To enable SSI processing, you need to </P> <UL> <LI>Build your server with the <A HREF="../mod/mod_include.html" ><SAMP>mod_include</SAMP></A> module. This is normally compiled in by default. </LI> <LI>Make sure your server configuration files have an <A HREF="../mod/core.html#options" ><SAMP>Options</SAMP></A> directive which permits <SAMP>Includes</SAMP>. </LI> <LI>Make sure that the directory where you want the SSI documents to live is covered by the "server-parsed" content handler, either explicitly or in some ancestral location. That can be done with the following <A HREF="../mod/mod_mime.html#addhandler" ><SAMP>AddHandler</SAMP></A> directive: <P> <DL> <DD><CODE>AddHandler server-parsed .shtml</CODE> </DD> </DL> </P> 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. </LI> </UL> <P> For additional information, see the <CITE>Apache Week</CITE> article on <A HREF="http://www.apacheweek.com/features/ssi" REL="Help" ><CITE>Using Server Side Includes</CITE></A>. </P> <HR> </LI> <LI><A NAME="ssi-part-ii"> <STRONG>Why don't my parsed files get cached?</STRONG> </A> <P> 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 <SAMP>Content-Length</SAMP> or <SAMP>Last-Modified</SAMP> headers. Caches commonly work by comparing the <SAMP>Last-Modified</SAMP> 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. </P> <P> You can work around this in some cases by causing an <SAMP>Expires</SAMP> header to be generated. (See the <A HREF="../mod/mod_expires.html" REL="Help" ><SAMP>mod_expires</SAMP></A> documentation for more details.) Another possibility is to use the <A HREF="../mod/mod_include.html#xbithack" REL="Help" ><SAMP>XBitHack Full</SAMP></A> mechanism, which tells Apache to send (under certain circumstances detailed in the XBitHack directive description) a <SAMP>Last-Modified</SAMP> 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. </P> <HR> </LI> <LI><A NAME="ssi-part-iii"> <STRONG>How can I have my script output parsed?</STRONG> </A> <P> 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. </P> <P> This is a feature The Apache Group hopes to add in the next major release after 1.2. </P> <HR> </LI> <LI><A NAME="proxy"> <STRONG>Does or will Apache act as a Proxy server?</STRONG> </A> <P> Apache version 1.1 and above comes with a <A HREF="../mod/mod_proxy.html" >proxy module</A>. If compiled in, this will make Apache act as a caching-proxy server. </P> <HR> </LI> <LI><A NAME="multiviews"> <STRONG>What are "multiviews"?</STRONG> </A> <P> "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 <A HREF="../content-negotiation.html" REL="Help" >content negotiation</A> description page. In addition, <CITE>Apache Week</CITE> carried an article on this subject entitled "<A HREF="http://www.apacheweek.com/features/negotiation" REL="Help" ><CITE>Content Negotiation Explained</CITE></A>". </P> <HR> </LI> <LI><A NAME="fdlim"> <STRONG>Why can't I run more than <<EM>n</EM>> virtual hosts?</STRONG> </A> <P> You are probably running into resource limitations in your operating system. The most common limitation is the <EM>per</EM>-process limit on <STRONG>file descriptors</STRONG>, 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 <CODE>gethostbyname()</CODE>) which needs file descriptors and doesn't complain intelligibly when it can't get them. </P> <P> 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 <A HREF="../mod/core.html#listen" ><SAMP>Listen</SAMP></A> directive also needs a file descriptor. </P> <P> Typical values for <<EM>n</EM>> 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. </P> <P> As to what you can do about this: </P> <OL> <LI>Reduce the number of <A HREF="../mod/core.html#listen" ><SAMP>Listen</SAMP></A> directives. If there are no other servers running on the machine on the same port then you normally don't need any Listen directives at all. By default Apache listens to all addresses on port 80. </LI> <LI>Reduce the number of log files. You can use <A HREF="../mod/mod_log_config.html" ><SAMP>mod_log_config</SAMP></A> to log all requests to a single log file while including the name of the virtual host in the log file. You can then write a script to split the logfile into separate files later if necessary. </LI> <LI>Increase the number of file descriptors available to the server (see your system's documentation on the <CODE>limit</CODE> or <CODE>ulimit</CODE> commands). For some systems, information on how to do this is available in the <A HREF="perf.html" >performance hints</A> page. There is a specific note for <a href="#freebsd-setsize">FreeBSD</a> below. </LI> <LI>"Don't do that" - try to run with fewer virtual hosts </LI> <LI>Spread your operation across multiple server processes (using <A HREF="../mod/core.html#listen" ><SAMP>Listen</SAMP></A> for example, but see the first point) and/or ports. </LI> </OL> <P> Since this is an operating-system limitation, there's not much else available in the way of solutions. <P> As of 1.2.1 we have made attempts to work around various limitations involving running with many descriptors. <a href="descriptors.html">More information is available.</a> </P> <HR> </LI> <LI><A NAME="freebsd-setsize"> <STRONG>Can I increase <SAMP>FD_SETSIZE</SAMP> on FreeBSD?</STRONG> </A> <P> On FreeBSD 2.2 and older <SAMP>FD_SETSIZE</SAMP>, which limits the number of open files on the system, is limited to 256. This can restrict the number of virtual hosts you can use; especially if they all use different log files. Increasing this limit (and recompiling Apache) is not enough, as it is on some platforms (such as Solaris), as you also will have to recompile <SAMP>libc</SAMP> with the changed setting. </P> <P> On FreeBSD 3.0 the default is 1024, so the problem is lessened. </P> <HR> </LI> <LI><A NAME="limitGET"> <STRONG>Why do I keep getting "access denied" for form POST requests?</STRONG> </A> <P> The most common cause of this is a <SAMP><Limit></SAMP> section that only names the <SAMP>GET</SAMP> method. Look in your configuration files for something that resembles the following and would affect the location where the POST-handling script resides: </P> <P> <DL> <DD><CODE><Limit GET><BR> :</CODE> </DD> </DL> </P> <P> Change that to <CODE><Limit GET POST></CODE> and the problem will probably go away. </P> <HR> </LI> <LI><A NAME="passwdauth"> <STRONG>Can I use my <SAMP>/etc/passwd</SAMP> file for Web page authentication?</STRONG> </A> <P> Yes, you can - but it's a <STRONG>very bad idea</STRONG>. Here are some of the reasons: </P> <UL> <LI>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 <SAMP>root</SAMP> 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 <EM>n</EM> failed passwords for the same account within <EM>m</EM> seconds) and evasion (breaking the connection, disabling the account under attack, disabling <EM>all</EM> logins from that source, <EM>et cetera</EM>), but the Web does not. </LI> <LI>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. </LI> <LI>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 - <EM>if</EM> you look at the logs. </LI> <LI>Web authentication passwords (at least for Basic authentication) generally fly across the wire, and through intermediate proxy systems, in what amounts to plaintext. "O'er the net we go/Caching all the way;/O what fun it is to surf/Giving my password away!" </LI> <LI>Since HTTP is stateless, information about the authentication is transmitted <EM>each and every time</EM> 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. </LI> <LI>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"? </LI> </UL> <P> 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. </P> <HR> </LI> <LI><A NAME="errordoc401"> <STRONG>Why doesn't my <CODE>ErrorDocument 401</CODE> work?</STRONG> </A> <P> You need to use it with a URL in the form "<SAMP>/foo/bar</SAMP>" and not one with a method and hostname such as "<SAMP>http://host/foo/bar</SAMP>". See the <A HREF="../mod/core.html#errordocument" ><SAMP>ErrorDocument</SAMP></A> documentation for details. This was incorrectly documented in the past. </P> <HR> </LI> <LI><A NAME="setgid"> <STRONG>Why do I get "<SAMP>setgid: Invalid argument</SAMP>" at startup?</STRONG> </A> <P> Your <A HREF="../mod/core.html#group" ><SAMP>Group</SAMP></A> directive (probably in <SAMP>conf/httpd.conf</SAMP>) needs to name a group that actually exists in the <SAMP>/etc/group</SAMP> file (or your system's equivalent). </P> <HR> </LI> <LI><A NAME="cookies1"> <STRONG>Why does Apache send a cookie on every response?</STRONG> </A> <P> Apache does <EM>not</EM> send automatically send a cookie on every response, unless you have re-compiled it with the <A HREF="../mod/mod_cookies.html" ><SAMP>mod_cookies</SAMP></A> module. This module was distributed with Apache prior to 1.2. This module may help track users, and uses cookies to do this. If you are not using the data generated by <SAMP>mod_cookies</SAMP>, do not compile it into Apache. Note that in 1.2 this module was renamed to the more correct name <A HREF="../mod/mod_usertrack.html" ><SAMP>mod_usertrack</SAMP></A>, and cookies have to be specifically enabled with the <A HREF="../mod/mod_usertrack.html#cookietracking" ><SAMP>CookieTracking</SAMP></A> directive. </P> <HR> </LI> <LI><A NAME="cookies2"> <STRONG>Why don't my cookies work, I even compiled in <SAMP>mod_cookies</SAMP>? </STRONG> </A> <P> Firstly, you do <EM>not</EM> need to compile in <SAMP>mod_cookies</SAMP> in order for your scripts to work (see the <A HREF="#cookies1" >previous question</A> for more about <SAMP>mod_cookies</SAMP>). Apache passes on your <SAMP>Set-Cookie</SAMP> 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. </P> <HR> </LI> <LI><A NAME="jdk1-and-http1.1"> <STRONG>Why do my Java app[let]s give me plain text when I request an URL from an Apache server?</STRONG> </A> <P> 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. </P> <P> 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 <EM>your</EM> 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. </P> <P> 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: </P> <P> <DL> <DD><CODE>BrowserMatch Java1.0 force-response-1.0 <BR> BrowserMatch JDK/1.0 force-response-1.0</CODE> </DD> </DL> </P> <P> More information about this issue can be found in the <A HREF="http://www.apache.org/info/jdk-102" ><CITE>Java and HTTP/1.1</CITE></A> page at the Apache web site. </P> <HR> </LI> <LI><A NAME="putsupport"> <STRONG>Why can't I publish to my Apache server using PUT on Netscape Gold and other programs?</STRONG> </A> <P> 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 <CITE>Apache Week</CITE> article <A HREF="http://www.apacheweek.com/features/put" ><CITE>Publishing Pages with PUT</CITE></A>. </P> <HR> </LI> <LI><A NAME="fastcgi"> <STRONG>Why isn't FastCGI included with Apache any more?</STRONG> </A> <P> 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 <A HREF="http://www.fastcgi.com/servers/apache/" >FastCGI web site</A>. When a new version of Apache was released, the version of the FastCGI module included with it would soon be out of date. </P> <P> You can still obtain the FastCGI module for Apache from the master FastCGI web site. </P> <HR> </LI> <LI><A NAME="nodelay"> <STRONG>Why am I getting "<SAMP>httpd: could not set socket option TCP_NODELAY</SAMP>" in my error log?</STRONG> </A> <P> This message almost always indicates that the client disconnected before Apache reached the point of calling <CODE>setsockopt()</CODE> 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. </P> <HR> </LI> <LI><A NAME="peerreset"> <STRONG>Why am I getting "<SAMP>connection reset by peer</SAMP>" in my error log?</STRONG> </A> <P> This is a normal message and nothing about which to be alarmed. It simply means that the client cancelled 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. </P> <HR> </LI> <LI><A NAME="nph-scripts"> <STRONG>How can I get my script's output without Apache buffering it?</STRONG> </A> <P> In order to improve network performance, Apache buffers script output into relatively large chunks. If you have a script that sends information in bursts (such as partial-done messages in a multi-commit database transaction, perhaps), the client will not necessarily get the output as the script is generating it. </P> <P> To avoid this, Apache recognizes scripts whose names begin with "<SAMP>nph-</SAMP>" as <EM>non-parsed-header</EM> scripts. That is, Apache won't buffer their output, but connect it directly to the socket going back to the client. </P> <P> While this will probably do what you want, there <EM>are</EM> some disadvantages to it: </P> <UL> <LI><STRONG>YOU</STRONG> (the script) are responsible for generating <STRONG>ALL</STRONG> of the HTTP headers, and no longer <EM>just</EM> the "<SAMP>Content-type</SAMP>" or "<SAMP>Location</SAMP>" headers </LI> <LI>Unless your script generates its output carefully, you will see a performance penalty as excessive numbers of packets go back and forth </LI> </UL> <P> As an example how you might handle the former (in a Perl script): </P> <P> <DL> <DD><CODE>if ($0 =~ m:^(.*/)*nph-[^/]*$:) { <BR> $HTTP_headers = "HTTP/1.1 200 OK\015\012"; <BR> $HTTP_headers .= "Connection: close\015\012"; <BR> print $HTTP_headers; <BR> }</CODE> </DD> </DL> </P> <P> and then follow with your normal non-<SAMP>nph</SAMP> headers. </P> <HR> </LI> <LI><A NAME="linuxiovec"> <STRONG>Why do I get complaints about redefinition of "<CODE>struct iovec</CODE>" when compiling under Linux?</STRONG> </A> <P> 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: </P> <P> <UL> <LI>Remove the definition of <CODE>struct iovec</CODE> from your C library includes. It is located in <CODE>/usr/include/sys/uio.h</CODE>. <STRONG>Or,</STRONG> </LI> <LI>Add <CODE>-DNO_WRITEV</CODE> to the <CODE>EXTRA_CFLAGS</CODE> line in your <SAMP>Configuration</SAMP> and reconfigure/rebuild. This hurts performance and should only be used as a last resort. </LI> </UL> </P> <HR> </LI> <LI><A NAME="wheres-the-dump"> <STRONG>The errorlog says Apache dumped core, but where's the dump file?</STRONG> </A> <P> 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 <CODE>setuid()</CODE> 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. </P> <P> 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 <EM>is</EM> a documented way of bypassing it, it is recommended that you bypass it only for the <SAMP>httpd</SAMP> server process if possible. </P> <P> The canonical location for Apache's core-dump files is the <A HREF="../mod/core.html#serverroot" >ServerRoot</A> directory. </P> <HR> </LI> <LI><A NAME="dnsauth"> <STRONG>Why isn't restricting access by host or domain name working correctly?</STRONG> </A> <P> Two of the most common causes of this are: </P> <OL> <LI><STRONG>An error, inconsistency, or unexpected mapping in the DNS registration</STRONG> <BR> This happens frequently: your configuration restricts access to <SAMP>Host.FooBar.Com</SAMP>, but you can't get in from that host. The usual reason for this is that <SAMP>Host.FooBar.Com</SAMP> is actually an alias for another name, and when Apache performs the address-to-name lookup it's getting the <EM>real</EM> name, not <SAMP>Host.FooBar.Com</SAMP>. 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. </LI> <LI><STRONG>Inadequate checking and verification in your configuration of Apache</STRONG> <BR> 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 the <SAMP>-DMAXIMUM_DNS</SAMP> clause to the <SAMP>EXTRA_CFLAGS</SAMP> definition in your <SAMP>Configuration</SAMP> file. For example: <P> <DL> <DD><CODE>EXTRA_CFLAGS=-DMAXIMUM_DNS</CODE> </DD> </DL> </P> <P> This will cause Apache to be very paranoid about making sure a particular host address is <EM>really</EM> assigned to the name it claims to be. Note that this <EM>can</EM> incur a significant performance penalty, however, because of all the name resolution requests being sent to a nameserver. </P> </LI> </OL> <HR> </LI> <LI><A NAME="SSL-i"> <STRONG>Why doesn't Apache include SSL?</STRONG> </A> <P> 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 <A HREF="http://www.rsa.com/">RSA Data Security</A>, who restricts its use without a license. </P> <P> Some SSL implementations of Apache are available, however; see the "<A HREF="http://www.apache.org/related_projects" >related projects</A>" page at the main Apache web site. </P> <P> You can find out more about this topic in the <CITE>Apache Week</CITE> article about <A HREF="http://www.apacheweek.com/features/ssl" REL="Help" ><CITE>Apache and Secure Transactions</CITE></A>. </P> <HR> </LI> <LI><A NAME="HPUX-core"> <STRONG>Why do I get core dumps under HPUX using HP's ANSI C compiler?</STRONG> </A> <P> We have had numerous reports of Apache dumping core when compiled with HP's ANSI C compiler using optimization. Disabling the compiler optimization has fixed these problems. </P> <HR> </LI> <LI><A NAME="midi"> <STRONG>How do I get Apache to send a MIDI file so the browser can play it?</STRONG> </A> <P> Even though the registered MIME type for MIDI files is <SAMP>audio/midi</SAMP>, some browsers are not set up to recognize it as such; instead, they look for <SAMP>audio/x-midi</SAMP>. There are two things you can do to address this: </P> <OL> <LI>Configure your browser to treat documents of type <SAMP>audio/midi</SAMP> correctly. This is the type that Apache sends by default. This may not be workable, however, if you have many client installations to change, or if some or many of the clients are not under your control. </LI> <LI>Instruct Apache to send a different <SAMP>Content-type</SAMP> header for these files by adding the following line to your server's configuration files: <P> <DL> <DD><CODE>AddType audio/x-midi .mid .midi .kar</CODE> </DD> </DL> </P> <P> Note that this may break browsers that <EM>do</EM> recognize the <SAMP>audio/midi</SAMP> MIME type unless they're prepared to also handle <SAMP>audio/x-midi</SAMP> the same way. </P> </LI> </OL> <HR> </LI> <LI><A NAME="cantbuild"> <STRONG>Why won't Apache compile with my system's <SAMP>cc</SAMP>?</STRONG> </A> <P> If the server won't compile on your system, it is probably due to one of the following causes: </P> <UL> <LI><STRONG>The <SAMP>Configure</SAMP> script doesn't recognize your system environment.</STRONG> <BR> This might be either because it's completely unknown or because the specific environment (include files, OS version, <EM>et cetera</EM>) isn't explicitly handled. If this happens, you may need to port the server to your OS yourself. </LI> <LI><STRONG>Your system's C compiler is garbage.</STRONG> <BR> Some operating systems include a default C compiler that is either not ANSI C-compliant or suffers from other deficiencies. The usual recommendation in cases like this is to acquire, install, and use <SAMP>gcc</SAMP>. </LI> <LI><STRONG>Your <SAMP>include</SAMP> files may be confused.</STRONG> <BR> In some cases, we have found that a compiler installation or system upgrade has left the C header files in an inconsistent state. Make sure that your include directory tree is in sync with the compiler and the operating system. </LI> <LI><STRONG>Your operating system or compiler may be out of revision.</STRONG> <BR> Software vendors (including those that develop operating systems) issue new releases for a reason; sometimes to add functionality, but more often to fix bugs that have been discovered. Try upgrading your compiler and/or your operating system. </LI> </UL> <P> 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 <A HREF="http://www.apache.org/bugdb.cgi" >problem report</A>. Be sure to include <EM>complete</EM> details, such as the compiler & OS versions and exact error messages. </P> <HR> </LI> <LI><A NAME="addlog"> <STRONG>How do I add browsers and referrers to my logs?</STRONG> </A> <P> Apache provides a couple of different ways of doing this. The recommended method is to compile the <A HREF="../mod/mod_log_config.html" ><SAMP>mod_log_config</SAMP></A> module into your configuration and use the <A HREF="../mod/mod_log_config.html#customlog" ><SAMP>CustomLog</SAMP></A> directive. </P> <P> 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: </P> <P> <CODE> CustomLog logs/access_log "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-Agent}i\"" </CODE> </P> <P> This will add the values of the <SAMP>User-agent:</SAMP> and <SAMP>Referer:</SAMP> headers, which indicate the client and the referring page, respectively, to the end of each line in the access log. </P> <P> You may want to check out the <CITE>Apache Week</CITE> article entitled: "<A HREF="http://www.apacheweek.com/features/logfiles" REL="Help" ><CITE>Gathering Visitor Information: Customising Your Logfiles</CITE></A>". </P> <HR> </LI> <LI><A NAME="bind8.1"> <STRONG>Why do I get an error about an undefined reference to "<SAMP>__inet_ntoa</SAMP>" or other <SAMP>__inet_*</SAMP> symbols?</STRONG> </A> <P> If you have installed <A HREF="http://www.isc.org/bind.html">BIND-8</A> then this is normally due to a conflict between your include files and your libraries. BIND-8 installs its include files and libraries <CODE>/usr/local/include/</CODE> and <CODE>/usr/local/lib/</CODE>, while the resolver that comes with your system is probably installed in <CODE>/usr/include/</CODE> and <CODE>/usr/lib/</CODE>. If your system uses the header files in <CODE>/usr/local/include/</CODE> before those in <CODE>/usr/include/</CODE> but you do not use the new resolver library, then the two versions will conflict. </P> <P> 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 <CODE>-lbind</CODE> to the <CODE>EXTRA_LDFLAGS</CODE> line in your <SAMP>Configuration</SAMP> file, then re-running <SAMP>Configure</SAMP>, should resolve the problem. (Apache versions 1.2.* and earlier use <CODE>EXTRA_LFLAGS</CODE> instead.) </P> <P> <STRONG>Note:</STRONG>As of BIND 8.1.1, the bind libraries and files are installed under <SAMP>/usr/local/bind</SAMP> 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: </P> <P> <DL> <DD><CODE>EXTRA_CFLAGS=-I/usr/local/bind/include <BR> EXTRA_LDFLAGS=-L/usr/local/bind/lib <BR> EXTRA_LIBS=-lbind</CODE> </DD> </DL> </P> <HR> </LI> <LI><A NAME="set-servername"> <STRONG>Why does accessing directories only work when I include the trailing "/" (<EM>e.g.</EM>, <SAMP>http://foo.domain.com/~user/</SAMP>) but not when I omit it (<EM>e.g.</EM>, <SAMP>http://foo.domain.com/~user</SAMP>)?</STRONG> </A> <P> 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. </P> <P> Add a <A HREF="../mod/core.html#servername">ServerName</A> directive to the config file to tell it what the domain name of the server is. </P> <HR> </LI> <LI><A NAME="user-authentication"> <STRONG>How do I set up Apache to require a username and password to access certain documents?</STRONG> </A> <P> There are several ways to do this; some of the more popular ones are to use the <A HREF="../mod/mod_auth.html">mod_auth</A>, <A HREF="../mod/mod_auth_db.html">mod_auth_db</A>, or <A HREF="../mod/mod_auth_dbm.html">mod_auth_dbm</A> modules. </P> <P> For an explaination on how to implement these restrictions, see <A HREF="http://www.apacheweek.com/" ><CITE>Apache Week</CITE></A>'s articles on <A HREF="http://www.apacheweek.com/features/userauth" ><CITE>Using User Authentication</CITE></A> or <A HREF="http://www.apacheweek.com/features/dbmauth" ><CITE>DBM User Authentication</CITE></A>. </P> <HR> </LI> <LI><A NAME="remote-auth-only"> <STRONG>How do I set up Apache to allow access to certain documents only if a site is either a local site <EM>or</EM> the user supplies a password and username?</STRONG> </A> <P> Use the <A HREF="../mod/core.html#satisfy">Satisfy</A> directive, in particular the <CODE>Satisfy Any</CODE> directive, to require that only one of the access restrictions be met. For example, adding the following configuration to a <SAMP>.htaccess</SAMP> 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: </P> <P> <DL> <DD><CODE>deny from all <BR> allow from .domain.com <BR> AuthType Basic <BR> AuthUserFile /usr/local/etc/httpd/conf/htpasswd.users <BR> AuthName special directory <BR> require valid-user <BR> satisfy any</CODE> </DD> </DL> </P> <P> See the <A HREF="#user-authentication">user authentication</A> question and the <A HREF="../mod/mod_access.html">mod_access</A> module for details on how the above directives work. </P> <HR> </LI> <LI><A NAME="no-info-directives"> <STRONG>Why doesn't mod_info list any directives?</STRONG> </A> <P> The <A HREF="../mod/mod_info.html" ><SAMP>mod_info</SAMP></A> 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 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 <A HREF="../mod/core.html#user" ><SAMP>User</SAMP></A> directive), then <SAMP>mod_info</SAMP> cannot read them in order to list their values. An entry <EM>will</EM> be made in the error log in this event, however. </P> <HR> </LI> <LI><A NAME="linux-shmget"> <STRONG>When I run it under Linux I get "shmget: function not found", what should I do?</STRONG> </A> <P> 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 <A HREF="http://www.linuxhq.com/HOWTO/Kernel-HOWTO.html" >Kernel HOWTO</A>, or the documentation provided with your distribution, or a <A HREF="http://www.linuxhq.com/HOWTO/META-FAQ.html" >Linux newsgroup/mailing list</A>. As a last-resort workaround, you can comment out the <CODE>#define HAVE_SHMGET</CODE> definition in the <SAMP>LINUX</SAMP> section of <SAMP>src/conf.h</SAMP> and rebuild the server. This will produce a server which is slower and less reliable. </P> <HR> </LI> <LI><A NAME="authauthoritative"> <STRONG>Why does my authentification give me a server error?</STRONG> </A> <P> 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 "authentification failed" messages. </P> <P> 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 <SAMP>http_request</SAMP> handler will give one of the following, confusing, errors: </P> <UL> <LI><SAMP>check access</SAMP> </LI> <LI><SAMP>check user. No user file?</SAMP> </LI> <LI><SAMP>check access. No groups file?</SAMP> </LI> </UL> <P> This does <EM>not</EM> mean that you have to add an '<SAMP>AuthUserFile /dev/null</SAMP>' line as some magazines suggest! </P> <P> The solution is to ensure that at least the last module is authoritative and <STRONG>CONFIGURED</STRONG>. By default, <SAMP>mod_auth</SAMP> is authoritative and will give an OK/Denied, but only if it is configured with the proper <SAMP>AuthUserFile</SAMP>. 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 <SAMP>Configuration</SAMP> file.) </P> <P> A typical situation for this error is when you are using the <SAMP>mod_auth_dbm</SAMP>, <SAMP>mod_auth_msql</SAMP>, <SAMP>mod_auth_mysql</SAMP>, <SAMP>mod_auth_anon</SAMP> or <SAMP>mod_auth_cookie</SAMP> modules on their own. These are by default <STRONG>not</STRONG> authoritative, and this will pass the buck on to the (non-existent) next authentification module when the user ID is not in their respective database. Just add the appropriate '<SAMP><EM>XXX</EM>Authoritative yes</SAMP>' line to the configuration. </P> <P> In general it is a good idea (though not terribly efficient) to have the file-based <SAMP>mod_auth</SAMP> 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. </P> <HR> </LI> <LI><A NAME="auth-on-same-machine"> <STRONG>Do I have to keep the (mSQL) authentification information on the same machine?</STRONG> </A> <P> Some organizations feel very strongly about keeping the authentification information on a different machine than the webserver. With the <SAMP>mod_auth_msql</SAMP>, <SAMP>mod_auth_mysql</SAMP>, and other SQL modules connecting to (R)DBMses this is quite possible. Just configure an explicit host to contact. </P> <P> 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 <SAMP>auth_*</SAMP> modules and play with the compile time flags to alleviate this somewhat, if your RDBMS licences allow for it. </P> <HR> </LI> <LI><A NAME="msql-slow"> <STRONG>Why is my mSQL authentification terribly slow?</STRONG> </A> <P> You have probably configured the Host by specificing 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 <SAMP>libmsql</SAMP>, the mSQL FAQ, and the <SAMP>mod_auth_msql</SAMP> documentation warn you about this. If you have to use different hosts, check out the <SAMP>mod_auth_msql</SAMP> code for some compile time flags which might - or might not - suit you. </P> <HR> </LI> <!-- Don't forget to add HR tags at the end of each list item.. --> </OL> <!--#include virtual="footer.html" --> </BODY> </HTML>