FAQ.html revision db81e057b060e365d840d9a1d35a5797192efa81
0N/A<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
0N/A<HTML>
0N/A <HEAD>
0N/A <TITLE>Apache Server Frequently Asked Questions</TITLE>
0N/A </HEAD>
0N/A
0N/A <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
0N/A <BODY
6983N/A BGCOLOR="#FFFFFF"
6983N/A TEXT="#000000"
0N/A LINK="#0000FF"
0N/A VLINK="#000080"
0N/A ALINK="#FF0000"
0N/A >
6983N/A <!--#include virtual="header.html" -->
6983N/A <H1 ALIGN="CENTER">Apache Server Frequently Asked Questions</H1>
6983N/A <P>
6983N/A $Revision: 1.82 $ ($Date: 1997/07/06 17:19:04 $)
0N/A </P>
0N/A <P>
0N/A The latest version of this FAQ is always available from the main
0N/A Apache web site, at
0N/A &lt;<A
4426N/A HREF="http://www.apache.org/docs/misc/FAQ"
7293N/A REL="Help"
0N/A ><SAMP>http://www.apache.org/docs/misc/FAQ</SAMP></A>&gt;.
0N/A </P>
0N/A<!-- Notes about changes: -->
0N/A<!-- - If adding a relative link to another part of the -->
6383N/A<!-- documentation, *do* include the ".html" portion. There's a -->
0N/A<!-- good chance that the user will be reading the documentation -->
0N/A<!-- on his own system, which may not be configured for -->
0N/A<!-- multiviews. Leave off the ".html" extension for absolute -->
2390N/A<!-- links to sites which are known to run multiviews (e.g., -->
0N/A<!-- apache.org or apacheweek.com). -->
0N/A<!-- - When adding items, make sure they're put in the right place -->
1689N/A<!-- - verify that the numbering matches up. -->
3861N/A<!-- - *Don't* use <PRE></PRE> blocks - they don't appear -->
1689N/A<!-- correctly in a reliable way when this is converted to text -->
4134N/A<!-- with Lynx. Use <DL><DD><CODE>xxx<BR>xx</CODE></DD></DL> -->
2390N/A<!-- blocks inside a <P></P> instead. This is necessary to get -->
2390N/A<!-- the horizontal and vertical indenting right. -->
2390N/A<!-- - Don't forget to include an HR tag after the last /P tag -->
2390N/A<!-- but before the /LI in an item. -->
2390N/A <P>
2390N/A If you are reading a text-only version of this FAQ, you may find numbers
2390N/A enclosed in brackets (such as &quot;[12]&quot;). These refer to the list of
6153N/A reference URLs to be found at the end of the document. These references
2390N/A do not appear, and are not needed, for the hypertext version.
2390N/A </P>
2390N/A <H2>The Questions</H2>
0N/A<!-- Stuff to Add: -->
0N/A<!-- - can't bind to port 80 -->
0N/A<!-- - permission denied -->
0N/A<!-- - address already in use -->
0N/A<!-- - mod_auth & passwd lines "user:pw:.*" - ++1st colon onward is -->
2095N/A<!-- treated as pw, not just ++1st to --2nd. -->
2095N/A<!-- - SSL: -->
2095N/A<!-- - Can I use Apache-SSL for free in Canada? -->
2095N/A<!-- - Why can't I use Apache-SSL in the U.S.? -->
2095N/A<!-- - How can I found out how many visitors my site gets? -->
2095N/A<!-- - How do I add a counter? -->
0N/A<!-- - How do I configure Apache as a proxy? -->
0N/A<!-- - What browsers support HTTP/1.1? -->
1079N/A<!-- - What's the point of vhosts-by-name is there aren't any -->
1400N/A<!-- HTTP/1.1 browsers? -->
1400N/A<!-- - Is there an Apache for W95/WNT? -->
1400N/A<!-- - Why does Apache die when a vhost can't be DNS-resolved? -->
1400N/A<!-- - Why do I get "send lost connection" messages in my error -->
1400N/A<!-- log? -->
6027N/A<!-- - specifically consider .pdf files which seem to cause this -->
1079N/A<!-- a lot when accessed via the plugin ... and also mention -->
1079N/A<!-- how range-requests can cause bytes served < file size -->
1079N/A<!-- - Why do directory indexes appear as garbage? (A: -lucb) -->
1079N/A<!-- - How do I add a footer to all pages offered by my server? -->
1079N/A<!-- - Fix midi question; a bigger problem than midi vs. x-midi is -->
1079N/A<!-- the simple fact that older versions of Apache (and new ones -->
1079N/A<!-- that have been upgraded without upgrading the mime.types -->
6153N/A<!-- file) don't have the type listed at all. -->
0N/A<UL>
0N/A <LI><STRONG>Background</STRONG>
6153N/A <OL START=1>
0N/A <LI><A HREF="#what">What is Apache?</A>
0N/A </LI>
6153N/A <LI><A HREF="#why">Why was Apache created?</A>
0N/A </LI>
0N/A <LI><A HREF="#relate">How does The Apache Group's work relate to
6153N/A other servers?</A>
0N/A </LI>
0N/A <LI><A HREF="#name">Why the name &quot;Apache&quot;?</A>
6153N/A </LI>
6027N/A <LI><A HREF="#compare">OK, so how does Apache compare to other servers?</A>
0N/A </LI>
0N/A <LI><A HREF="#tested">How thoroughly tested is Apache?</A>
0N/A </LI>
0N/A <LI><A HREF="#future">What are the future plans for Apache?</A>
0N/A </LI>
0N/A <LI><A HREF="#support">Whom do I contact for support?</A>
0N/A </LI>
0N/A <LI><A HREF="#more">Is there any more information on Apache?</A>
0N/A </LI>
0N/A <LI><A HREF="#where">Where can I get Apache?</A>
0N/A </LI>
0N/A </OL>
0N/A </LI>
0N/A <LI><STRONG>Technical Questions</STRONG>
0N/A <OL START=11>
0N/A <LI><A HREF="#what2do">&quot;Why can't I ...? Why won't ...
0N/A work?&quot; What to do in case of problems</A>
765N/A </LI>
0N/A <LI><A HREF="#compatible">How compatible is Apache with my existing
0N/A NCSA 1.3 setup?</A>
0N/A </LI>
0N/A <LI><A HREF="#CGIoutsideScriptAlias">How do I enable CGI execution
3861N/A in directories other than the ScriptAlias?</A>
3861N/A </LI>
0N/A <LI><A HREF="#premature-script-headers">What does it mean when my
0N/A CGIs fail with &quot;<SAMP>Premature end of script
773N/A headers</SAMP>&quot;?</A>
773N/A </LI>
773N/A <LI><A HREF="#ssi-part-i">How do I enable SSI (parsed HTML)?</A>
0N/A </LI>
0N/A <LI><A HREF="#ssi-part-ii">Why don't my parsed files get cached?</A>
773N/A </LI>
773N/A <LI><A HREF="#ssi-part-iii">How can I have my script output parsed?</A>
773N/A </LI>
773N/A <LI><A HREF="#proxy">Does or will Apache act as a Proxy server?</A>
773N/A </LI>
773N/A <LI><A HREF="#multiviews">What are &quot;multiviews&quot;?</A>
773N/A </LI>
773N/A <LI><A HREF="#fdlim">Why can't I run more than &lt;<EM>n</EM>&gt;
773N/A virtual hosts?</A>
773N/A </LI>
773N/A <LI><A HREF="#freebsd-setsize">Can I increase FD_SETSIZE on FreeBSD?</A>
773N/A </LI>
773N/A <LI><A HREF="#limitGET">Why do I keep getting &quot;access denied&quot; for
773N/A form POST requests?</A>
773N/A </LI>
773N/A <LI><A HREF="#passwdauth">Can I use my <SAMP>/etc/passwd</SAMP> file
773N/A for Web page authentication?</A>
773N/A </LI>
773N/A <LI><A HREF="#errordoc401">Why doesn't my <CODE>ErrorDocument
773N/A 401</CODE> work?</A>
773N/A </LI>
773N/A <LI><A HREF="#setgid">Why do I get &quot;<SAMP>setgid: Invalid
773N/A argument</SAMP>&quot; at startup?</A>
773N/A </LI>
3853N/A <LI><A HREF="#cookies1">Why does Apache send a cookie on every response?</A>
3853N/A </LI>
773N/A <LI><A HREF="#cookies2">Why don't my cookies work, I even compiled in
773N/A <SAMP>mod_cookies</SAMP>?</A>
773N/A </LI>
3853N/A <LI><A HREF="#jdk1-and-http1.1">Why do my Java app[let]s give me plain text
773N/A when I request an URL from an Apache server?</A>
773N/A </LI>
773N/A <LI><A HREF="#putsupport">Why can't I publish to my Apache server
3853N/A using PUT on Netscape Gold and other programs?</A>
3853N/A </LI>
3853N/A <LI><A HREF="#fastcgi">Why isn't FastCGI included with Apache any
773N/A more?</A>
773N/A </LI>
773N/A <LI><A HREF="#nodelay">Why am I getting &quot;<SAMP>httpd: could not
773N/A set socket option TCP_NODELAY</SAMP>&quot; in my error log?</A>
773N/A </LI>
773N/A <LI><A HREF="#peerreset">Why am I getting &quot;<SAMP>connection
1712N/A reset by peer</SAMP>&quot; in my error log?</A>
1712N/A </LI>
1712N/A <LI><A HREF="#nph-scripts">How can I get my script's output without
1712N/A Apache buffering it?</A>
3853N/A </LI>
1712N/A <LI><A HREF="#linuxiovec">Why do I get complaints about redefinition
1712N/A of &quot;<CODE>struct iovec</CODE>&quot; when compiling under Linux?</A>
4134N/A </LI>
1712N/A <LI><A HREF="#wheres-the-dump">The errorlog says Apache dumped core,
1712N/A but where's the dump file?</A>
3853N/A </LI>
1712N/A <LI><A HREF="#dnsauth">Why isn't restricting access by host or domain name
1712N/A working correctly?</A>
1712N/A </LI>
773N/A <LI><A HREF="#SSL-i">Why doesn't Apache include SSL?</A>
773N/A </LI>
773N/A <LI><A HREF="#HPUX-core">Why do I get core dumps under HPUX using
773N/A HP's ANSI C compiler?</A>
773N/A </LI>
0N/A <LI><A HREF="#midi">How do I get Apache to send a MIDI file so the
195N/A browser can play it?</A>
773N/A </LI>
776N/A <LI><A HREF="#cantbuild">Why won't Apache compile with my
1057N/A system's <SAMP>cc</SAMP>?</A>
1057N/A </LI>
2095N/A <LI><A HREF="#addlog">How do I add browsers and referrers to my
1057N/A logs?</A>
0N/A </LI>
0N/A <LI><A HREF="#bind8.1">Why do I get an error about an undefined
0N/A reference to &quot;<SAMP>__inet_ntoa</SAMP>&quot; or other
868N/A <SAMP>__inet_*</SAMP> symbols?</A>
868N/A </LI>
1400N/A <LI><A HREF="#set-servername">Why does accessing directories only work
868N/A when I include the trailing "/"
0N/A (<EM>e.g.</EM>,&nbsp;<SAMP>http://foo.domain.com/~user/</SAMP>) but
2086N/A not when I omit it
2086N/A (<EM>e.g.</EM>,&nbsp;<SAMP>http://foo.domain.com/~user</SAMP>)?</A>
0N/A </LI>
0N/A <LI><A HREF="#user-authentication">How do I set up Apache to require
0N/A a username and password to access certain documents?</A>
0N/A </LI>
0N/A <LI><A HREF="#remote-auth-only">How do I set up Apache to allow access
0N/A to certain documents only if a site is either a local site
0N/A <EM>or</EM> the user supplies a password and username?</A>
0N/A </LI>
0N/A <LI><A HREF="#no-info-directives">Why doesn't mod_info list any
0N/A directives?</A>
0N/A <LI><A HREF="#linux-shmget">When I run it under Linux I get "shmget:
0N/A function not found", what should I do?</A>
0N/A </LI>
0N/A <LI><A HREF="#authauthoritative">Why does my authentification give
0N/A me a server error?</A>
0N/A <LI><A HREF="#auth-on-same-machine">Do I have to keep the (mSQL)
0N/A authentification information on the same machine?</A>
0N/A </LI>
3861N/A <LI><A HREF="#msql-slow">Why is my mSQL authentification terribly slow?</A>
3861N/A </LI>
5553N/A </OL>
5553N/A </LI>
5553N/A</UL>
5553N/A
5553N/A<HR>
5553N/A
5553N/A <H2>The Answers</H2>
5553N/A <H3>
5553N/A Background
5553N/A </H3>
5553N/A<OL START=1>
5553N/A <LI><A NAME="what">
5553N/A <STRONG>What is Apache?</STRONG>
5553N/A </A>
5553N/A <P>
1057N/A Apache was originally based on code and ideas found in the most
1057N/A popular HTTP server of the time.. NCSA httpd 1.3 (early 1995). It has
2095N/A since evolved into a far superior system which can rival (and probably
1057N/A surpass) almost any other UNIX based HTTP server in terms of functionality,
0N/A efficiency and speed.
0N/A </P>
0N/A <P>
0N/A Since it began, it has been completely rewritten, and includes many new
0N/A features. Apache is, as of January 1997, the most popular WWW server on
0N/A the Internet, according to the
0N/A <A
2105N/A HREF="http://www.netcraft.com/Survey/"
2105N/A >Netcraft Survey</A>.
2105N/A </P>
2105N/A <HR>
2105N/A </LI>
2105N/A <LI><A NAME="why">
2105N/A <STRONG>Why was Apache created?</STRONG>
2105N/A </A>
2105N/A <P>
2105N/A To address the concerns of a group of WWW providers and part-time httpd
2105N/A programmers that httpd didn't behave as they wanted it to behave.
2105N/A Apache is an entirely volunteer effort, completely funded by its
2105N/A members, not by commercial sales.
2105N/A </P>
2105N/A <HR>
2105N/A </LI>
2105N/A <LI><A NAME="relate">
2105N/A <STRONG>How does The Apache Group's work relate to other
2105N/A server efforts, such as NCSA's?</STRONG>
2105N/A </A>
2105N/A <P>
2105N/A We, of course, owe a great debt to NCSA and their programmers for
2105N/A making the server Apache was based on. We now, however, have our own
2105N/A server, and our project is mostly our own. The Apache Project is an
2105N/A entirely independent venture.
2105N/A </P>
2105N/A <HR>
2105N/A </LI>
2105N/A <LI><A NAME="name">
2105N/A <STRONG>Why the name &quot;Apache&quot;?</STRONG>
2105N/A </A>
2105N/A <P>
2105N/A A cute name which stuck. Apache is &quot;<STRONG>A
2105N/A PA</STRONG>t<STRONG>CH</STRONG>y server&quot;. It was
2105N/A based on some existing code and a series of &quot;patch files&quot;.
2105N/A </P>
2105N/A <HR>
2105N/A </LI>
2105N/A <LI><A NAME="compare">
2105N/A <STRONG>OK, so how does Apache compare to other servers?</STRONG>
2105N/A </A>
2105N/A <P>
2105N/A For an independent assessment, see
2105N/A <A
2105N/A HREF="http://webcompare.iworld.com/compare/chart.html"
2105N/A >Web Compare</A>'s
2105N/A comparison chart.
2105N/A </P>
2105N/A <P>
2105N/A Apache has been shown to be substantially faster than many other
2105N/A free servers. Although certain commercial servers have claimed to
2105N/A surpass Apache's speed (it has not been demonstrated that any of these
2105N/A &quot;benchmarks&quot; are a good way of measuring WWW server speed at any
2105N/A rate), we feel that it is better to have a mostly-fast free server
2105N/A than an extremely-fast server that costs thousands of dollars. Apache
2105N/A is run on sites that get millions of hits per day, and they have
2105N/A experienced no performance difficulties.
2105N/A </P>
2105N/A <HR>
2105N/A </LI>
2105N/A <LI><A NAME="tested">
0N/A <STRONG>How thoroughly tested is Apache?</STRONG>
0N/A </A>
0N/A <P>
0N/A Apache is run on over 400,000 Internet servers (as of April 1997). It has
0N/A been tested thoroughly by both developers and users. The Apache Group
0N/A maintains rigorous standards before releasing new versions of their
0N/A server, and our server runs without a hitch on over one third of all
0N/A WWW servers available on the Internet. When bugs do show up, we
2342N/A release patches and new versions as soon as they are available.
2342N/A </P>
2342N/A <P>
2342N/A The Apache project's web site includes a page with a partial list of
2342N/A <A
0N/A HREF="http://www.apache.org/info/apache_users"
0N/A >sites running Apache</A>.
0N/A </P>
0N/A <HR>
0N/A </LI>
0N/A <LI><A NAME="future">
0N/A <STRONG>What are the future plans for Apache?</STRONG>
0N/A </A>
0N/A <P>
0N/A <UL>
0N/A <LI>to continue as a public domain HTTP server,
0N/A </LI>
0N/A <LI>to keep up with advances in HTTP protocol and web developments in
0N/A general,
0N/A </LI>
0N/A <LI>to collect suggestions for fixes/improvements from its users,
0N/A </LI>
0N/A <LI>to respond to needs of large volume providers as well as
0N/A occasional users.
0N/A </LI>
0N/A </UL>
0N/A </P>
0N/A <HR>
0N/A </LI>
0N/A <LI><A NAME="support">
0N/A <STRONG>Whom do I contact for support?</STRONG>
0N/A </A>
0N/A <P>
0N/A There is no official support for Apache. None of the developers want to
0N/A be swamped by a flood of trivial questions that can be resolved elsewhere.
0N/A Bug reports and suggestions should be sent <EM>via</EM>
0N/A <A
0N/A HREF="http://www.apache.org/bug_report"
0N/A >the bug report page</A>.
0N/A Other questions should be directed to the
0N/A <A
0N/A HREF="news:comp.infosystems.www.servers.unix"
0N/A ><SAMP>comp.infosystems.www.servers.unix</SAMP></A>
0N/A newsgroup, where some of the Apache team lurk,
0N/A in the company of many other httpd gurus who should be able
0N/A to help.
0N/A </P>
0N/A <P>
0N/A Commercial support for Apache is, however, available from a number
0N/A of third parties.
0N/A </P>
0N/A <HR>
0N/A </LI>
0N/A <LI><A NAME="more">
0N/A <STRONG>Is there any more information available on
0N/A Apache?</STRONG>
0N/A </A>
0N/A <P>
0N/A Indeed there is. See the main
0N/A <A
0N/A HREF="http://www.apache.org/"
0N/A >Apache web site</A>.
0N/A There is also a regular electronic publication called
0N/A <A
0N/A HREF="http://www.apacheweek.com/"
0N/A REL="Help"
0N/A ><CITE>Apache Week</CITE></A>
0N/A available. Links to relevant <CITE>Apache Week</CITE> articles are
0N/A included below where appropriate.
0N/A </P>
0N/A <HR>
0N/A </LI>
0N/A <LI><A NAME="where">
0N/A <STRONG>Where can I get Apache?</STRONG>
0N/A </A>
0N/A <P>
0N/A You can find out how to download the source for Apache at the
0N/A project's
0N/A <A
2095N/A HREF="http://www.apache.org/"
0N/A >main web page</A>.
0N/A </P>
0N/A <HR>
0N/A </LI>
0N/A</OL>
0N/A <H3>
0N/A Technical Questions
0N/A </H3>
0N/A<OL START=11>
0N/A <LI><A NAME="what2do">
0N/A <STRONG>&quot;Why can't I ...? Why won't ... work?&quot; What to
0N/A do in case of problems</STRONG>
0N/A </A>
0N/A <P>
2095N/A If you are having trouble with your Apache server software, you should
2095N/A take the following steps:
2095N/A </P>
2095N/A <OL>
2095N/A <LI><STRONG>Check the errorlog!</STRONG>
2095N/A <P>
3853N/A Apache tries to be helpful when it encounters a problem. In many
0N/A cases, it will provide some details by writing one or messages to
0N/A the server error log. Sometimes this is enough for you to diagnose
0N/A &amp; fix the problem yourself (such as file permissions or the like).
0N/A The default location of the error log is
0N/A <SAMP>/usr/local/etc/httpd/logs/error_log</SAMP>, but see the
0N/A <A
0N/A HREF="/mod/core.html#errorlog"
0N/A ><SAMP>ErrorLog</SAMP></A>
0N/A directive in your config files for the location on your server.
0N/A </P>
0N/A </LI>
0N/A <LI><STRONG>Check the
0N/A <A
2095N/A HREF="http://www.apache.org/docs/misc/FAQ.html"
0N/A >FAQ</A>!</STRONG>
0N/A <P>
0N/A The latest version of the Apache Frequently-Asked Questions list can
0N/A always be found at the main Apache web site.
0N/A </P>
0N/A </LI>
0N/A <LI><STRONG>Check the Apache bug database</STRONG>
0N/A <P>
0N/A Most problems that get reported to The Apache Group are recorded in
0N/A the
0N/A <A
0N/A HREF="http://www.apache.org/bugdb.cgi"
2095N/A >bug database</A>.
0N/A <EM><STRONG>Please</STRONG> check the existing reports, open
0N/A <STRONG>and</STRONG> closed, before adding one.</EM> If you find
0N/A that your issue has already been reported, please <EM>don't</EM> add
0N/A a &quot;me, too&quot; report. If the original report isn't closed
0N/A yet, we suggest that you check it periodically. You might also
0N/A consider contacting the original submitter, because there may be an
0N/A email exchange going on about the issue that isn't getting recorded
0N/A in the database.
3853N/A </P>
3853N/A </LI>
3853N/A <LI><STRONG>Ask in the <SAMP>comp.infosystems.www.servers.unix</SAMP>
3853N/A USENET newsgroup</STRONG>
3853N/A <P>
4495N/A A lot of common problems never make it to the bug database because
3853N/A there's already high Q&amp;A traffic about them in the
3853N/A <A
3853N/A HREF="news:comp.infosystems.www.servers.unix"
3853N/A ><SAMP>comp.infosystems.www.servers.unix</SAMP></A>
3853N/A newsgroup. Many Apache users, and some of the developers, can be
3853N/A found roaming its virtual halls, so it is suggested that you seek
3853N/A wisdom there. The chances are good that you'll get a faster answer
3853N/A there than from the bug database, even if you <EM>don't</EM> see
0N/A your question already posted.
0N/A </P>
0N/A </LI>
0N/A <LI><STRONG>If all else fails, report the problem in the bug
0N/A database</STRONG>
0N/A <P>
2095N/A If you've gone through those steps above that are appropriate and
0N/A have obtained no relief, then please <EM>do</EM> let The Apache
0N/A Group know about the problem by
0N/A <A
0N/A HREF="http://www.apache.org/bugdb.cgi"
0N/A >logging a bug report</A>.
0N/A </P>
0N/A <P>
0N/A If your problem involves the server crashing and generating a core
3853N/A dump, please include a backtrace (if possible). As an example,
3853N/A </P>
3853N/A <P>
3853N/A <DL>
3853N/A <DD><CODE># cd <EM>ServerRoot</EM><BR>
3853N/A # dbx httpd core<BR>
3853N/A (dbx) where</CODE>
4495N/A </DD>
3853N/A </DL>
3853N/A </P>
3853N/A <P>
3853N/A (Substitute the appropriate locations for your
3853N/A <SAMP>ServerRoot</SAMP> and your <SAMP>httpd</SAMP> and
3853N/A <SAMP>core</SAMP> files. You may have to use <CODE>gdb</CODE>
3853N/A instead of <CODE>dbx</CODE>.)
3853N/A </P>
0N/A </LI>
0N/A </OL>
0N/A <HR>
0N/A </LI>
0N/A <LI><A NAME="compatible">
0N/A <STRONG>How compatible is Apache with my existing NCSA 1.3
0N/A setup?</STRONG>
0N/A </A>
2095N/A <P>
0N/A Apache attempts to offer all the features and configuration options
0N/A of NCSA httpd 1.3, as well as many of the additional features found in
0N/A NCSA httpd 1.4 and NCSA httpd 1.5.
0N/A </P>
0N/A <P>
0N/A NCSA httpd appears to be moving toward adding experimental features
0N/A which are not generally required at the moment. Some of the experiments
0N/A will succeed while others will inevitably be dropped. The Apache
0N/A philosophy is to add what's needed as and when it is needed.
0N/A </P>
0N/A <P>
0N/A Friendly interaction between Apache and NCSA developers should ensure
0N/A that fundamental feature enhancements stay consistent between the two
0N/A servers for the foreseeable future.
0N/A </P>
0N/A <HR>
2095N/A </LI>
0N/A <LI><A NAME="CGIoutsideScriptAlias">
0N/A <STRONG>How do I enable CGI execution in directories other than
0N/A the ScriptAlias?</STRONG>
0N/A </A>
0N/A <P>
0N/A Apache recognizes all files in a directory named as a
0N/A <A
0N/A HREF="/mod/mod_alias.html#scriptalias"
2095N/A ><SAMP>ScriptAlias</SAMP></A>
2095N/A as being eligible for execution rather than processing as normal
2095N/A documents. This applies regardless of the file name, so scripts in a
2095N/A ScriptAlias directory don't need to be named
2095N/A &quot;<SAMP>*.cgi</SAMP>&quot; or &quot;<SAMP>*.pl</SAMP>&quot; or
2095N/A whatever. In other words, <EM>all</EM> files in a ScriptAlias
2095N/A directory are scripts, as far as Apache is concerned.
2095N/A </P>
1057N/A <P>
1057N/A To persuade Apache to execute scripts in other locations, such as in
1057N/A directories where normal documents may also live, you must tell it how
1057N/A to recognize them - and also that it's okay to execute them. For
1057N/A this, you need to use something like the
1057N/A <A
1057N/A HREF="/mod/mod_mime.html#addhandler"
1057N/A ><SAMP>AddHandler</SAMP></A>
1057N/A directive.
1057N/A </P>
1057N/A <OL>
2095N/A <LI>In an appropriate section of your server configuration files, add
2095N/A a line such as
2095N/A <P>
2095N/A <DL>
2095N/A <DD><CODE>AddHandler cgi-script .cgi</CODE>
2095N/A </DD>
2095N/A </DL>
2095N/A </P>
1057N/A <P>
1057N/A The server will then recognize that all files in that location (and
1057N/A its logical descendants) that end in &quot;<SAMP>.cgi</SAMP>&quot;
1057N/A are script files, not documents.
1057N/A </P>
1057N/A </LI>
1057N/A <LI>Make sure that the directory location is covered by an
1057N/A <A
1057N/A HREF="/mod/core.html#options"
1057N/A ><SAMP>Options</SAMP></A>
1057N/A declaration that includes the <SAMP>ExecCGI</SAMP> option.
2095N/A <P>
2095N/A </P>
2095N/A </LI>
2095N/A </OL>
2095N/A <HR>
2095N/A </LI>
2095N/A <LI><A NAME="premature-script-headers">
2095N/A <STRONG>What does it mean when my CGIs fail with
2095N/A &quot;<SAMP>Premature end of script headers</SAMP>&quot;?</STRONG>
2095N/A </A>
2095N/A <P>
2095N/A It means just what it says: the server was expecting a complete set of
2095N/A HTTP headers (one or more followed by a blank line), and didn't get
2095N/A them.
6027N/A </P>
2095N/A <P>
2095N/A The most common cause of this problem is the script dying before
2095N/A sending the complete set of headers, or possibly any at all, to the
2095N/A server. To see if this is the case, try running the script standalone
2095N/A from an interactive session, rather than as a script under the server.
2095N/A If you get error messages, this is almost certainly the cause of the
2095N/A &quot;premature end of script headers&quot; message.
2095N/A </P>
6027N/A <P>
2095N/A The second most common cause of this (aside from people not
2095N/A outputting the required headers at all) is a result of an interaction
2095N/A with Perl's output buffering. To make Perl flush its buffers
2095N/A after each output statement, insert the following statements around
2095N/A the <CODE>print</CODE> or <CODE>write</CODE> statements that send your
1057N/A HTTP headers:
1057N/A </P>
1057N/A <P>
1057N/A <DL>
1057N/A <DD><CODE>{<BR>
1057N/A &nbsp;local ($oldbar) = $|;<BR>
1057N/A &nbsp;$cfh = select (STDOUT);<BR>
1057N/A &nbsp;$| = 1;<BR>
6198N/A &nbsp;#<BR>
6198N/A &nbsp;# print your HTTP headers here<BR>
6198N/A &nbsp;#<BR>
6198N/A &nbsp;$| = $oldbar;<BR>
6198N/A &nbsp;select ($cfh);<BR>
6198N/A }</CODE>
6198N/A </DD>
1057N/A </DL>
1057N/A </P>
0N/A <P>
0N/A This is generally only necessary when you are calling external
0N/A programs from your script that send output to stdout, or if there will
0N/A be a long delay between the time the headers are sent and the actual
0N/A content starts being emitted. To maximise performance, you should
0N/A turn buffer-flushing back <EM>off</EM> (with <CODE>$| = 0</CODE> or the
0N/A equivalent) after the statements that send the headers, as displayed
0N/A above.
0N/A </P>
0N/A <P>
0N/A If your script isn't written in Perl, do the equivalent thing for
2095N/A whatever language you <EM>are</EM> using (<EM>e.g.</EM>, for C, call
0N/A <CODE>fflush()</CODE> after writing the headers).
0N/A </P>
4134N/A <HR>
0N/A </LI>
0N/A <LI><A NAME="ssi-part-i">
0N/A <STRONG>How do I enable SSI (parsed HTML)?</STRONG>
0N/A </A>
0N/A <P>
0N/A SSI (an acronym for Server-Side Include) directives allow static HTML
0N/A documents to be enhanced at run-time (<EM>e.g.</EM>, when delivered to
0N/A a client by Apache). The format of SSI directives is covered
0N/A in the <A HREF="/mod/mod_include.html">mod_include manual</A>;
0N/A suffice it to say that Apache supports not only SSI but
2095N/A xSSI (eXtended SSI) directives.
2095N/A </P>
2095N/A <P>
2095N/A Processing a document at run-time is called <EM>parsing</EM> it; hence
2095N/A the term &quot;parsed HTML&quot; sometimes used for documents that
2095N/A contain SSI instructions. Parsing tends to be <EM>extremely</EM>
0N/A resource-consumptive, and is not enabled by default. It can also
0N/A interfere with the cachability of your documents, which can put a
0N/A further load on your server. (see the
0N/A <A
0N/A HREF="#ssi-part-ii"
0N/A >next question</A>
0N/A for more information about this.)
0N/A </P>
0N/A <P>
195N/A To enable SSI processing, you need to
195N/A </P>
195N/A <UL>
195N/A <LI>Build your server with the
195N/A <A
195N/A HREF="/mod/mod_include.html"
195N/A ><SAMP>mod_include</SAMP></A>
195N/A module. This is normally compiled in by default.
195N/A </LI>
2095N/A <LI>Make sure your server configuration files have an
2095N/A <A
2095N/A HREF="/mod/core.html#options"
2095N/A ><SAMP>Options</SAMP></A>
2095N/A directive which permits <SAMP>Includes</SAMP>.
2095N/A </LI>
195N/A <LI>Make sure that the directory where you want the SSI documents to
195N/A live is covered by the &quot;server-parsed&quot; content handler,
195N/A either explicitly or in some ancestral location. That can be done
195N/A with the following
195N/A <A
195N/A HREF="/mod/mod_mime.html#addhandler"
195N/A ><SAMP>AddHandler</SAMP></A>
195N/A directive:
195N/A <P>
195N/A <DL>
195N/A <DD><CODE>AddHandler server-parsed .shtml</CODE>
195N/A </DD>
195N/A </DL>
2095N/A </P>
2095N/A This indicates that all files ending in &quot;.shtml&quot; in that
2095N/A location (or its descendants) should be parsed. Note that using
2095N/A &quot;.html&quot; will cause all normal HTML files to be parsed,
2095N/A which may put an inordinate load on your server.
2095N/A </LI>
195N/A </UL>
195N/A <P>
195N/A For additional information, see the <CITE>Apache Week</CITE> article
195N/A on
195N/A <A
195N/A HREF="http://www.apacheweek.com/features/ssi"
195N/A REL="Help"
195N/A ><CITE>Using Server Side Includes</CITE></A>.
0N/A </P>
0N/A <HR>
0N/A </LI>
0N/A <LI><A NAME="ssi-part-ii">
0N/A <STRONG>Why don't my parsed files get cached?</STRONG>
0N/A </A>
0N/A <P>
0N/A Since the server is performing run-time processing of your SSI
0N/A directives, which may change the content shipped to the client, it
0N/A can't know at the time it starts parsing what the final size of the
1177N/A result will be, or whether the parsed result will always be the same.
1177N/A This means that it can't generate <SAMP>Content-Length</SAMP> or
1177N/A <SAMP>Last-Modified</SAMP> headers. Caches commonly work by comparing
4134N/A the <SAMP>Last-Modified</SAMP> of what's in the cache with that being
2845N/A delivered by the server. Since the server isn't sending that header
1177N/A for a parsed document, whatever's doing the caching can't tell whether
1177N/A the document has changed or not - and so fetches it again to be on the
1177N/A safe side.
1177N/A </P>
1177N/A <P>
1177N/A You can work around this in some cases by causing an
1177N/A <SAMP>Expires</SAMP> header to be generated. (See the
1177N/A <A
1177N/A HREF="/mod/mod_expires.html"
1177N/A REL="Help"
1177N/A ><SAMP>mod_expires</SAMP></A>
1177N/A documentation for more details.) Another possibility is to use the
1177N/A <A
1177N/A HREF="/mod/mod_include.html#xbithack"
1177N/A REL="Help"
0N/A ><SAMP>XBitHack Full</SAMP></A>
1177N/A mechanism, which tells Apache to send (under certain circumstances
0N/A detailed in the XBitHack directive description) a
2845N/A <SAMP>Last-Modified</SAMP> header based upon the last modification
2845N/A time of the file being parsed. Note that this may actually be lying
2845N/A to the client if the parsed file doesn't change but the SSI-inserted
2845N/A content does; if the included content changes often, this can result
2845N/A in stale copies being cached.
2845N/A </P>
2845N/A <HR>
2845N/A </LI>
2845N/A <LI><A NAME="ssi-part-iii">
2845N/A <STRONG>How can I have my script output parsed?</STRONG>
2845N/A </A>
2845N/A <P>
2845N/A So you want to include SSI directives in the output from your CGI
2845N/A script, but can't figure out how to do it?
2845N/A The short answer is &quot;you can't.&quot; This is potentially
2845N/A a security liability and, more importantly, it can not be cleanly
2845N/A implemented under the current server API. The best workaround
2845N/A is for your script itself to do what the SSIs would be doing.
2845N/A After all, it's generating the rest of the content.
2845N/A </P>
2845N/A <P>
2845N/A This is a feature The Apache Group hopes to add in the next major
1689N/A release after 1.2.
1689N/A </P>
2845N/A <HR>
1177N/A </LI>
0N/A <LI><A NAME="proxy">
0N/A <STRONG>Does or will Apache act as a Proxy server?</STRONG>
0N/A </A>
0N/A <P>
0N/A Apache version 1.1 and above comes with a
0N/A <A
0N/A HREF="/mod/mod_proxy.html"
0N/A >proxy module</A>.
0N/A If compiled
0N/A in, this will make Apache act as a caching-proxy server.
0N/A </P>
0N/A <HR>
0N/A </LI>
0N/A <LI><A NAME="multiviews">
6027N/A <STRONG>What are &quot;multiviews&quot;?</STRONG>
0N/A </A>
0N/A <P>
0N/A &quot;Multiviews&quot; is the general name given to the Apache
0N/A server's ability to provide language-specific document variants in
0N/A response to a request. This is documented quite thoroughly in the
0N/A <A
0N/A HREF="/content-negotiation.html"
0N/A REL="Help"
0N/A >content negotiation</A>
0N/A description page. In addition, <CITE>Apache Week</CITE> carried an
0N/A article on this subject entitled
0N/A &quot;<A
0N/A HREF="http://www.apacheweek.com/features/negotiation"
0N/A REL="Help"
0N/A ><CITE>Content Negotiation Explained</CITE></A>&quot;.
0N/A </P>
2845N/A <HR>
2845N/A </LI>
2845N/A <LI><A NAME="fdlim">
2845N/A <STRONG>Why can't I run more than &lt;<EM>n</EM>&gt;
2845N/A virtual hosts?</STRONG>
2845N/A </A>
2845N/A <P>
2845N/A You are probably running into resource limitations in your
2845N/A operating system. The most common limitation is the
2845N/A <EM>per</EM>-process limit on <STRONG>file descriptors</STRONG>,
2845N/A which is almost always the cause of problems seen when adding
2845N/A virtual hosts. Apache often does not give an intuitive error
6027N/A message because it is normally some library routine (such as
2845N/A <CODE>gethostbyname()</CODE>) which needs file descriptors and
2845N/A doesn't complain intelligibly when it can't get them.
2845N/A </P>
2845N/A <P>
2845N/A Each log file requires a file descriptor, which means that if you are
2845N/A using separate access and error logs for each virtual host, each
2845N/A virtual host needs two file descriptors. Each
2845N/A <A
2845N/A HREF="/mod/core.html#listen"
2845N/A ><SAMP>Listen</SAMP></A>
2845N/A directive also needs a file descriptor.
2845N/A </P>
2845N/A <P>
2845N/A Typical values for &lt;<EM>n</EM>&gt; that we've seen are in
2845N/A the neighborhood of 128 or 250. When the server bumps into the file
2845N/A descriptor limit, it may dump core with a SIGSEGV, it might just
2845N/A hang, or it may limp along and you'll see (possibly meaningful) errors
2845N/A in the error log. One common problem that occurs when you run into
2845N/A a file descriptor limit is that CGI scripts stop being executed
1689N/A properly.
1689N/A </P>
2845N/A <P>
0N/A As to what you can do about this:
0N/A </P>
0N/A <OL>
0N/A <LI>Reduce the number of
0N/A <A
0N/A HREF="/mod/core.html#listen"
0N/A ><SAMP>Listen</SAMP></A>
0N/A directives. If there are no other servers running on the machine
0N/A on the same port then you normally don't
0N/A need any Listen directives at all. By default Apache listens to
0N/A all addresses on port 80.
1177N/A </LI>
1177N/A <LI>Reduce the number of log files. You can use
1177N/A <A
1177N/A HREF="/mod/mod_log_config.html"
1177N/A ><SAMP>mod_log_config</SAMP></A>
1177N/A to log all requests to a single log file while including the name
1177N/A of the virtual host in the log file. You can then write a
1177N/A script to split the logfile into separate files later if
1177N/A necessary.
1177N/A </LI>
2845N/A <LI>Increase the number of file descriptors available to the server
2845N/A (see your system's documentation on the <CODE>limit</CODE> or
2845N/A <CODE>ulimit</CODE> commands). For some systems, information on
2845N/A how to do this is available in the
2845N/A <A
2845N/A HREF="perf.html"
2845N/A >performance hints</A>
2845N/A page. There is a specific note for
2845N/A <a href="#freebsd-setsize">FreeBSD</a> below.
2845N/A </LI>
2845N/A <LI>&quot;Don't do that&quot; - try to run with fewer virtual hosts
2845N/A </LI>
2845N/A <LI>Spread your operation across multiple server processes (using
2845N/A <A
2845N/A HREF="/mod/core.html#listen"
2845N/A ><SAMP>Listen</SAMP></A>
2845N/A for example, but see the first point) and/or ports.
1177N/A </LI>
1177N/A </OL>
5703N/A <P>
5703N/A Since this is an operating-system limitation, there's not much else
1177N/A available in the way of solutions.
1177N/A <P>
1177N/A As of 1.2.1 we have made attempts to work around various limitations
1177N/A involving running with many descriptors.
1177N/A <a href="descriptors.html">More information is available.</a>
2390N/A </P>
2390N/A <HR>
2390N/A </LI>
2390N/A
2390N/A <LI><A NAME="freebsd-setsize">
2390N/A <STRONG>Can I increase <SAMP>FD_SETSIZE</SAMP> on FreeBSD?</STRONG>
2390N/A </A>
2390N/A <P>
2390N/A On FreeBSD 2.2 and older <SAMP>FD_SETSIZE</SAMP>, which limits the
2390N/A number of open
2390N/A files on the system, is limited to 256. This can restrict the number of
2390N/A virtual hosts you can use; especially if they all use different log
2390N/A files. Increasing this limit (and recompiling Apache) is not enough,
2390N/A as it is on some platforms (such as Solaris), as you also will have
2390N/A to recompile <SAMP>libc</SAMP> with the changed setting.
2390N/A </P>
2390N/A <P>
2390N/A On FreeBSD 3.0 the default is 1024, so the problem is lessened.
2390N/A </P>
2390N/A <HR>
2390N/A </LI>
2390N/A
2390N/A <LI><A NAME="limitGET">
2390N/A <STRONG>Why do I keep getting &quot;access denied&quot; for form POST
2390N/A requests?</STRONG>
2390N/A </A>
3853N/A <P>
2390N/A The most common cause of this is a <SAMP>&lt;Limit&gt;</SAMP> section
4134N/A that only names the <SAMP>GET</SAMP> method. Look in your
2390N/A configuration files for something that resembles the following and
2390N/A would affect the location where the POST-handling script resides:
2390N/A </P>
2390N/A <P>
2390N/A <DL>
2390N/A <DD><CODE>&lt;Limit GET&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;:</CODE>
2390N/A </DD>
2390N/A </DL>
2390N/A </P>
2390N/A <P>
2390N/A Change that to <CODE>&lt;Limit GET POST&gt;</CODE> and the problem
2390N/A will probably go away.
2390N/A </P>
2390N/A <HR>
2390N/A </LI>
2390N/A <LI><A NAME="passwdauth">
2390N/A <STRONG>Can I use my <SAMP>/etc/passwd</SAMP> file
2390N/A for Web page authentication?</STRONG>
2390N/A </A>
1177N/A <P>
1177N/A Yes, you can - but it's a <STRONG>very bad idea</STRONG>. Here are
1177N/A some of the reasons:
1177N/A </P>
1177N/A <UL>
1177N/A <LI>The Web technology provides no governors on how often or how
1177N/A rapidly password (authentication failure) retries can be made. That
1177N/A means that someone can hammer away at your system's
1177N/A <SAMP>root</SAMP> password using the Web, using a dictionary or
1177N/A similar mass attack, just as fast as the wire and your server can
1177N/A handle the requests. Most operating systems these days include
1177N/A attack detection (such as <EM>n</EM> failed passwords for the same
1177N/A account within <EM>m</EM> seconds) and evasion (breaking the
1177N/A connection, disabling the account under attack, disabling
4134N/A <EM>all</EM> logins from that source, <EM>et cetera</EM>), but the
4134N/A Web does not.
2845N/A </LI>
2845N/A <LI>An account under attack isn't notified (unless the server is
2845N/A heavily modified); there's no &quot;You have 19483 login
2845N/A failures&quot; message when the legitimate owner logs in.
2845N/A </LI>
2845N/A <LI>Without an exhaustive and error-prone examination of the server
2845N/A logs, you can't tell whether an account has been compromised.
2845N/A Detecting that an attack has occurred, or is in progress, is fairly
2845N/A obvious, though - <EM>if</EM> you look at the logs.
2845N/A </LI>
2845N/A <LI>Web authentication passwords (at least for Basic authentication)
2845N/A generally fly across the wire, and through intermediate proxy
2845N/A systems, in what amounts to plaintext. &quot;O'er the net we
2845N/A go/Caching all the way;/O what fun it is to surf/Giving my password
2845N/A away!&quot;
2845N/A </LI>
2845N/A <LI>Since HTTP is stateless, information about the authentication is
2845N/A transmitted <EM>each and every time</EM> a request is made to the
2845N/A server. Essentially, the client caches it after the first
2845N/A successful access, and transmits it without asking for all
2845N/A subsequent requests to the same server.
2845N/A </LI>
2845N/A <LI>It's relatively trivial for someone on your system to put up a
4134N/A page that will steal the cached password from a client's cache
4134N/A without them knowing. Can you say &quot;password grabber&quot;?
1177N/A </LI>
1177N/A </UL>
1177N/A <P>
1177N/A If you still want to do this in light of the above disadvantages, the
1177N/A method is left as an exercise for the reader. It'll void your Apache
195N/A warranty, though, and you'll lose all accumulated UNIX guru points.
195N/A </P>
195N/A <HR>
195N/A </LI>
195N/A <LI><A NAME="errordoc401">
195N/A <STRONG>Why doesn't my <CODE>ErrorDocument 401</CODE> work?</STRONG>
195N/A </A>
195N/A <P>
195N/A You need to use it with a URL in the form
195N/A &quot;<SAMP>/foo/bar</SAMP>&quot; and not one with a method and
195N/A hostname such as &quot;<SAMP>http://host/foo/bar</SAMP>&quot;. See the
195N/A <A
195N/A HREF="/mod/core.html#errordocument"
195N/A ><SAMP>ErrorDocument</SAMP></A>
2845N/A documentation for details. This was incorrectly documented in the past.
2845N/A </P>
2845N/A <HR>
2845N/A </LI>
2845N/A <LI><A NAME="setgid">
2845N/A <STRONG>Why do I get &quot;<SAMP>setgid: Invalid
2845N/A argument</SAMP>&quot; at startup?</STRONG>
2845N/A </A>
2845N/A <P>
2845N/A Your
2845N/A <A
2845N/A HREF="/mod/core.html#group"
2845N/A ><SAMP>Group</SAMP></A>
2845N/A directive (probably in <SAMP>conf/httpd.conf</SAMP>) needs to name a
2845N/A group that actually exists in the <SAMP>/etc/group</SAMP> file (or
2845N/A your system's equivalent).
2845N/A </P>
2845N/A <HR>
2845N/A </LI>
2845N/A <LI><A NAME="cookies1">
2845N/A <STRONG>Why does Apache send a cookie on every response?</STRONG>
2845N/A </A>
1689N/A <P>
1689N/A Apache does <EM>not</EM> send automatically send a cookie on every
2845N/A response, unless you have re-compiled it with the
1079N/A <A
195N/A HREF="/mod/mod_cookies.html"
195N/A ><SAMP>mod_cookies</SAMP></A>
195N/A module.
195N/A This module was distributed with Apache prior to 1.2.
195N/A This module may help track users, and uses cookies to do this. If
195N/A you are not using the data generated by <SAMP>mod_cookies</SAMP>, do
195N/A not compile it into Apache. Note that in 1.2 this module was renamed
195N/A to the more correct name
195N/A <A
195N/A HREF="/mod/mod_usertrack.html"
195N/A ><SAMP>mod_usertrack</SAMP></A>,
195N/A and cookies
195N/A have to be specifically enabled with the
195N/A <A
195N/A HREF="/mod/mod_usertrack.html#cookietracking"
195N/A ><SAMP>CookieTracking</SAMP></A>
195N/A directive.
195N/A </P>
195N/A <HR>
195N/A </LI>
195N/A <LI><A NAME="cookies2">
195N/A <STRONG>Why don't my cookies work, I even compiled in
195N/A <SAMP>mod_cookies</SAMP>?
2845N/A </STRONG>
2845N/A </A>
2845N/A <P>
2845N/A Firstly, you do <EM>not</EM> need to compile in
2845N/A <SAMP>mod_cookies</SAMP> in order for your scripts to work (see the
2845N/A <A
2845N/A HREF="#cookies1"
2845N/A >previous question</A>
2845N/A for more about <SAMP>mod_cookies</SAMP>). Apache passes on your
2845N/A <SAMP>Set-Cookie</SAMP> header fine, with or without this module. If
2845N/A cookies do not work it will be because your script does not work
2845N/A properly or your browser does not use cookies or is not set-up to
2845N/A accept them.
2845N/A </P>
2845N/A <HR>
2845N/A </LI>
2845N/A <LI><A NAME="jdk1-and-http1.1">
2845N/A <STRONG>Why do my Java app[let]s give me plain text when I request
2845N/A an URL from an Apache server?</STRONG>
2845N/A </A>
2845N/A <P>
2845N/A As of version 1.2, Apache is an HTTP/1.1 (HyperText Transfer Protocol
1689N/A version 1.1) server. This fact is reflected in the protocol version
1689N/A that's included in the response headers sent to a client when
2845N/A processing a request. Unfortunately, low-level Web access classes
1079N/A included in the Java Development Kit (JDK) version 1.0.2 expect to see
195N/A the version string &quot;HTTP/1.0&quot; and do not correctly interpret
195N/A the &quot;HTTP/1.1&quot; value Apache is sending (this part of the
195N/A response is a declaration of what the server can do rather than a
195N/A declaration of the dialect of the response). The result
195N/A is that the JDK methods do not correctly parse the headers, and
195N/A include them with the document content by mistake.
195N/A </P>
195N/A <P>
195N/A This is definitely a bug in the JDK 1.0.2 foundation classes from Sun,
195N/A and it has been fixed in version 1.1. However, the classes in
195N/A question are part of the virtual machine environment, which means
195N/A they're part of the Web browser (if Java-enabled) or the Java
195N/A environment on the client system - so even if you develop
195N/A <EM>your</EM> classes with a recent JDK, the eventual users might
195N/A encounter the problem.
195N/A The classes involved are replaceable by vendors implementing the
195N/A Java virtual machine environment, and so even those that are based
195N/A upon the 1.0.2 version may not have this problem.
195N/A </P>
195N/A <P>
195N/A In the meantime, a workaround is to tell
195N/A Apache to &quot;fake&quot; an HTTP/1.0 response to requests that come
195N/A from the JDK methods; this can be done by including a line such as the
4134N/A following in your server configuration files:
195N/A </P>
2845N/A <P>
2845N/A <DL>
2845N/A <DD><CODE>BrowserMatch Java1.0 force-response-1.0</CODE>
2845N/A </DD>
2845N/A </DL>
2845N/A </P>
2845N/A <P>
2845N/A More information about this issue can be found in the
2845N/A <A
2845N/A HREF="http://www.apache.org/info/jdk-102"
2845N/A ><CITE>Java and HTTP/1.1</CITE></A>
2845N/A page at the Apache web site.
2845N/A </P>
2845N/A <HR>
2845N/A </LI>
2845N/A <LI><A NAME="putsupport">
2845N/A <STRONG>Why can't I publish to my Apache server using PUT on
2845N/A Netscape Gold and other programs?</STRONG>
2845N/A </A>
2845N/A <P>
2845N/A Because you need to install and configure a script to handle
2845N/A the uploaded files. This script is often called a &quot;PUT&quot; handler.
2845N/A There are several available, but they may have security problems.
4134N/A Using FTP uploads may be easier and more secure, at least for now.
2845N/A For more information, see the <CITE>Apache Week</CITE> article
2845N/A <A
1689N/A HREF="http://www.apacheweek.com/features/put"
1689N/A ><CITE>Publishing Pages with PUT</CITE></A>.
2845N/A </P>
1079N/A <HR>
1079N/A </LI>
195N/A <LI><A NAME="fastcgi">
195N/A <STRONG>Why isn't FastCGI included with Apache any more?</STRONG>
195N/A </A>
195N/A <P>
195N/A The simple answer is that it was becoming too difficult to keep the
195N/A version being included with Apache synchronized with the master copy
195N/A at the
195N/A <A
195N/A HREF="http://www.fastcgi.com/servers/apache/"
195N/A >FastCGI web site</A>. When a new version of Apache was released, the
195N/A version of the FastCGI module included with it would soon be out of date.
195N/A </P>
195N/A <P>
195N/A You can still obtain the FastCGI module for Apache from the master
195N/A FastCGI web site.
195N/A </P>
195N/A <HR>
195N/A </LI>
195N/A <LI><A NAME="nodelay">
195N/A <STRONG>Why am I getting &quot;<SAMP>httpd: could not set socket
195N/A option TCP_NODELAY</SAMP>&quot; in my error log?</STRONG>
195N/A </A>
195N/A <P>
4134N/A This message almost always indicates that the client disconnected
195N/A before Apache reached the point of calling <CODE>setsockopt()</CODE>
2845N/A for the connection. It shouldn't occur for more than about 1% of the
2845N/A requests your server handles, and it's advisory only in any case.
2845N/A </P>
2845N/A <HR>
2845N/A </LI>
2845N/A <LI><A NAME="peerreset">
2845N/A <STRONG>Why am I getting &quot;<SAMP>connection reset by
2845N/A peer</SAMP>&quot; in my error log?</STRONG>
2845N/A </A>
2845N/A <P>
2845N/A This is a normal message and nothing about which to be alarmed. It simply
2845N/A means that the client cancelled the connection before it had been
2845N/A completely set up - such as by the end-user pressing the &quot;Stop&quot;
2845N/A button. People's patience being what it is, sites with response-time
2845N/A problems or slow network links may experiences this more than
2845N/A high-capacity ones or those with large pipes to the network.
2845N/A </P>
2845N/A <HR>
2845N/A </LI>
2845N/A <LI><A NAME="nph-scripts">
2845N/A <STRONG>How can I get my script's output without Apache buffering
2845N/A it?</STRONG>
2845N/A </A>
4134N/A <P>
2845N/A In order to improve network performance, Apache buffers script output
2845N/A into relatively large chunks. If you have a script that sends
1689N/A information in bursts (such as partial-done messages in a multi-commit
1689N/A database transaction, perhaps), the client will not necessarily get
2845N/A the output as the script is generating it.
1079N/A </P>
1079N/A <P>
195N/A To avoid this, Apache recognizes scripts whose names begin with
195N/A &quot;<SAMP>nph-</SAMP>&quot; as <EM>non-parsed-header</EM> scripts.
195N/A That is, Apache won't buffer their output, but connect it directly to
195N/A the socket going back to the client.
195N/A </P>
195N/A <P>
195N/A While this will probably do what you want, there <EM>are</EM> some
195N/A disadvantages to it:
195N/A </P>
0N/A <UL>
0N/A <LI><STRONG>YOU</STRONG> (the script) are responsible for generating
0N/A <STRONG>ALL</STRONG> of the HTTP headers, and no longer
0N/A <EM>just</EM> the &quot;<SAMP>Content-type</SAMP>&quot; or
0N/A &quot;<SAMP>Location</SAMP>&quot; headers
0N/A </LI>
0N/A <LI>Unless your script generates its output carefully, you will see a
0N/A performance penalty as excessive numbers of packets go back and forth
0N/A </LI>
0N/A </UL>
0N/A <P>
0N/A As an example how you might handle the former (in a Perl script):
0N/A </P>
1177N/A <P>
1177N/A <DL>
1177N/A <DD><CODE>if ($0 =~ m:^(.*/)*nph-[^/]*$:) {
1177N/A <BR>
4134N/A &nbsp;&nbsp;&nbsp;&nbsp;
1177N/A $HTTP_headers&nbsp;=&nbsp;
4134N/A &quot;HTTP/1.1&nbsp;200&nbsp;OK\015\012&quot;;
2845N/A <BR>
2845N/A &nbsp;&nbsp;&nbsp;&nbsp;
2845N/A $HTTP_headers&nbsp;.=&nbsp;
2845N/A &quot;Connection:&nbsp;close\015\012&quot;;
2845N/A <BR>
2845N/A &nbsp;&nbsp;&nbsp;&nbsp;
2845N/A print&nbsp;$HTTP_headers;
2845N/A <BR>
2845N/A }</CODE>
2845N/A </DD>
2845N/A </DL>
2845N/A </P>
2845N/A <P>
2845N/A and then follow with your normal non-<SAMP>nph</SAMP> headers.
2845N/A </P>
2845N/A <HR>
2845N/A </LI>
2845N/A <LI><A NAME="linuxiovec">
2845N/A <STRONG>Why do I get complaints about redefinition
2845N/A of &quot;<CODE>struct iovec</CODE>&quot; when
2845N/A compiling under Linux?</STRONG>
2845N/A </A>
2845N/A <P>
2845N/A This is a conflict between your C library includes and your kernel
2845N/A includes. You need to make sure that the versions of both are matched
4134N/A properly. There are two workarounds, either one will solve the problem:
2845N/A </P>
4134N/A <P>
2845N/A <UL>
1177N/A <LI>Remove the definition of <CODE>struct iovec</CODE> from your C
1177N/A library includes. It is located in <CODE>/usr/include/sys/uio.h</CODE>.
1177N/A <STRONG>Or,</STRONG>
1177N/A </LI>
1177N/A <LI>Add <CODE>-DNO_WRITEV</CODE> to the <CODE>EXTRA_CFLAGS</CODE>
1177N/A line in your <SAMP>Configuration</SAMP> and reconfigure/rebuild.
1177N/A This hurts performance and should only be used as a last resort.
1177N/A </LI>
1177N/A </UL>
1177N/A </P>
1177N/A <HR>
1177N/A </LI>
1177N/A <LI><A NAME="wheres-the-dump">
1177N/A <STRONG>The errorlog says Apache dumped core, but where's the dump
1177N/A file?</STRONG>
1177N/A </A>
1177N/A <P>
1177N/A In Apache version 1.2, the error log message
0N/A about dumped core includes the directory where the dump file should be
0N/A located. However, many Unixes do not allow a process that has
0N/A called <CODE>setuid()</CODE> to dump core for security reasons;
0N/A the typical Apache setup has the server started as root to bind to
2845N/A port 80, after which it changes UIDs to a non-privileged user to
2845N/A serve requests.
2845N/A </P>
2845N/A <P>
2845N/A Dealing with this is extremely operating system-specific, and may
2845N/A require rebuilding your system kernel. Consult your operating system
2845N/A documentation or vendor for more information about whether your system
2845N/A does this and how to bypass it. If there <EM>is</EM> a documented way
2845N/A of bypassing it, it is recommended that you bypass it only for the
2845N/A <SAMP>httpd</SAMP> server process if possible.
2845N/A </P>
2845N/A <P>
2845N/A The canonical location for Apache's core-dump files is the
2845N/A <A
2845N/A HREF="/mod/core.html#serverroot"
2845N/A >ServerRoot</A>
2845N/A directory.
2845N/A </P>
2845N/A <HR>
2845N/A </LI>
2845N/A <LI><A NAME="dnsauth">
2845N/A <STRONG>Why isn't restricting access by host or domain name
2845N/A working correctly?</STRONG>
2845N/A </A>
2845N/A <P>
2845N/A Two of the most common causes of this are:
2845N/A </P>
1842N/A <OL>
1842N/A <LI><STRONG>An error, inconsistency, or unexpected mapping in the DNS
2845N/A registration</STRONG>
0N/A <BR>
0N/A This happens frequently: your configuration restricts access to
0N/A <SAMP>Host.FooBar.Com</SAMP>, but you can't get in from that host.
0N/A The usual reason for this is that <SAMP>Host.FooBar.Com</SAMP> is
0N/A actually an alias for another name, and when Apache performs the
0N/A address-to-name lookup it's getting the <EM>real</EM> name, not
0N/A <SAMP>Host.FooBar.Com</SAMP>. You can verify this by checking the
0N/A reverse lookup yourself. The easiest way to work around it is to
0N/A specify the correct host name in your configuration.
0N/A </LI>
0N/A <LI><STRONG>Inadequate checking and verification in your
0N/A configuration of Apache</STRONG>
0N/A <BR>
0N/A If you intend to perform access checking and restriction based upon
0N/A the client's host or domain name, you really need to configure
0N/A Apache to double-check the origin information it's supplied. You do
0N/A this by adding the <SAMP>-DMAXIMUM_DNS</SAMP> clause to the
0N/A <SAMP>EXTRA_CFLAGS</SAMP> definition in your
0N/A <SAMP>Configuration</SAMP> file. For example:
0N/A <P>
0N/A <DL>
0N/A <DD><CODE>EXTRA_CFLAGS=-DMAXIMUM_DNS</CODE>
0N/A </DD>
0N/A </DL>
0N/A </P>
0N/A <P>
0N/A This will cause Apache to be very paranoid about making sure a
2845N/A particular host address is <EM>really</EM> assigned to the name it
2845N/A claims to be. Note that this <EM>can</EM> incur a significant
2845N/A performance penalty, however, because of all the name resolution
2845N/A requests being sent to a nameserver.
2845N/A </P>
2845N/A </LI>
2845N/A </OL>
2845N/A <HR>
2845N/A </LI>
2845N/A <LI><A NAME="SSL-i">
2845N/A <STRONG>Why doesn't Apache include SSL?</STRONG>
2845N/A </A>
2845N/A <P>
2845N/A SSL (Secure Socket Layer) data transport requires encryption, and many
2845N/A governments have restrictions upon the import, export, and use of
2845N/A encryption technology. If Apache included SSL in the base package,
2845N/A its distribution would involve all sorts of legal and bureaucratic
2845N/A issues, and it would no longer be freely available. Also, some of
2845N/A the technology required to talk to current clients using SSL is
2845N/A patented by <A HREF="http://www.rsa.com/">RSA Data Security</A>,
2845N/A who restricts its use without a license.
2845N/A </P>
2845N/A <P>
2845N/A Some SSL implementations of Apache are available, however; see the
2845N/A &quot;<A
2845N/A HREF="http://www.apache.org/related_projects"
2845N/A >related projects</A>&quot;
1842N/A page at the main Apache web site.
1842N/A </P>
2845N/A <P>
0N/A You can find out more about this topic in the <CITE>Apache Week</CITE>
0N/A article about
0N/A <A
0N/A HREF="http://www.apacheweek.com/features/ssl"
0N/A REL="Help"
0N/A ><CITE>Apache and Secure Transactions</CITE></A>.
0N/A </P>
0N/A <HR>
0N/A </LI>
0N/A <LI><A NAME="HPUX-core">
0N/A <STRONG>Why do I get core dumps under HPUX using HP's ANSI
0N/A C compiler?</STRONG>
0N/A </A>
0N/A <P>
0N/A We have had numerous reports of Apache dumping core when compiled
0N/A with HP's ANSI C compiler using optimization. Disabling the compiler
0N/A optimization has fixed these problems.
0N/A </P>
0N/A <HR>
1177N/A </LI>
1177N/A <LI><A NAME="midi">
4134N/A <STRONG>How do I get Apache to send a MIDI file so the browser can
2845N/A play it?</STRONG>
2845N/A </A>
2845N/A <P>
2845N/A Even though the registered MIME type for MIDI files is
2845N/A <SAMP>audio/midi</SAMP>, some browsers are not set up to recognize it
2845N/A as such; instead, they look for <SAMP>audio/x-midi</SAMP>. There are
2845N/A two things you can do to address this:
2845N/A </P>
2845N/A <OL>
2845N/A <LI>Configure your browser to treat documents of type
2845N/A <SAMP>audio/midi</SAMP> correctly. This is the type that Apache
2845N/A sends by default. This may not be workable, however, if you have
2845N/A many client installations to change, or if some or many of the
2845N/A clients are not under your control.
2845N/A </LI>
2845N/A <LI>Instruct Apache to send a different <SAMP>Content-type</SAMP>
2845N/A header for these files by adding the following line to your server's
2845N/A configuration files:
2845N/A <P>
4134N/A <DL>
1177N/A <DD><CODE>AddType audio/x-midi .mid .midi .kar</CODE>
1177N/A </DD>
1177N/A </DL>
1177N/A </P>
1177N/A <P>
1177N/A Note that this may break browsers that <EM>do</EM> recognize the
1177N/A <SAMP>audio/midi</SAMP> MIME type unless they're prepared to also
1177N/A handle <SAMP>audio/x-midi</SAMP> the same way.
1177N/A </P>
1177N/A </LI>
1177N/A </OL>
1177N/A <HR>
1177N/A </LI>
1177N/A <LI><A NAME="cantbuild">
0N/A <STRONG>Why won't Apache compile with my system's
0N/A <SAMP>cc</SAMP>?</STRONG>
2845N/A </A>
2845N/A <P>
2845N/A If the server won't compile on your system, it is probably due to one
2845N/A of the following causes:
2845N/A </P>
2845N/A <UL>
2845N/A <LI><STRONG>The <SAMP>Configure</SAMP> script doesn't recognize your system
2845N/A environment.</STRONG>
2845N/A <BR>
2845N/A This might be either because it's completely unknown or because
2845N/A the specific environment (include files, OS version, <EM>et
2845N/A cetera</EM>) isn't explicitly handled. If this happens, you may
2845N/A need to port the server to your OS yourself.
2845N/A </LI>
2845N/A <LI><STRONG>Your system's C compiler is garbage.</STRONG>
2845N/A <BR>
2845N/A Some operating systems include a default C compiler that is either
2845N/A not ANSI C-compliant or suffers from other deficiencies. The usual
2845N/A recommendation in cases like this is to acquire, install, and use
2845N/A <SAMP>gcc</SAMP>.
1689N/A </LI>
1689N/A <LI><STRONG>Your <SAMP>include</SAMP> files may be confused.</STRONG>
2845N/A <BR>
0N/A In some cases, we have found that a compiler installation or system
0N/A upgrade has left the C header files in an inconsistent state. Make
0N/A sure that your include directory tree is in sync with the compiler and
0N/A the operating system.
0N/A </LI>
0N/A <LI><STRONG>Your operating system or compiler may be out of
0N/A revision.</STRONG>
0N/A <BR>
0N/A Software vendors (including those that develop operating systems)
0N/A issue new releases for a reason; sometimes to add functionality, but
0N/A more often to fix bugs that have been discovered. Try upgrading
0N/A your compiler and/or your operating system.
0N/A </LI>
0N/A </UL>
0N/A <P>
0N/A The Apache Group tests the ability to build the server on many
0N/A different platforms. Unfortunately, we can't test all of the OS
0N/A platforms there are. If you have verified that none of the above
0N/A issues is the cause of your problem, and it hasn't been reported
0N/A before, please submit a
2845N/A <A
2845N/A HREF="http://www.apache.org/bugdb.cgi"
2845N/A >problem report</A>.
2845N/A Be sure to include <EM>complete</EM> details, such as the compiler
2845N/A &amp; OS versions and exact error messages.
2845N/A </P>
2845N/A <HR>
2845N/A </LI>
2845N/A <LI><A NAME="addlog">
2845N/A <STRONG>How do I add browsers and referrers to my logs?</STRONG>
2845N/A </A>
2845N/A <P>
2845N/A Apache provides a couple of different ways of doing this. The
2845N/A recommended method is to compile the
2845N/A <A
2845N/A HREF="/mod/mod_log_config.html"
2845N/A ><SAMP>mod_log_config</SAMP></A>
2845N/A module into your configuration and use the
2845N/A <A
1689N/A HREF="/mod/mod_log_config.html#customlog"
1689N/A ><SAMP>CustomLog</SAMP></A>
2845N/A directive.
0N/A </P>
0N/A <P>
0N/A You can either log the additional information in files other than your
0N/A normal transfer log, or you can add them to the records already being
0N/A written. For example:
0N/A </P>
0N/A <P>
0N/A <CODE>
0N/A CustomLog&nbsp;logs/access_log&nbsp;"%h&nbsp;%l&nbsp;%u&nbsp;%t&nbsp;\"%r\"&nbsp;%s&nbsp;%b&nbsp;\"%{Referer}i\"&nbsp;\"%{User-Agent}i\""
2390N/A </CODE>
2390N/A </P>
2390N/A <P>
2390N/A This will add the values of the <SAMP>User-agent:</SAMP> and
2390N/A <SAMP>Referer:</SAMP> headers, which indicate the client and the
2390N/A referring page, respectively, to the end of each line in the access
2390N/A log.
2390N/A </P>
2390N/A <P>
2390N/A You may want to check out the <CITE>Apache Week</CITE> article
2390N/A entitled:
2390N/A &quot;<A
2390N/A HREF="http://www.apacheweek.com/features/logfiles"
2390N/A REL="Help"
2390N/A ><CITE>Gathering Visitor Information: Customising Your
2390N/A Logfiles</CITE></A>&quot;.
2390N/A </P>
2390N/A <HR>
2390N/A </LI>
0N/A <LI><A NAME="bind8.1">
0N/A <STRONG>Why do I get an error about an undefined reference to
0N/A &quot;<SAMP>__inet_ntoa</SAMP>&quot; or other
0N/A <SAMP>__inet_*</SAMP> symbols?</STRONG>
2845N/A </A>
0N/A <P>
0N/A If you have installed <A HREF="http://www.isc.org/bind.html">BIND-8</A>
0N/A then this is normally due to a conflict between your include files
0N/A and your libraries. BIND-8 installs its include files and libraries
0N/A <CODE>/usr/local/include/</CODE> and <CODE>/usr/local/lib/</CODE>, while
0N/A the resolver that comes with your system is probably installed in
0N/A <CODE>/usr/include/</CODE> and <CODE>/usr/lib/</CODE>. If
1864N/A your system uses the header files in <CODE>/usr/local/include/</CODE>
1864N/A before those in <CODE>/usr/include/</CODE> but you do not use the new
4134N/A resolver library, then the two versions will conflict.
0N/A </P>
2845N/A <P>
2845N/A To resolve this, you can either make sure you use the include files
2845N/A and libraries that came with your system or make sure to use the
2845N/A new include files and libraries. Adding <CODE>-lbind</CODE> to the
2845N/A <CODE>EXTRA_LDFLAGS</CODE> line in your <SAMP>Configuration</SAMP>
2845N/A file, then re-running <SAMP>Configure</SAMP>, should resolve the
2845N/A problem. (Apache versions 1.2.* and earlier use
2845N/A <CODE>EXTRA_LFLAGS</CODE> instead.)
2845N/A </P>
2845N/A <P>
2845N/A <STRONG>Note:</STRONG>As of BIND 8.1.1, the bind libraries and files are
2845N/A installed under <SAMP>/usr/local/bind</SAMP> by default, so you
2845N/A should not run into this problem. Should you want to use the bind
2845N/A resolvers you'll have to add the following to the respective lines:
2845N/A </P>
2845N/A <P>
2845N/A <DL>
2845N/A <DD><CODE>EXTRA_CFLAGS=-I/usr/local/bind/include
2845N/A <BR>
2845N/A EXTRA_LDFLAGS=-L/usr/local/bind/lib
2845N/A <BR>
2845N/A EXTRA_LIBS=-lbind</CODE>
4134N/A </DD>
2845N/A </DL>
2845N/A </P>
1864N/A <HR>
1864N/A </LI>
2845N/A <LI><A NAME="set-servername">
0N/A <STRONG>Why does accessing directories only work when I include
0N/A the trailing "/"
0N/A (<EM>e.g.</EM>,&nbsp;<SAMP>http://foo.domain.com/~user/</SAMP>)
0N/A but not when I omit it
0N/A (<EM>e.g.</EM>,&nbsp;<SAMP>http://foo.domain.com/~user</SAMP>)?</STRONG>
0N/A </A>
0N/A <P>
0N/A When you access a directory without a trailing "/", Apache needs
0N/A to send what is called a redirect to the client to tell it to
0N/A add the trailing slash. If it did not do so, relative URLs would
0N/A not work properly. When it sends the redirect, it needs to know
0N/A the name of the server so that it can include it in the redirect.
0N/A There are two ways for Apache to find this out; either it can guess,
0N/A or you can tell it. If your DNS is configured correctly, it can
0N/A normally guess without any problems. If it is not, however, then
0N/A you need to tell it.
0N/A </P>
0N/A <P>
0N/A Add a <A HREF="/mod/core.html#servername">ServerName</A> directive
0N/A to the config file to tell it what the domain name of the server is.
0N/A </P>
1177N/A <HR>
1177N/A </LI>
1177N/A <LI><A NAME="user-authentication">
4134N/A <STRONG>How do I set up Apache to require a username and
2845N/A password to access certain documents?</STRONG>
2845N/A </A>
2845N/A <P>
2845N/A There are several ways to do this; some of the more popular
2845N/A ones are to use the <A HREF="/mod/mod_auth.html">mod_auth</A>,
2845N/A <A HREF="/mod/mod_auth_db.html">mod_auth_db</A>, or
2845N/A <A HREF="/mod/mod_auth_dbm.html">mod_auth_dbm</A> modules.
2845N/A </P>
2845N/A <P>
2845N/A For an explaination on how to implement these restrictions, see
2845N/A <A
2845N/A HREF="http://www.apacheweek.com/"
2845N/A ><CITE>Apache Week</CITE></A>'s
2845N/A articles on
2845N/A <A
2845N/A HREF="http://www.apacheweek.com/features/userauth"
2845N/A ><CITE>Using User Authentication</CITE></A>
2845N/A or
2845N/A <A
2845N/A HREF="http://www.apacheweek.com/features/dbmauth"
2845N/A ><CITE>DBM User Authentication</CITE></A>.
2845N/A </P>
2845N/A <HR>
2845N/A </LI>
4134N/A <LI><A NAME="remote-auth-only">
2845N/A <STRONG>How do I set up Apache to allow access to certain
1177N/A documents only if a site is either a local site <EM>or</EM>
1177N/A the user supplies a password and username?</STRONG>
1177N/A </A>
1177N/A <P>
1177N/A Use the <A HREF="/mod/core.html#satisfy">Satisfy</A> directive,
1177N/A in particular the <CODE>Satisfy Any</CODE> directive, to require
1177N/A that only one of the access restrictions be met. For example,
1177N/A adding the following configuration to a <SAMP>.htaccess</SAMP>
1177N/A or server configuration file would restrict access to people who
1177N/A either are accessing the site from a host under domain.com or
1177N/A who can supply a valid username and password:
1177N/A </P>
1177N/A <P>
1177N/A <DL>
1177N/A <DD><CODE>deny from all
1177N/A <BR>
1177N/A allow from .domain.com
0N/A <BR>
1177N/A AuthType Basic
0N/A <BR>
2845N/A AuthUserFile /usr/local/etc/httpd/conf/htpasswd.users
2845N/A <BR>
2845N/A AuthName special directory
2845N/A <BR>
2845N/A require valid-user
2845N/A <BR>
2845N/A satisfy any</CODE>
2845N/A </DD>
2845N/A </DL>
2845N/A </P>
2845N/A <P>
2845N/A See the <A HREF="#user-authentication">user authentication</A>
2845N/A question and the <A HREF="/mod/mod_access.html">mod_access</A>
2845N/A module for details on how the above directives work.
2845N/A </P>
2845N/A <HR>
2845N/A </LI>
2845N/A <LI><A NAME="no-info-directives">
2845N/A <STRONG>Why doesn't mod_info list any directives?</STRONG>
2845N/A </A>
2845N/A <P>
2845N/A The
2845N/A <A
2845N/A HREF="/mod/mod_info.html"
1689N/A ><SAMP>mod_info</SAMP></A>
1689N/A module allows you to use a Web browser to see how your server is
2845N/A configured. Among the information it displays is the list modules and
0N/A their configuration directives. The &quot;current&quot; values for
0N/A the directives are not necessarily those of the running server; they
1689N/A are extracted from the configuration files themselves at the time of
0N/A the request. If the files have been changed since the server was last
0N/A reloaded, the display will will not match the values actively in use.
0N/A If the files and the path to the files are not readable by the user as
0N/A which the server is running (see the
0N/A <A
0N/A HREF="/mod/core.html#user"
0N/A ><SAMP>User</SAMP></A>
0N/A directive), then <SAMP>mod_info</SAMP> cannot read them in order to
0N/A list their values. An entry <EM>will</EM> be made in the error log in
0N/A this event, however.
0N/A </P>
0N/A <HR>
0N/A </LI>
0N/A <LI><A NAME="linux-shmget">
0N/A <STRONG>When I run it under Linux I get "shmget:
0N/A function not found", what should I do?</STRONG>
0N/A </A>
0N/A <P>
0N/A Your kernel has been built without SysV IPC support. You will have to
0N/A rebuild the kernel with that support enabled (it's under the
2845N/A &quot;General Setup&quot; submenu). Documentation for
2845N/A kernel building is beyond the scope of this FAQ; you should consult
2845N/A the
2845N/A <A HREF="http://www.linuxhq.com/HOWTO/Kernel-HOWTO.html"
2845N/A >Kernel HOWTO</A>,
2845N/A or the documentation provided with your distribution, or a
2845N/A <A HREF="http://www.linuxhq.com/HOWTO/META-FAQ.html"
2845N/A >Linux newsgroup/mailing list</A>.
2845N/A As a last-resort workaround, you can
2845N/A comment out the <CODE>#define HAVE_SHMGET</CODE> definition in the
2845N/A <SAMP>LINUX</SAMP> section of
2845N/A <SAMP>src/conf.h</SAMP> and rebuild the server. This will produce
2845N/A a server which is slower and less reliable.
2845N/A </P>
2845N/A <HR>
2845N/A </LI>
2845N/A <LI><A NAME="authauthoritative">
2845N/A <STRONG>Why does my authentification give me a server error?</STRONG>
2845N/A </A>
2845N/A <P>
2845N/A Under normal circumstances, the Apache access control modules will
2845N/A pass unrecognized user IDs on to the next access control module in
2845N/A line. Only if the user ID is recognized and the password is validated
1689N/A (or not) will it give the usual success or &quot;authentification
1689N/A failed&quot; messages.
2845N/A </P>
0N/A <P>
0N/A However, if the last access module in line 'declines' the validation
1689N/A request (because it has never heard of the user ID or because it is not
0N/A configured), the <SAMP>http_request</SAMP> handler will give one of
0N/A the following, confusing, errors:
0N/A </P>
0N/A <UL>
0N/A <LI><SAMP>check access</SAMP>
0N/A </LI>
2390N/A <LI><SAMP>check user. No user file?</SAMP>
2390N/A </LI>
2390N/A <LI><SAMP>check access. No groups file?</SAMP>
2390N/A </LI>
2390N/A </UL>
2390N/A <P>
2390N/A This does <EM>not</EM> mean that you have to add an
2390N/A '<SAMP>AuthUserFile&nbsp;/dev/null</SAMP>' line as some magazines suggest!
2390N/A </P>
2390N/A <P>
2390N/A The solution is to ensure that at least the last module is authoritative
2390N/A and <STRONG>CONFIGURED</STRONG>. By default, <SAMP>mod_auth</SAMP> is
2390N/A authoritative and will give an OK/Denied, but only if it is configured
2390N/A with the proper <SAMP>AuthUserFile</SAMP>. Likewise, if a valid group
2390N/A is required. (Remember that the modules are processed in the reverse
2390N/A order from that in which they appear in your compile-time
2390N/A <SAMP>Configuration</SAMP> file.)
2390N/A </P>
2390N/A <P>
2390N/A A typical situation for this error is when you are using the
0N/A <SAMP>mod_auth_dbm</SAMP>, <SAMP>mod_auth_msql</SAMP>,
0N/A <SAMP>mod_auth_mysql</SAMP>, <SAMP>mod_auth_anon</SAMP> or
0N/A <SAMP>mod_auth_cookie</SAMP> modules on their own. These are by
0N/A default <STRONG>not</STRONG> authoritative, and this will pass the
0N/A buck on to the (non-existent) next authentification module when the
0N/A user ID is not in their respective database. Just add the appropriate
0N/A '<SAMP><EM>XXX</EM>Authoritative yes</SAMP>' line to the configuration.
0N/A </P>
0N/A <P>
0N/A In general it is a good idea (though not terribly efficient) to have the
0N/A file-based <SAMP>mod_auth</SAMP> a module of last resort. This allows
0N/A you to access the web server with a few special passwords even if the
1865N/A databases are down or corrupted. This does cost a
1177N/A file open/seek/close for each request in a protected area.
1177N/A </P>
1177N/A <HR>
4134N/A </LI>
4134N/A <LI><A NAME="auth-on-same-machine">
2845N/A <STRONG>Do I have to keep the (mSQL) authentification information
2845N/A on the same machine?</STRONG>
2845N/A </A>
2845N/A <P>
2845N/A Some organizations feel very strongly about keeping the authentification
2845N/A information on a different machine than the webserver. With the
2845N/A <SAMP>mod_auth_msql</SAMP>, <SAMP>mod_auth_mysql</SAMP>, and other SQL
2845N/A modules connecting to (R)DBMses this is quite possible. Just configure
2845N/A an explicit host to contact.
2845N/A </P>
2845N/A <P>
2845N/A Be aware that with mSQL and Oracle, opening and closing these database
2845N/A connections is very expensive and time consuming. You might want to
2845N/A look at the code in the <SAMP>auth_*</SAMP> modules and play with the
2845N/A compile time flags to alleviate this somewhat, if your RDBMS licences
2845N/A allow for it.
2845N/A </P>
2845N/A <HR>
2845N/A </LI>
2845N/A <LI><A NAME="msql-slow">
2845N/A <STRONG>Why is my mSQL authentification terribly slow?</STRONG>
2845N/A </A>
2845N/A <P>
2845N/A You have probably configured the Host by specificing a FQHN,
2845N/A and thus the libmsql will use a full blown tcp/ip socket to talk to
4134N/A the database, rather than a fast internal device. The
4134N/A <SAMP>libmsql</SAMP>, the mSQL FAQ, and the <SAMP>mod_auth_msql</SAMP>
2845N/A documentation warn you about this. If you have to use different
1177N/A hosts, check out the <SAMP>mod_auth_msql</SAMP> code for
1177N/A some compile time flags which might - or might not - suit you.
1177N/A </P>
1177N/A <HR>
1177N/A </LI>
1177N/A
1177N/A <!-- Don't forget to add HR tags at the end of each list item.. -->
1177N/A
1177N/A</OL>
1177N/A <!--#include virtual="footer.html" -->
1177N/A</BODY>
1177N/A</HTML>
1177N/A