granicus.if.org Git - apache/blob - docs/manual/misc/FAQ.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
   2 <HTML>
   3  <HEAD>
   4   <TITLE>Apache Server Frequently Asked Questions</TITLE>
   5  </HEAD>
   6 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
   7  <BODY
   8   BGCOLOR="#FFFFFF"
   9   TEXT="#000000"
  10   LINK="#0000FF"
  11   VLINK="#000080"
  12   ALINK="#FF0000"
  13  >
  14   <!--#include virtual="header.html" -->
  15   <H1 ALIGN="CENTER">Apache Server Frequently Asked Questions</H1>
  16   <P>
  17   $Revision: 1.137 $ ($Date: 1999/02/04 18:15:05 $)
  18   </P>
  19   <P>
  20   The latest version of this FAQ is always available from the main
  21   Apache web site, at
  22   &lt;<A
  23        HREF="http://www.apache.org/docs/misc/FAQ.html"
  24        REL="Help"
  25       ><SAMP>http://www.apache.org/docs/misc/FAQ.html</SAMP></A>&gt;.
  26   </P>
  27 <!-- Notes about changes:                                           -->
  28 <!--  - If adding a relative link to another part of the            -->
  29 <!--    documentation, *do* include the ".html" portion.  There's a -->
  30 <!--    good chance that the user will be reading the documentation -->
  31 <!--    on his own system, which may not be configured for          -->
  32 <!--    multiviews.                                                 -->
  33 <!--  - When adding items, make sure they're put in the right place -->
  34 <!--    - verify that the numbering matches up.                     -->
  35 <!--  - *Don't* use <PRE></PRE> blocks - they don't appear          -->
  36 <!--    correctly in a reliable way when this is converted to text  -->
  37 <!--    with Lynx.  Use <DL><DD><CODE>xxx<BR>xx</CODE></DD></DL>    -->
  38 <!--    blocks inside a <P></P> instead.  This is necessary to get  -->
  39 <!--    the horizontal and vertical indenting right.                -->
  40 <!--  - Don't forget to include an HR tag after the last /P tag     -->
  41 <!--    but before the /LI in an item.                              -->
  42   <P>
  43   If you are reading a text-only version of this FAQ, you may find numbers
  44   enclosed in brackets (such as &quot;[12]&quot;).  These refer to the list of
  45   reference URLs to be found at the end of the document.  These references
  46   do not appear, and are not needed, for the hypertext version.
  47   </P>
  48   <H2>The Questions</H2>
  49 <!-- Stuff to Add:                                                  -->
  50 <!-- - can't bind to port 80                                        -->
  51 <!--   - permission denied                                          -->
  52 <!--   - address already in use                                     -->
  53 <!-- - mod_auth & passwd lines "user:pw:.*" - ++1st colon onward is -->
  54 <!--   treated as pw, not just ++1st to --2nd.                      -->
  55 <!-- - SSL:                                                         -->
  56 <!--   - Can I use Apache-SSL for free in Canada?                   -->
  57 <!--   - Why can't I use Apache-SSL in the U.S.?                    -->
  58 <!-- - How can I found out how many visitors my site gets?          -->
  59 <!-- - How do I add a counter?                                      -->
  60 <!-- - How do I configure Apache as a proxy?                        -->
  61 <!-- - What browsers support HTTP/1.1?                              -->
  62 <!-- - What's the point of vhosts-by-name is there aren't any       -->
  63 <!--   HTTP/1.1 browsers?                                           -->
  64 <!-- - Is there an Apache for W95/WNT?                              -->
  65 <!-- - Why does Apache die when a vhost can't be DNS-resolved?      -->
  66 <!-- - Why do I get "send lost connection" messages in my error     -->
  67 <!--   log?                                                         -->
  68 <!--   - specifically consider .pdf files which seem to cause this  -->
  69 <!--     a lot when accessed via the plugin ... and also mention    -->
  70 <!--     how range-requests can cause bytes served < file size      -->
  71 <!-- - Why do directory indexes appear as garbage?  (A: -lucb)      -->
  72 <!-- - How do I add a footer to all pages offered by my server?     -->
  73 <!-- - Fix midi question; a bigger problem than midi vs. x-midi is  -->
  74 <!--   the simple fact that older versions of Apache (and new ones  -->
  75 <!--   that have been upgraded without upgrading the mime.types     -->
  76 <!--   file) don't have the type listed at all.                     -->
  77 <!-- - RewriteRule /~fraggle/* /cgi-bin/fraggle.pl does not work    -->
  78 <!-- - how do I disable authentication for a subdirectory?          -->
  79 <!--   (A: you can't but "satisfy any; allow from all" can be close -->
  80 <!-- - '400 malformed request' on Win32 might mean stale proxy; see -->
  81 <!--   PR #2300.                                                    -->
  82 <!-- - how do I tell what version of Apache I am running?           -->
  83 <UL>
  84  <LI><STRONG>Background</STRONG>
  85   <OL START=1>
  86    <LI><A HREF="#what">What is Apache?</A>
  87    </LI>
  88    <LI><A HREF="#why">Why was Apache created?</A>
  89    </LI>
  90    <LI><A HREF="#relate">How does The Apache Group's work relate to
  91     other servers?</A>
  92    </LI>
  93    <LI><A HREF="#name">Why the name &quot;Apache&quot;?</A>
  94    </LI>
  95    <LI><A HREF="#compare">OK, so how does Apache compare to other servers?</A>
  96    </LI>
  97    <LI><A HREF="#tested">How thoroughly tested is Apache?</A>
  98    </LI>
  99    <LI><A HREF="#future">What are the future plans for Apache?</A>
 100    </LI>
 101    <LI><A HREF="#support">Whom do I contact for support?</A>
 102    </LI>
 103    <LI><A HREF="#more">Is there any more information on Apache?</A>
 104    </LI>
 105    <LI><A HREF="#where">Where can I get Apache?</A>
 106    </LI>
 107   </OL>
 108  </LI>
 109  <LI><STRONG>Technical Questions</STRONG>
 110   <OL START=11>
 111    <LI><A HREF="#what2do">&quot;Why can't I ...?  Why won't ...
 112         work?&quot;  What to do in case of problems</A>
 113    </LI>
 114    <LI><A HREF="#compatible">How compatible is Apache with my existing
 115         NCSA 1.3 setup?</A>
 116    </LI>
 117    <LI><A HREF="#CGIoutsideScriptAlias">How do I enable CGI execution
 118         in directories other than the ScriptAlias?</A>
 119    </LI>
 120    <LI><A HREF="#premature-script-headers">What does it mean when my
 121         CGIs fail with &quot;<SAMP>Premature end of script
 122         headers</SAMP>&quot;?</A>
 123    </LI>
 124    <LI><A HREF="#ssi-part-i">How do I enable SSI (parsed HTML)?</A>
 125    </LI>
 126    <LI><A HREF="#ssi-part-ii">Why don't my parsed files get cached?</A>
 127    </LI>
 128    <LI><A HREF="#ssi-part-iii">How can I have my script output parsed?</A>
 129    </LI>
 130    <LI><A HREF="#ssi-part-iv">SSIs don't work for VirtualHosts and/or
 131         user home directories</A>
 132    </LI>
 133    <LI><A HREF="#proxy">Does or will Apache act as a Proxy server?</A>
 134    </LI>
 135    <LI><A HREF="#multiviews">What are &quot;multiviews&quot;?</A>
 136    </LI>
 137    <LI><A HREF="#fdlim">Why can't I run more than &lt;<EM>n</EM>&gt;
 138         virtual hosts?</A>
 139    </LI>
 140    <LI><A HREF="#freebsd-setsize">Can I increase <SAMP>FD_SETSIZE</SAMP>
 141         on FreeBSD?</A>
 142    </LI>
 143    <LI><A HREF="#POSTnotallowed">Why do I keep getting &quot;Method Not
 144         Allowed&quot; for form POST requests?</A>
 145    </LI>
 146    <LI><A HREF="#passwdauth">Can I use my <SAMP>/etc/passwd</SAMP> file
 147         for Web page authentication?</A>
 148    </LI>
 149    <LI><A HREF="#errordoc401">Why doesn't my <CODE>ErrorDocument
 150         401</CODE> work?</A>
 151    </LI>
 152    <LI><A HREF="#errordocssi">How can I use <CODE>ErrorDocument</CODE>
 153         and SSI to simplify customized error messages?</A>
 154    </LI>
 155    <LI><A HREF="#setgid">Why do I get &quot;<SAMP>setgid: Invalid
 156         argument</SAMP>&quot; at startup?</A>
 157    </LI>
 158    <LI><A HREF="#cookies1">Why does Apache send a cookie on every response?</A>
 159    </LI>
 160    <LI><A HREF="#cookies2">Why don't my cookies work, I even compiled in
 161         <SAMP>mod_cookies</SAMP>?</A>
 162    </LI>
 163    <LI><A HREF="#jdk1-and-http1.1">Why do my Java app[let]s give me plain text
 164         when I request an URL from an Apache server?</A>
 165    </LI>
 166    <LI><A HREF="#putsupport">Why can't I publish to my Apache server
 167         using PUT on Netscape Gold and other programs?</A>
 168    </LI>
 169    <LI><A HREF="#fastcgi">Why isn't FastCGI included with Apache any
 170         more?</A>
 171    </LI>
 172    <LI><A HREF="#nodelay">Why am I getting &quot;<SAMP>httpd: could not
 173         set socket option TCP_NODELAY</SAMP>&quot; in my error log?</A>
 174    </LI>
 175    <LI><A HREF="#peerreset">Why am I getting &quot;<SAMP>connection
 176         reset by peer</SAMP>&quot; in my error log?</A>
 177    </LI>
 178    <LI><A HREF="#nph-scripts">How can I get my script's output without
 179         Apache buffering it?  Why doesn't my server push work?</A>
 180    </LI>
 181    <LI><A HREF="#linuxiovec">Why do I get complaints about redefinition
 182         of &quot;<CODE>struct iovec</CODE>&quot; when compiling under Linux?</A>
 183    </LI>
 184    <LI><A HREF="#wheres-the-dump">The errorlog says Apache dumped core,
 185         but where's the dump file?</A>
 186    </LI>
 187    <LI><A HREF="#dnsauth">Why isn't restricting access by host or domain name
 188         working correctly?</A>
 189    </LI>
 190    <LI><A HREF="#SSL-i">Why doesn't Apache include SSL?</A>
 191    </LI>
 192    <LI><A HREF="#midi">How do I get Apache to send a MIDI file so the
 193         browser can play it?</A>
 194    </LI>
 195    <LI><A HREF="#cantbuild">Why won't Apache compile with my
 196         system's <SAMP>cc</SAMP>?</A>
 197    </LI>
 198    <LI><A HREF="#addlog">How do I add browsers and referrers to my logs?</A>
 199    </LI>
 200    <LI><A HREF="#bind8.1">Why do I get an error about an undefined
 201         reference to &quot;<SAMP>__inet_ntoa</SAMP>&quot; or other
 202         <SAMP>__inet_*</SAMP> symbols?</A>
 203    </LI>
 204    <LI><A HREF="#set-servername">Why does accessing directories only work
 205         when I include the trailing &quot;/&quot;
 206         (<EM>e.g.</EM>,&nbsp;<SAMP>http://foo.domain.com/~user/</SAMP>) but
 207         not when I omit it
 208         (<EM>e.g.</EM>,&nbsp;<SAMP>http://foo.domain.com/~user</SAMP>)?</A>
 209    </LI>
 210    <LI><A HREF="#user-authentication">How do I set up Apache to require
 211         a username and password to access certain documents?</A>
 212    </LI>
 213    <LI><A HREF="#remote-user-var">Why is the environment variable
 214         <SAMP>REMOTE_USER</SAMP> not set?</A>
 215    </LI>
 216    <LI><A HREF="#remote-auth-only">How do I set up Apache to allow access
 217         to certain documents only if a site is either a local site
 218         <EM>or</EM> the user supplies a password and username?</A>
 219    </LI>
 220    <LI><A HREF="#no-info-directives">Why doesn't mod_info list any
 221         directives?</A>
 222    </LI>
 223    <LI><A HREF="#linux-shmget">When I run it under Linux I get &quot;shmget:
 224         function not found&quot;, what should I do?</A>
 225    </LI>
 226    <LI><A HREF="#authauthoritative">Why does my authentication give
 227         me a server error?</A>
 228    </LI>
 229    <LI><A HREF="#auth-on-same-machine">Do I have to keep the (mSQL)
 230         authentication information on the same machine?</A>
 231    </LI>
 232    <LI><A HREF="#msql-slow">Why is my mSQL authentication terribly slow?</A>
 233    </LI>
 234    <LI><A HREF="#rewrite-more-config">Where can I find mod_rewrite rulesets
 235         which already solve particular URL-related problems?</A>
 236    </LI>
 237    <LI><A HREF="#rewrite-article">Where can I find any published information
 238         about URL-manipulations and mod_rewrite?</A>
 239    </LI>
 240    <LI><A HREF="#rewrite-complexity">Why is mod_rewrite so difficult to learn
 241         and seems so complicated?</A>
 242    </LI>
 243    <LI><A HREF="#rewrite-dontwork">What can I do if my RewriteRules don't work
 244         as expected?</A>
 245    </LI>
 246    <LI><A HREF="#rewrite-prefixdocroot">Why don't some of my URLs get
 247         prefixed with DocumentRoot when using mod_rewrite?</A>
 248    </LI>
 249    <LI><A HREF="#rewrite-nocase">How can I make all my URLs case-insensitive
 250         with mod_rewrite?</A>
 251    </LI>
 252    <LI><A HREF="#rewrite-virthost">Why are RewriteRules in my VirtualHost
 253         parts ignored?</A>
 254    </LI>
 255    <LI><A HREF="#rewrite-envwhitespace">How can I use strings with whitespaces
 256         in RewriteRule's ENV flag?</A>
 257    </LI>
 258    <LI><A HREF="#cgi-spec">Where can I find the &quot;CGI
 259         specification&quot;?</A>
 260    </LI>
 261    <LI><A HREF="#year2000">Is Apache Year 2000 compliant?</A>
 262    </LI>
 263    <LI><A HREF="#namevhost">I upgraded to Apache 1.3 and now my
 264         virtual hosts don't work!</A>
 265    </LI>
 266    <LI><A HREF="#redhat">I'm using RedHat Linux and I have problems with httpd
 267         dying randomly or not restarting properly</A>
 268    </LI>
 269    <LI><A HREF="#stopping">I upgraded from an Apache version earlier
 270         than 1.2.0 and suddenly I have problems with Apache dying randomly
 271         or not restarting properly</A>
 272    </LI>
 273    <LI><A HREF="#redhat-htm">I'm using RedHat Linux and my .htm files are
 274         showing up as HTML source rather than being formatted!</A>
 275    </LI>
 276    <LI><A HREF="#glibc-crypt">I'm using RedHat Linux 5.0, or some other
 277         <SAMP>glibc</SAMP>-based Linux system, and I get errors with the
 278         <CODE>crypt</CODE> function when I attempt to build Apache 1.2.</A>
 279    </LI>
 280    <LI><A HREF="#nfslocking">Server hangs, or fails to start, and/or error log
 281         fills with &quot;<SAMP>fcntl: F_SETLKW: No record locks
 282         available</SAMP>&quot; or similar messages</A>
 283    </LI>
 284    <LI><A HREF="#zoom">What's the best hardware/operating system/... How do
 285         I get the most out of my Apache Web server?</A>
 286    </LI>
 287    <LI><A HREF="#regex">What are "regular expressions"?</A>
 288    </LI>
 289    <LI><A HREF="#broken-gcc">I'm using gcc and I get some compilation errors,
 290         what is wrong?</A>
 291    </LI>
 292    <LI><A HREF="#htaccess-work">My <CODE>.htaccess</CODE> files are being
 293         ignored.</A>
 294    </LI>
 295    <LI><A HREF="#submit_patch">How do I submit a patch to the Apache Group?</A>
 296    </LI>
 297    <LI><A HREF="#aixccbug">Why am I getting "<SAMP>Expected &lt/Directory&gt;
 298         but saw &lt;/Directory&gt;</SAMP>" when I try to start Apache?</A>
 299    </LI>
 300    <LI><A HREF="#domination">Why has Apache stolen my favourite site's
 301         Internet address?</A>
 302    </LI>
 303    <LI><A HREF="#apspam">Why am I getting spam mail from the Apache site?</A>
 304    </LI>
 305   </OL>
 306  </LI>
 307 </UL>
 308
 309 <HR>
 310
 311   <H2>The Answers</H2>
 312   <H3>
 313    Background
 314   </H3>
 315 <OL START=1>
 316  <LI><A NAME="what">
 317       <STRONG>What is Apache?</STRONG>
 318      </A>
 319   <P>
 320   Apache was originally based on code and ideas found in the most
 321   popular HTTP server of the time.. NCSA httpd 1.3 (early 1995). It has
 322   since evolved into a far superior system which can rival (and probably
 323   surpass) almost any other UNIX based HTTP server in terms of functionality,
 324   efficiency and speed.
 325   </P>
 326   <P>
 327   Since it began, it has been completely rewritten, and includes many new
 328   features. Apache is, as of January 1997, the most popular WWW server on
 329   the Internet, according to the
 330   <A HREF="http://www.netcraft.com/Survey/">Netcraft Survey</A>.
 331   </P>
 332   <HR>
 333  </LI>
 334
 335  <LI><A NAME="why">
 336       <STRONG>Why was Apache created?</STRONG>
 337      </A>
 338   <P>
 339   To address the concerns of a group of WWW providers and part-time httpd
 340   programmers that httpd didn't behave as they wanted it to behave.
 341   Apache is an entirely volunteer effort, completely funded by its
 342   members, not by commercial sales.
 343   </P>
 344   <HR>
 345  </LI>
 346
 347  <LI><A NAME="relate">
 348       <STRONG>How does The Apache Group's work relate to other
 349       server efforts, such as NCSA's?</STRONG>
 350      </A>
 351   <P>
 352   We, of course, owe a great debt to NCSA and their programmers for
 353   making the server Apache was based on. We now, however, have our own
 354   server, and our project is mostly our own. The Apache Project is an
 355   entirely independent venture.
 356   </P>
 357   <HR>
 358  </LI>
 359
 360  <LI><A NAME="name">
 361       <STRONG>Why the name &quot;Apache&quot;?</STRONG>
 362       </A>
 363   <P>
 364   A cute name which stuck. Apache is &quot;<STRONG>A
 365   PA</STRONG>t<STRONG>CH</STRONG>y server&quot;.  It was
 366   based on some existing code and a series of &quot;patch files&quot;.
 367   </P>
 368   <HR>
 369  </LI>
 370
 371  <LI><A NAME="compare">
 372       <STRONG>OK, so how does Apache compare to other servers?</STRONG>
 373      </A>
 374   <P>
 375   For an independent assessment, see
 376   <A HREF="http://webcompare.internet.com/chart.html">Web Compare</A>'s
 377   comparison chart.
 378   </P>
 379   <P>
 380   Apache has been shown to be substantially faster than many other
 381   free servers. Although certain commercial servers have claimed to
 382   surpass Apache's speed (it has not been demonstrated that any of these
 383   &quot;benchmarks&quot; are a good way of measuring WWW server speed at any
 384   rate), we feel that it is better to have a mostly-fast free server
 385   than an extremely-fast server that costs thousands of dollars. Apache
 386   is run on sites that get millions of hits per day, and they have
 387   experienced no performance difficulties.
 388   </P>
 389   <HR>
 390  </LI>
 391
 392  <LI><A NAME="tested">
 393       <STRONG>How thoroughly tested is Apache?</STRONG>
 394      </A>
 395   <P>
 396   Apache is run on over 1.2 million Internet servers (as of July 1998). It has
 397   been tested thoroughly by both developers and users. The Apache Group
 398   maintains rigorous standards before releasing new versions of their
 399   server, and our server runs without a hitch on over one half of all
 400   WWW servers available on the Internet.  When bugs do show up, we
 401   release patches and new versions as soon as they are available.
 402   </P>
 403   <P>
 404   The Apache project's web site includes a page with a partial list of
 405   <A HREF="http://www.apache.org/info/apache_users.html">sites running
 406   Apache</A>.
 407   </P>
 408   <HR>
 409  </LI>
 410
 411  <LI><A NAME="future">
 412       <STRONG>What are the future plans for Apache?</STRONG>
 413      </A>
 414   <P>
 415   <UL>
 416    <LI>to continue to be an "open source" no-charge-for-use HTTP server,
 417    </LI>
 418    <LI>to keep up with advances in HTTP protocol and web developments in
 419     general,
 420    </LI>
 421    <LI>to collect suggestions for fixes/improvements from its users,
 422    </LI>
 423    <LI>to respond to needs of large volume providers as well as
 424     occasional users.
 425    </LI>
 426   </UL>
 427   <P></P>
 428   <HR>
 429  </LI>
 430
 431  <LI><A NAME="support">
 432       <STRONG>Whom do I contact for support?</STRONG>
 433      </A>
 434   <P>
 435   There is no official support for Apache. None of the developers want to
 436   be swamped by a flood of trivial questions that can be resolved elsewhere.
 437   Bug reports and suggestions should be sent <EM>via</EM>
 438   <A HREF="http://www.apache.org/bug_report.html">the bug report page</A>.
 439   Other questions should be directed to the
 440   <A HREF="news:comp.infosystems.www.servers.unix"
 441   >comp.infosystems.www.servers.unix</A> or <A HREF=
 442   "news:comp.infosystems.www.servers.ms-windows"
 443   >comp.infosystems.www.servers.ms-windows</A>
 444   newsgroup (as appropriate for the platform you use), where some of the
 445   Apache team lurk, in the company of many other httpd gurus who
 446   should be able to help.
 447   </P>
 448   <P>
 449   Commercial support for Apache is, however, available from a number
 450   of third parties.
 451   </P>
 452   <HR>
 453  </LI>
 454
 455  <LI><A NAME="more">
 456       <STRONG>Is there any more information available on
 457       Apache?</STRONG>
 458      </A>
 459   <P>
 460   Indeed there is.  See the main
 461   <A HREF="http://www.apache.org/">Apache web site</A>.
 462   There is also a regular electronic publication called
 463   <A HREF="http://www.apacheweek.com/" REL="Help"><CITE>Apache Week</CITE></A>
 464   available.  Links to relevant <CITE>Apache Week</CITE> articles are
 465   included below where appropriate. There are also some
 466   <A HREF="http://www.apache.org/info/apache_books.html"
 467   >Apache-specific books</A> available.
 468   </P>
 469   <HR>
 470  </LI>
 471
 472  <LI><A NAME="where">
 473       <STRONG>Where can I get Apache?</STRONG>
 474      </A>
 475   <P>
 476   You can find out how to download the source for Apache at the
 477   project's
 478   <A HREF="http://www.apache.org/">main web page</A>.
 479   </P>
 480   <HR>
 481  </LI>
 482 </OL>
 483   <H3>Technical Questions</H3>
 484 <OL START=11>
 485  <LI><A NAME="what2do">
 486       <STRONG>&quot;Why can't I ...?  Why won't ... work?&quot;  What to
 487       do in case of problems</STRONG>
 488      </A>
 489   <P>
 490   If you are having trouble with your Apache server software, you should
 491   take the following steps:
 492   </P>
 493   <OL>
 494    <LI><STRONG>Check the errorlog!</STRONG>
 495     <P>
 496     Apache tries to be helpful when it encounters a problem.  In many
 497     cases, it will provide some details by writing one or messages to
 498     the server error log.  Sometimes this is enough for you to diagnose
 499     &amp; fix the problem yourself (such as file permissions or the like).
 500     The default location of the error log is
 501     <SAMP>/usr/local/apache/logs/error_log</SAMP>, but see the
 502     <A HREF="../mod/core.html#errorlog"><SAMP>ErrorLog</SAMP></A>
 503     directive in your config files for the location on your server.
 504     </P>
 505    </LI>
 506    <LI><STRONG>Check the
 507     <A HREF="http://www.apache.org/docs/misc/FAQ.html">FAQ</A>!</STRONG>
 508     <P>
 509     The latest version of the Apache Frequently-Asked Questions list can
 510     always be found at the main Apache web site.
 511     </P>
 512    </LI>
 513    <LI><STRONG>Check the Apache bug database</STRONG>
 514     <P>
 515     Most problems that get reported to The Apache Group are recorded in
 516     the
 517     <A HREF="http://bugs.apache.org/">bug database</A>.
 518     <EM><STRONG>Please</STRONG> check the existing reports, open
 519     <STRONG>and</STRONG> closed, before adding one.</EM>  If you find
 520     that your issue has already been reported, please <EM>don't</EM> add
 521     a &quot;me, too&quot; report.  If the original report isn't closed
 522     yet, we suggest that you check it periodically.  You might also
 523     consider contacting the original submitter, because there may be an
 524     email exchange going on about the issue that isn't getting recorded
 525     in the database.
 526     </P>
 527    </LI>
 528    <LI><STRONG>Ask in the <SAMP>comp.infosystems.www.servers.unix</SAMP>
 529     USENET newsgroup</STRONG>
 530     <P>
 531     A lot of common problems never make it to the bug database because
 532     there's already high Q&amp;A traffic about them in the
 533     <A HREF="news:comp.infosystems.www.servers.unix"
 534     ><SAMP>comp.infosystems.www.servers.unix</SAMP></A>
 535     newsgroup.  Many Apache users, and some of the developers, can be
 536     found roaming its virtual halls, so it is suggested that you seek
 537     wisdom there.  The chances are good that you'll get a faster answer
 538     there than from the bug database, even if you <EM>don't</EM> see
 539     your question already posted.
 540     </P>
 541    </LI>
 542    <LI><STRONG>If all else fails, report the problem in the bug
 543     database</STRONG>
 544     <P>
 545     If you've gone through those steps above that are appropriate and
 546     have obtained no relief, then please <EM>do</EM> let The Apache
 547     Group know about the problem by
 548     <A HREF="http://www.apache.org/bug_report.html">logging a bug report</A>.
 549     </P>
 550     <P>
 551     If your problem involves the server crashing and generating a core
 552     dump, please include a backtrace (if possible).  As an example,
 553     </P>
 554     <P>
 555     <DL>
 556      <DD><CODE># cd <EM>ServerRoot</EM><BR>
 557       # dbx httpd core<BR>
 558       (dbx) where</CODE>
 559      </DD>
 560     </DL>
 561     <P></P>
 562     <P>
 563     (Substitute the appropriate locations for your
 564     <SAMP>ServerRoot</SAMP> and your <SAMP>httpd</SAMP> and
 565     <SAMP>core</SAMP> files.  You may have to use <CODE>gdb</CODE>
 566     instead of <CODE>dbx</CODE>.)
 567     </P>
 568    </LI>
 569   </OL>
 570   <HR>
 571  </LI>
 572
 573  <LI><A NAME="compatible">
 574       <STRONG>How compatible is Apache with my existing NCSA 1.3
 575       setup?</STRONG>
 576      </A>
 577   <P>
 578   Apache attempts to offer all the features and configuration options
 579   of NCSA httpd 1.3, as well as many of the additional features found in
 580   NCSA httpd 1.4 and NCSA httpd 1.5.
 581   </P>
 582   <P>
 583   NCSA httpd appears to be moving toward adding experimental features
 584   which are not generally required at the moment. Some of the experiments
 585   will succeed while others will inevitably be dropped. The Apache
 586   philosophy is to add what's needed as and when it is needed.
 587   </P>
 588   <P>
 589   Friendly interaction between Apache and NCSA developers should ensure
 590   that fundamental feature enhancements stay consistent between the two
 591   servers for the foreseeable future.
 592   </P>
 593   <HR>
 594  </LI>
 595
 596  <LI><A NAME="CGIoutsideScriptAlias">
 597       <STRONG>How do I enable CGI execution in directories other than
 598       the ScriptAlias?</STRONG>
 599      </A>
 600   <P>
 601   Apache recognizes all files in a directory named as a
 602   <A HREF="../mod/mod_alias.html#scriptalias"><SAMP>ScriptAlias</SAMP></A>
 603   as being eligible for execution rather than processing as normal
 604   documents.  This applies regardless of the file name, so scripts in a
 605   ScriptAlias directory don't need to be named
 606   &quot;<SAMP>*.cgi</SAMP>&quot; or &quot;<SAMP>*.pl</SAMP>&quot; or
 607   whatever.  In other words, <EM>all</EM> files in a ScriptAlias
 608   directory are scripts, as far as Apache is concerned.
 609   </P>
 610   <P>
 611   To persuade Apache to execute scripts in other locations, such as in
 612   directories where normal documents may also live, you must tell it how
 613   to recognize them - and also that it's okay to execute them.  For
 614   this, you need to use something like the
 615   <A HREF="../mod/mod_mime.html#addhandler"><SAMP>AddHandler</SAMP></A>
 616   directive.
 617   </P>
 618   <P>
 619   <OL>
 620    <LI>In an appropriate section of your server configuration files, add
 621     a line such as
 622     <P>
 623     <DL>
 624      <DD><CODE>AddHandler cgi-script .cgi</CODE>
 625      </DD>
 626     </DL>
 627     <P></P>
 628     <P>
 629     The server will then recognize that all files in that location (and
 630     its logical descendants) that end in &quot;<SAMP>.cgi</SAMP>&quot;
 631     are script files, not documents.
 632     </P>
 633    </LI>
 634    <LI>Make sure that the directory location is covered by an
 635     <A HREF="../mod/core.html#options"><SAMP>Options</SAMP></A>
 636     declaration that includes the <SAMP>ExecCGI</SAMP> option.
 637    </LI>
 638   </OL>
 639   <P></P>
 640   <P>
 641   In some situations, you might not want to actually
 642   allow all files named &quot;<SAMP>*.cgi</SAMP>&quot; to be executable.
 643   Perhaps all you want is to enable a particular file in a normal directory to
 644   be executable. This can be alternatively accomplished
 645   <EM>via</EM> <A HREF="../mod/mod_rewrite.html"><SAMP>mod_rewrite</SAMP></A>
 646   and the following steps:
 647   </P>
 648   <P>
 649   <OL>
 650    <LI>Locally add to the corresponding <SAMP>.htaccess</SAMP> file a ruleset
 651     similar to this one:
 652     <P>
 653     <DL>
 654      <DD><CODE>RewriteEngine on
 655       <BR>
 656       RewriteBase   /~foo/bar/
 657       <BR>
 658       RewriteRule   ^quux\.cgi$  -  [T=application/x-httpd-cgi]</CODE>
 659      </DD>
 660     </DL>
 661     <P></P>
 662    </LI>
 663    <LI>Make sure that the directory location is covered by an
 664     <A HREF="../mod/core.html#options"><SAMP>Options</SAMP></A>
 665     declaration that includes the <SAMP>ExecCGI</SAMP> and
 666     <SAMP>FollowSymLinks</SAMP> option.
 667    </LI>
 668   </OL>
 669   <P></P>
 670   <HR>
 671  </LI>
 672
 673  <LI><A NAME="premature-script-headers">
 674       <STRONG>What does it mean when my CGIs fail with
 675       &quot;<SAMP>Premature end of script headers</SAMP>&quot;?</STRONG>
 676      </A>
 677   <P>
 678   It means just what it says: the server was expecting a complete set of
 679   HTTP headers (one or more followed by a blank line), and didn't get
 680   them.
 681   </P>
 682   <P>
 683   The most common cause of this problem is the script dying before
 684   sending the complete set of headers, or possibly any at all, to the
 685   server.  To see if this is the case, try running the script standalone
 686   from an interactive session, rather than as a script under the server.
 687   If you get error messages, this is almost certainly the cause of the
 688   &quot;premature end of script headers&quot; message.
 689   </P>
 690   <P>
 691   The second most common cause of this (aside from people not
 692   outputting the required headers at all) is a result of an interaction
 693   with Perl's output buffering.  To make Perl flush its buffers
 694   after each output statement, insert the following statements around
 695   the <CODE>print</CODE> or <CODE>write</CODE> statements that send your
 696   HTTP headers:
 697   </P>
 698   <P>
 699   <DL>
 700    <DD><CODE>{<BR>
 701     &nbsp;local ($oldbar) = $|;<BR>
 702     &nbsp;$cfh = select (STDOUT);<BR>
 703     &nbsp;$| = 1;<BR>
 704     &nbsp;#<BR>
 705     &nbsp;# print your HTTP headers here<BR>
 706     &nbsp;#<BR>
 707     &nbsp;$| = $oldbar;<BR>
 708     &nbsp;select ($cfh);<BR>
 709     }</CODE>
 710    </DD>
 711   </DL>
 712   <P></P>
 713   <P>
 714   This is generally only necessary when you are calling external
 715   programs from your script that send output to stdout, or if there will
 716   be a long delay between the time the headers are sent and the actual
 717   content starts being emitted.  To maximize performance, you should
 718   turn buffer-flushing back <EM>off</EM> (with <CODE>$| = 0</CODE> or the
 719   equivalent) after the statements that send the headers, as displayed
 720   above.
 721   </P>
 722   <P>
 723   If your script isn't written in Perl, do the equivalent thing for
 724   whatever language you <EM>are</EM> using (<EM>e.g.</EM>, for C, call
 725   <CODE>fflush()</CODE> after writing the headers).
 726   </P>
 727   <P>
 728   Another cause for the &quot;premature end of script headers&quot;
 729   message are the RLimitCPU and RLimitMEM directives. You may
 730   get the message if the CGI script was killed due to a
 731   resource limit.
 732   </P>
 733   <HR>
 734  </LI>
 735
 736  <LI><A NAME="ssi-part-i">
 737       <STRONG>How do I enable SSI (parsed HTML)?</STRONG>
 738      </A>
 739   <P>
 740   SSI (an acronym for Server-Side Include) directives allow static HTML
 741   documents to be enhanced at run-time (<EM>e.g.</EM>, when delivered to
 742   a client by Apache).  The format of SSI directives is covered
 743   in the <A HREF="../mod/mod_include.html">mod_include manual</A>;
 744   suffice it to say that Apache supports not only SSI but
 745   xSSI (eXtended SSI) directives.
 746   </P>
 747   <P>
 748   Processing a document at run-time is called <EM>parsing</EM> it; hence
 749   the term &quot;parsed HTML&quot; sometimes used for documents that
 750   contain SSI instructions.  Parsing tends to be <EM>extremely</EM>
 751   resource-consumptive, and is not enabled by default.  It can also
 752   interfere with the cachability of your documents, which can put a
 753   further load on your server.  (see the
 754   <A HREF="#ssi-part-ii">next question</A> for more information about this.)
 755   </P>
 756   <P>
 757   To enable SSI processing, you need to
 758   </P>
 759   <UL>
 760    <LI>Build your server with the
 761     <A HREF="../mod/mod_include.html"><SAMP>mod_include</SAMP></A>
 762     module.  This is normally compiled in by default.
 763    </LI>
 764    <LI>Make sure your server configuration files have an
 765     <A HREF="../mod/core.html#options"><SAMP>Options</SAMP></A>
 766     directive which permits <SAMP>Includes</SAMP>.
 767    </LI>
 768    <LI>Make sure that the directory where you want the SSI documents to
 769     live is covered by the &quot;server-parsed&quot; content handler,
 770     either explicitly or in some ancestral location.  That can be done
 771     with the following
 772     <A HREF="../mod/mod_mime.html#addhandler"><SAMP>AddHandler</SAMP></A>
 773     directive:
 774     <P>
 775     <DL>
 776      <DD><CODE>AddHandler server-parsed .shtml</CODE>
 777      </DD>
 778     </DL>
 779     <P></P>
 780     <P>
 781     This indicates that all files ending in &quot;.shtml&quot; in that
 782     location (or its descendants) should be parsed.  Note that using
 783     &quot;.html&quot; will cause all normal HTML files to be parsed,
 784     which may put an inordinate load on your server.
 785     </P>
 786    </LI>
 787   </UL>
 788   <P>
 789   For additional information, see the <CITE>Apache Week</CITE> article on
 790   <A HREF="http://www.apacheweek.com/features/ssi" REL="Help"
 791   ><CITE>Using Server Side Includes</CITE></A>.
 792   </P>
 793   <HR>
 794  </LI>
 795
 796  <LI><A NAME="ssi-part-ii">
 797       <STRONG>Why don't my parsed files get cached?</STRONG>
 798      </A>
 799   <P>
 800   Since the server is performing run-time processing of your SSI
 801   directives, which may change the content shipped to the client, it
 802   can't know at the time it starts parsing what the final size of the
 803   result will be, or whether the parsed result will always be the same.
 804   This means that it can't generate <SAMP>Content-Length</SAMP> or
 805   <SAMP>Last-Modified</SAMP> headers.  Caches commonly work by comparing
 806   the <SAMP>Last-Modified</SAMP> of what's in the cache with that being
 807   delivered by the server.  Since the server isn't sending that header
 808   for a parsed document, whatever's doing the caching can't tell whether
 809   the document has changed or not - and so fetches it again to be on the
 810   safe side.
 811   </P>
 812   <P>
 813   You can work around this in some cases by causing an
 814   <SAMP>Expires</SAMP> header to be generated.  (See the
 815   <A HREF="../mod/mod_expires.html" REL="Help"><SAMP>mod_expires</SAMP></A>
 816   documentation for more details.)  Another possibility is to use the
 817   <A HREF="../mod/mod_include.html#xbithack" REL="Help"
 818   ><SAMP>XBitHack Full</SAMP></A>
 819   mechanism, which tells Apache to send (under certain circumstances
 820   detailed in the XBitHack directive description) a
 821   <SAMP>Last-Modified</SAMP> header based upon the last modification
 822   time of the file being parsed.  Note that this may actually be lying
 823   to the client if the parsed file doesn't change but the SSI-inserted
 824   content does; if the included content changes often, this can result
 825   in stale copies being cached.
 826   </P>
 827   <HR>
 828  </LI>
 829
 830  <LI><A NAME="ssi-part-iii">
 831       <STRONG>How can I have my script output parsed?</STRONG>
 832      </A>
 833   <P>
 834   So you want to include SSI directives in the output from your CGI
 835   script, but can't figure out how to do it?
 836   The short answer is &quot;you can't.&quot;  This is potentially
 837   a security liability and, more importantly, it can not be cleanly
 838   implemented under the current server API.  The best workaround
 839   is for your script itself to do what the SSIs would be doing.
 840   After all, it's generating the rest of the content.
 841   </P>
 842   <P>
 843   This is a feature The Apache Group hopes to add in the next major
 844   release after 1.3.
 845   </P>
 846   <HR>
 847  </LI>
 848
 849  <LI><A NAME="ssi-part-iv">
 850       <STRONG>SSIs don't work for VirtualHosts and/or
 851         user home directories.</STRONG>
 852      </A>
 853   <P>
 854   This is almost always due to having some setting in your config file that
 855   sets "Options Includes" or some other setting for your DocumentRoot
 856   but not for other directories.  If you set it inside a Directory
 857   section, then that setting will only apply to that directory.
 858   </P>
 859  </LI>
 860
 861  <LI><A NAME="proxy">
 862       <STRONG>Does or will Apache act as a Proxy server?</STRONG>
 863      </A>
 864   <P>
 865   Apache version 1.1 and above comes with a
 866   <A HREF="../mod/mod_proxy.html">proxy module</A>.
 867   If compiled in, this will make Apache act as a caching-proxy server.
 868   </P>
 869   <HR>
 870  </LI>
 871
 872  <LI><A NAME="multiviews">
 873       <STRONG>What are &quot;multiviews&quot;?</STRONG>
 874      </A>
 875   <P>
 876   &quot;Multiviews&quot; is the general name given to the Apache
 877   server's ability to provide language-specific document variants in
 878   response to a request.  This is documented quite thoroughly in the
 879   <A HREF="../content-negotiation.html" REL="Help">content negotiation</A>
 880   description page.  In addition, <CITE>Apache Week</CITE> carried an
 881   article on this subject entitled
 882   &quot;<A HREF="http://www.apacheweek.com/features/negotiation" REL="Help"
 883         ><CITE>Content Negotiation Explained</CITE></A>&quot;.
 884   </P>
 885   <HR>
 886  </LI>
 887
 888  <LI><A NAME="fdlim">
 889       <STRONG>Why can't I run more than &lt;<EM>n</EM>&gt;
 890       virtual hosts?</STRONG>
 891      </A>
 892   <P>
 893   You are probably running into resource limitations in your
 894   operating system.  The most common limitation is the
 895   <EM>per</EM>-process limit on <STRONG>file descriptors</STRONG>,
 896   which is almost always the cause of problems seen when adding
 897   virtual hosts.  Apache often does not give an intuitive error
 898   message because it is normally some library routine (such as
 899   <CODE>gethostbyname()</CODE>) which needs file descriptors and
 900   doesn't complain intelligibly when it can't get them.
 901   </P>
 902   <P>
 903   Each log file requires a file descriptor, which means that if you are
 904   using separate access and error logs for each virtual host, each
 905   virtual host needs two file descriptors.  Each
 906   <A HREF="../mod/core.html#listen"><SAMP>Listen</SAMP></A>
 907   directive also needs a file descriptor.
 908   </P>
 909   <P>
 910   Typical values for &lt;<EM>n</EM>&gt; that we've seen are in
 911   the neighborhood of 128 or 250.  When the server bumps into the file
 912   descriptor limit, it may dump core with a SIGSEGV, it might just
 913   hang, or it may limp along and you'll see (possibly meaningful) errors
 914   in the error log.  One common problem that occurs when you run into
 915   a file descriptor limit is that CGI scripts stop being executed
 916   properly.
 917   </P>
 918   <P>
 919   As to what you can do about this:
 920   </P>
 921   <OL>
 922    <LI>Reduce the number of
 923     <A HREF="../mod/core.html#listen"><SAMP>Listen</SAMP></A>
 924     directives.  If there are no other servers running on the machine
 925     on the same port then you normally don't
 926     need any Listen directives at all.  By default Apache listens to
 927     all addresses on port 80.
 928    </LI>
 929    <LI>Reduce the number of log files.  You can use
 930     <A HREF="../mod/mod_log_config.html"><SAMP>mod_log_config</SAMP></A>
 931     to log all requests to a single log file while including the name
 932     of the virtual host in the log file.  You can then write a
 933     script to split the logfile into separate files later if
 934     necessary.  Such a script is provided with the Apache 1.3 distribution
 935     in the <SAMP>src/support/split-logfile</SAMP> file.
 936    </LI>
 937    <LI>Increase the number of file descriptors available to the server
 938     (see your system's documentation on the <CODE>limit</CODE> or
 939     <CODE>ulimit</CODE> commands).  For some systems, information on
 940     how to do this is available in the
 941     <A HREF="perf.html">performance hints</A> page.  There is a specific
 942     note for <A HREF="#freebsd-setsize">FreeBSD</A> below.
 943     <P>
 944     For Windows 95, try modifying your <SAMP>C:\CONFIG.SYS</SAMP> file to
 945     include a line like
 946     </P>
 947     <DL>
 948      <DD><CODE>FILES=300</CODE>
 949      </DD>
 950     </DL>
 951     <P>
 952     Remember that you'll need to reboot your Windows 95 system in order
 953     for the new value to take effect.
 954     </P>
 955    </LI>
 956    <LI>&quot;Don't do that&quot; - try to run with fewer virtual hosts
 957    </LI>
 958    <LI>Spread your operation across multiple server processes (using
 959     <A HREF="../mod/core.html#listen"><SAMP>Listen</SAMP></A>
 960     for example, but see the first point) and/or ports.
 961    </LI>
 962   </OL>
 963   <P>
 964   Since this is an operating-system limitation, there's not much else
 965   available in the way of solutions.
 966   </P>
 967   <P>
 968   As of 1.2.1 we have made attempts to work around various limitations
 969   involving running with many descriptors.
 970   <A HREF="descriptors.html">More information is available.</A>
 971   </P>
 972   <HR>
 973  </LI>
 974
 975  <LI><A NAME="freebsd-setsize">
 976       <STRONG>Can I increase <SAMP>FD_SETSIZE</SAMP> on FreeBSD?</STRONG>
 977      </A>
 978   <P>
 979   On versions of FreeBSD before 3.0, the <SAMP>FD_SETSIZE</SAMP> define
 980   defaults to 256.  This means that you will have trouble usefully using
 981   more than 256 file descriptors in Apache.  This can be increased, but
 982   doing so can be tricky.
 983   </P>
 984   <P>
 985   If you are using a version prior to 2.2, you need to recompile your
 986   kernel with a larger <SAMP>FD_SETSIZE</SAMP>.  This can be done by adding a
 987   line such as:
 988   </P>
 989   <DL>
 990    <DD><CODE>options FD_SETSIZE <EM>nnn</EM></CODE>
 991    </DD>
 992   </DL>
 993   <P>
 994   to your kernel config file.  Starting at version 2.2, this is no
 995   longer necessary.
 996   </P>
 997   <P>
 998   If you are using a version of 2.1-stable from after 1997/03/10 or
 999   2.2 or 3.0-current from before 1997/06/28, there is a limit in
1000   the resolver library that prevents it from using more file descriptors
1001   than what <SAMP>FD_SETSIZE</SAMP> is set to when libc is compiled.  To
1002   increase this, you have to recompile libc with a higher
1003   <SAMP>FD_SETSIZE</SAMP>.
1004   </P>
1005   <P>
1006   In FreeBSD 3.0, the default <SAMP>FD_SETSIZE</SAMP> has been increased to
1007   1024 and the above limitation in the resolver library
1008   has been removed.
1009   </P>
1010   <P>
1011   After you deal with the appropriate changes above, you can increase
1012   the setting of <SAMP>FD_SETSIZE</SAMP> at Apache compilation time
1013   by adding &quot;<SAMP>-DFD_SETSIZE=<EM>nnn</EM></SAMP>&quot; to the
1014   <SAMP>EXTRA_CFLAGS</SAMP> line in your <SAMP>Configuration</SAMP>
1015   file.
1016   </P>
1017   <HR>
1018  </LI>
1019
1020  <LI><A NAME="POSTnotallowed">
1021       <STRONG>Why do I keep getting &quot;Method Not Allowed&quot; for
1022       form POST requests?</STRONG>
1023      </A>
1024   <P>
1025   This is almost always due to Apache not being configured to treat the
1026   file you are trying to POST to as a CGI script.  You can not POST
1027   to a normal HTML file; the operation has no meaning.  See the FAQ
1028   entry on <A HREF="#CGIoutsideScriptAlias">CGIs outside ScriptAliased
1029   directories</A> for details on how to configure Apache to treat the
1030   file in question as a CGI.
1031   </P>
1032   <HR>
1033  </LI>
1034
1035  <LI><A NAME="passwdauth">
1036       <STRONG>Can I use my <SAMP>/etc/passwd</SAMP> file
1037       for Web page authentication?</STRONG>
1038      </A>
1039   <P>
1040   Yes, you can - but it's a <STRONG>very bad idea</STRONG>.  Here are
1041   some of the reasons:
1042   </P>
1043   <UL>
1044    <LI>The Web technology provides no governors on how often or how
1045     rapidly password (authentication failure) retries can be made.  That
1046     means that someone can hammer away at your system's
1047     <SAMP>root</SAMP> password using the Web, using a dictionary or
1048     similar mass attack, just as fast as the wire and your server can
1049     handle the requests.  Most operating systems these days include
1050     attack detection (such as <EM>n</EM> failed passwords for the same
1051     account within <EM>m</EM> seconds) and evasion (breaking the
1052     connection, disabling the account under attack, disabling
1053     <EM>all</EM> logins from that source, <EM>et cetera</EM>), but the
1054     Web does not.
1055    </LI>
1056    <LI>An account under attack isn't notified (unless the server is
1057     heavily modified); there's no &quot;You have 19483 login
1058     failures&quot; message when the legitimate owner logs in.
1059    </LI>
1060    <LI>Without an exhaustive and error-prone examination of the server
1061     logs, you can't tell whether an account has been compromised.
1062     Detecting that an attack has occurred, or is in progress, is fairly
1063     obvious, though - <EM>if</EM> you look at the logs.
1064    </LI>
1065    <LI>Web authentication passwords (at least for Basic authentication)
1066     generally fly across the wire, and through intermediate proxy
1067     systems, in what amounts to plain text.  &quot;O'er the net we
1068     go/Caching all the way;/O what fun it is to surf/Giving my password
1069     away!&quot;
1070    </LI>
1071    <LI>Since HTTP is stateless, information about the authentication is
1072     transmitted <EM>each and every time</EM> a request is made to the
1073     server.  Essentially, the client caches it after the first
1074     successful access, and transmits it without asking for all
1075     subsequent requests to the same server.
1076    </LI>
1077    <LI>It's relatively trivial for someone on your system to put up a
1078     page that will steal the cached password from a client's cache
1079     without them knowing.  Can you say &quot;password grabber&quot;?
1080    </LI>
1081   </UL>
1082   <P>
1083   If you still want to do this in light of the above disadvantages, the
1084   method is left as an exercise for the reader.  It'll void your Apache
1085   warranty, though, and you'll lose all accumulated UNIX guru points.
1086   </P>
1087   <HR>
1088  </LI>
1089
1090  <LI><A NAME="errordoc401">
1091       <STRONG>Why doesn't my <CODE>ErrorDocument 401</CODE> work?</STRONG>
1092      </A>
1093   <P>
1094   You need to use it with a URL in the form
1095   &quot;<SAMP>/foo/bar</SAMP>&quot; and not one with a method and
1096   hostname such as &quot;<SAMP>http://host/foo/bar</SAMP>&quot;.  See the
1097   <A HREF="../mod/core.html#errordocument"><SAMP>ErrorDocument</SAMP></A>
1098   documentation for details.  This was incorrectly documented in the past.
1099   </P>
1100   <HR>
1101  </LI>
1102
1103  <LI><A NAME="errordocssi">
1104       <STRONG>How can I use <CODE>ErrorDocument</CODE>
1105       and SSI to simplify customized error messages?</STRONG>
1106      </A>
1107   <P>
1108   Have a look at <A HREF="custom_errordocs.html">this document</A>.
1109   It shows in example form how you can a combination of XSSI and
1110   negotiation to tailor a set of <CODE>ErrorDocument</CODE>s to your
1111   personal taste, and returning different internationalized error
1112   responses based on the client's native language.
1113   </P>
1114   <HR>
1115  </LI>
1116
1117  <LI><A NAME="setgid">
1118       <STRONG>Why do I get &quot;<SAMP>setgid: Invalid
1119       argument</SAMP>&quot; at startup?</STRONG>
1120      </A>
1121   <P>
1122   Your
1123   <A HREF="../mod/core.html#group"><SAMP>Group</SAMP></A>
1124   directive (probably in <SAMP>conf/httpd.conf</SAMP>) needs to name a
1125   group that actually exists in the <SAMP>/etc/group</SAMP> file (or
1126   your system's equivalent).
1127   </P>
1128   <HR>
1129  </LI>
1130
1131  <LI><A NAME="cookies1">
1132       <STRONG>Why does Apache send a cookie on every response?</STRONG>
1133      </A>
1134   <P>
1135   Apache does <EM>not</EM> automatically send a cookie on every
1136   response, unless you have re-compiled it with the
1137   <A HREF="../mod/mod_usertrack.html"><SAMP>mod_usertrack</SAMP></A>
1138   module, and specifically enabled it with the
1139   <A HREF="../mod/mod_usertrack.html#cookietracking"
1140   ><SAMP>CookieTracking</SAMP></A>
1141   directive.
1142   This module has been in Apache since version 1.2.
1143   This module may help track users, and uses cookies to do this. If
1144   you are not using the data generated by <SAMP>mod_usertrack</SAMP>, do
1145   not compile it into Apache.
1146   </P>
1147   <HR>
1148  </LI>
1149
1150  <LI><A NAME="cookies2">
1151       <STRONG>Why don't my cookies work, I even compiled in
1152       <SAMP>mod_cookies</SAMP>?
1153       </STRONG>
1154      </A>
1155   <P>
1156   Firstly, you do <EM>not</EM> need to compile in
1157   <SAMP>mod_cookies</SAMP> in order for your scripts to work (see the
1158   <A HREF="#cookies1">previous question</A>
1159   for more about <SAMP>mod_cookies</SAMP>). Apache passes on your
1160   <SAMP>Set-Cookie</SAMP> header fine, with or without this module. If
1161   cookies do not work it will be because your script does not work
1162   properly or your browser does not use cookies or is not set-up to
1163   accept them.
1164   </P>
1165   <HR>
1166  </LI>
1167
1168  <LI><A NAME="jdk1-and-http1.1">
1169       <STRONG>Why do my Java app[let]s give me plain text when I request
1170       an URL from an Apache server?</STRONG>
1171      </A>
1172   <P>
1173   As of version 1.2, Apache is an HTTP/1.1 (HyperText Transfer Protocol
1174   version 1.1) server.  This fact is reflected in the protocol version
1175   that's included in the response headers sent to a client when
1176   processing a request.  Unfortunately, low-level Web access classes
1177   included in the Java Development Kit (JDK) version 1.0.2 expect to see
1178   the version string &quot;HTTP/1.0&quot; and do not correctly interpret
1179   the &quot;HTTP/1.1&quot; value Apache is sending (this part of the
1180   response is a declaration of what the server can do rather than a
1181   declaration of the dialect of the response).  The result
1182   is that the JDK methods do not correctly parse the headers, and
1183   include them with the document content by mistake.
1184   </P>
1185   <P>
1186   This is definitely a bug in the JDK 1.0.2 foundation classes from Sun,
1187   and it has been fixed in version 1.1.  However, the classes in
1188   question are part of the virtual machine environment, which means
1189   they're part of the Web browser (if Java-enabled) or the Java
1190   environment on the client system - so even if you develop
1191   <EM>your</EM> classes with a recent JDK, the eventual users might
1192   encounter the problem.
1193   The classes involved are replaceable by vendors implementing the
1194   Java virtual machine environment, and so even those that are based
1195   upon the 1.0.2 version may not have this problem.
1196   </P>
1197   <P>
1198   In the meantime, a workaround is to tell
1199   Apache to &quot;fake&quot; an HTTP/1.0 response to requests that come
1200   from the JDK methods; this can be done by including a line such as the
1201   following in your server configuration files:
1202   </P>
1203   <P>
1204   <DL>
1205    <DD><CODE>BrowserMatch Java1.0 force-response-1.0
1206     <BR>
1207     BrowserMatch JDK/1.0 force-response-1.0</CODE>
1208    </DD>
1209   </DL>
1210   <P></P>
1211   <P>
1212   More information about this issue can be found in the
1213   <A HREF="http://www.apache.org/info/jdk-102.html"
1214   ><CITE>Java and HTTP/1.1</CITE></A>
1215   page at the Apache web site.
1216   </P>
1217   <HR>
1218  </LI>
1219
1220  <LI><A NAME="putsupport">
1221       <STRONG>Why can't I publish to my Apache server using PUT on
1222       Netscape Gold and other programs?</STRONG>
1223      </A>
1224   <P>
1225   Because you need to install and configure a script to handle
1226   the uploaded files.  This script is often called a &quot;PUT&quot; handler.
1227   There are several available, but they may have security problems.
1228   Using FTP uploads may be easier and more secure, at least for now.
1229   For more information, see the <CITE>Apache Week</CITE> article
1230   <A HREF="http://www.apacheweek.com/features/put"
1231   ><CITE>Publishing Pages with PUT</CITE></A>.
1232   </P>
1233   <HR>
1234  </LI>
1235
1236  <LI><A NAME="fastcgi">
1237       <STRONG>Why isn't FastCGI included with Apache any more?</STRONG>
1238      </A>
1239   <P>
1240   The simple answer is that it was becoming too difficult to keep the
1241   version being included with Apache synchronized with the master copy
1242   at the
1243   <A HREF="http://www.fastcgi.com/"
1244   >FastCGI web site</A>.  When a new version of Apache was released, the
1245   version of the FastCGI module included with it would soon be out of date.
1246   </P>
1247   <P>
1248   You can still obtain the FastCGI module for Apache from the master
1249   FastCGI web site.
1250   </P>
1251   <HR>
1252  </LI>
1253
1254  <LI><A NAME="nodelay">
1255       <STRONG>Why am I getting &quot;<SAMP>httpd: could not set socket
1256       option TCP_NODELAY</SAMP>&quot; in my error log?</STRONG>
1257      </A>
1258   <P>
1259   This message almost always indicates that the client disconnected
1260   before Apache reached the point of calling <CODE>setsockopt()</CODE>
1261   for the connection.  It shouldn't occur for more than about 1% of the
1262   requests your server handles, and it's advisory only in any case.
1263   </P>
1264   <HR>
1265  </LI>
1266
1267  <LI><A NAME="peerreset">
1268       <STRONG>Why am I getting &quot;<SAMP>connection reset by
1269       peer</SAMP>&quot; in my error log?</STRONG>
1270      </A>
1271   <P>
1272   This is a normal message and nothing about which to be alarmed.  It simply
1273   means that the client canceled the connection before it had been
1274   completely set up - such as by the end-user pressing the &quot;Stop&quot;
1275   button.  People's patience being what it is, sites with response-time
1276   problems or slow network links may experiences this more than
1277   high-capacity ones or those with large pipes to the network.
1278   </P>
1279   <HR>
1280  </LI>
1281
1282  <LI><A NAME="nph-scripts">
1283       <STRONG>How can I get my script's output without Apache buffering
1284       it?  Why doesn't my server push work?</STRONG>
1285      </A>
1286   <P>
1287   As of Apache 1.3, CGI scripts are essentially not buffered.  Every time
1288   your script does a "flush" to output data, that data gets relayed on to
1289   the client.  Some scripting languages, for example Perl, have their own
1290   buffering for output - this can be disabled by setting the <CODE>$|</CODE>
1291   special variable to 1.  Of course this does increase the overall number
1292   of packets being transmitted, which can result in a sense of slowness for
1293   the end user.
1294   </P>
1295   <P>Prior to 1.3, you needed to use "nph-" scripts to accomplish non-buffering.
1296   Today, the only difference between nph scripts and normal scripts is
1297   that nph scripts require the full HTTP headers to be sent.
1298   </P>
1299   <HR>
1300  </LI>
1301
1302  <LI><A NAME="linuxiovec">
1303       <STRONG>Why do I get complaints about redefinition
1304       of &quot;<CODE>struct iovec</CODE>&quot; when
1305       compiling under Linux?</STRONG>
1306      </A>
1307   <P>
1308   This is a conflict between your C library includes and your kernel
1309   includes.  You need to make sure that the versions of both are matched
1310   properly.  There are two workarounds, either one will solve the problem:
1311   </P>
1312   <P>
1313   <UL>
1314    <LI>Remove the definition of <CODE>struct iovec</CODE> from your C
1315     library includes.  It is located in <CODE>/usr/include/sys/uio.h</CODE>.
1316     <STRONG>Or,</STRONG>
1317    </LI>
1318    <LI>Add  <CODE>-DNO_WRITEV</CODE> to the <CODE>EXTRA_CFLAGS</CODE>
1319     line in your <SAMP>Configuration</SAMP> and reconfigure/rebuild.
1320     This hurts performance and should only be used as a last resort.
1321    </LI>
1322   </UL>
1323   <P></P>
1324   <HR>
1325  </LI>
1326
1327  <LI><A NAME="wheres-the-dump">
1328       <STRONG>The errorlog says Apache dumped core, but where's the dump
1329       file?</STRONG>
1330      </A>
1331   <P>
1332   In Apache version 1.2, the error log message
1333   about dumped core includes the directory where the dump file should be
1334   located.  However, many Unixes do not allow a process that has
1335   called <CODE>setuid()</CODE> to dump core for security reasons;
1336   the typical Apache setup has the server started as root to bind to
1337   port 80, after which it changes UIDs to a non-privileged user to
1338   serve requests.
1339   </P>
1340   <P>
1341   Dealing with this is extremely operating system-specific, and may
1342   require rebuilding your system kernel.  Consult your operating system
1343   documentation or vendor for more information about whether your system
1344   does this and how to bypass it.  If there <EM>is</EM> a documented way
1345   of bypassing it, it is recommended that you bypass it only for the
1346   <SAMP>httpd</SAMP> server process if possible.
1347   </P>
1348   <P>
1349   The canonical location for Apache's core-dump files is the
1350   <A HREF="../mod/core.html#serverroot">ServerRoot</A>
1351   directory. As of Apache version 1.3, the location can be set <EM>via</EM>
1352   the
1353   <A HREF="../mod/core.html#coredumpdirectory"
1354   ><SAMP>CoreDumpDirectory</SAMP></A>
1355   directive to a different directory. Make sure that this directory is
1356   writable by the user the server runs as (as opposed to the user the server
1357   is <EM>started</EM> as).
1358   </P>
1359   <HR>
1360  </LI>
1361
1362  <LI><A NAME="dnsauth">
1363       <STRONG>Why isn't restricting access by host or domain name
1364       working correctly?</STRONG>
1365      </A>
1366   <P>
1367   Two of the most common causes of this are:
1368   </P>
1369   <OL>
1370    <LI><STRONG>An error, inconsistency, or unexpected mapping in the DNS
1371     registration</STRONG>
1372     <BR>
1373     This happens frequently: your configuration restricts access to
1374     <SAMP>Host.FooBar.Com</SAMP>, but you can't get in from that host.
1375     The usual reason for this is that <SAMP>Host.FooBar.Com</SAMP> is
1376     actually an alias for another name, and when Apache performs the
1377     address-to-name lookup it's getting the <EM>real</EM> name, not
1378     <SAMP>Host.FooBar.Com</SAMP>.  You can verify this by checking the
1379     reverse lookup yourself.  The easiest way to work around it is to
1380     specify the correct host name in your configuration.
1381    </LI>
1382    <LI><STRONG>Inadequate checking and verification in your
1383     configuration of Apache</STRONG>
1384     <BR>
1385     If you intend to perform access checking and restriction based upon
1386     the client's host or domain name, you really need to configure
1387     Apache to double-check the origin information it's supplied.  You do
1388     this by adding the <SAMP>-DMAXIMUM_DNS</SAMP> clause to the
1389     <SAMP>EXTRA_CFLAGS</SAMP> definition in your
1390     <SAMP>Configuration</SAMP> file.  For example:
1391     <P>
1392     <DL>
1393      <DD><CODE>EXTRA_CFLAGS=-DMAXIMUM_DNS</CODE>
1394      </DD>
1395     </DL>
1396     <P></P>
1397     <P>
1398     This will cause Apache to be very paranoid about making sure a
1399     particular host address is <EM>really</EM> assigned to the name it
1400     claims to be.  Note that this <EM>can</EM> incur a significant
1401     performance penalty, however, because of all the name resolution
1402     requests being sent to a nameserver.
1403     </P>
1404    </LI>
1405   </OL>
1406   <HR>
1407  </LI>
1408
1409  <LI><A NAME="SSL-i">
1410       <STRONG>Why doesn't Apache include SSL?</STRONG>
1411      </A>
1412   <P>
1413   SSL (Secure Socket Layer) data transport requires encryption, and many
1414   governments have restrictions upon the import, export, and use of
1415   encryption technology.  If Apache included SSL in the base package,
1416   its distribution would involve all sorts of legal and bureaucratic
1417   issues, and it would no longer be freely available.  Also, some of
1418   the technology required to talk to current clients using SSL is
1419   patented by <A HREF="http://www.rsa.com/">RSA Data Security</A>,
1420   who restricts its use without a license.
1421   </P>
1422   <P>
1423   Some SSL implementations of Apache are available, however; see the
1424   &quot;<A HREF="http://www.apache.org/related_projects.html"
1425         >related projects</A>&quot;
1426   page at the main Apache web site.
1427   </P>
1428   <P>
1429   You can find out more about this topic in the <CITE>Apache Week</CITE>
1430   article about
1431   <A HREF="http://www.apacheweek.com/features/ssl" REL="Help"
1432   ><CITE>Apache and Secure Transactions</CITE></A>.
1433   </P>
1434   <HR>
1435  </LI>
1436
1437  <LI><A NAME="midi">
1438       <STRONG>How do I get Apache to send a MIDI file so the browser can
1439       play it?</STRONG>
1440      </A>
1441   <P>
1442   Even though the registered MIME type for MIDI files is
1443   <SAMP>audio/midi</SAMP>, some browsers are not set up to recognize it
1444   as such; instead, they look for <SAMP>audio/x-midi</SAMP>.  There are
1445   two things you can do to address this:
1446   </P>
1447   <OL>
1448    <LI>Configure your browser to treat documents of type
1449     <SAMP>audio/midi</SAMP> correctly.  This is the type that Apache
1450     sends by default.  This may not be workable, however, if you have
1451     many client installations to change, or if some or many of the
1452     clients are not under your control.
1453    </LI>
1454    <LI>Instruct Apache to send a different <SAMP>Content-type</SAMP>
1455     header for these files by adding the following line to your server's
1456     configuration files:
1457     <P>
1458     <DL>
1459      <DD><CODE>AddType audio/x-midi .mid .midi .kar</CODE>
1460      </DD>
1461     </DL>
1462     <P></P>
1463     <P>
1464     Note that this may break browsers that <EM>do</EM> recognize the
1465     <SAMP>audio/midi</SAMP> MIME type unless they're prepared to also
1466     handle <SAMP>audio/x-midi</SAMP> the same way.
1467     </P>
1468    </LI>
1469   </OL>
1470   <HR>
1471  </LI>
1472
1473  <LI><A NAME="cantbuild">
1474       <STRONG>Why won't Apache compile with my system's
1475       <SAMP>cc</SAMP>?</STRONG>
1476      </A>
1477   <P>
1478   If the server won't compile on your system, it is probably due to one
1479   of the following causes:
1480   </P>
1481   <UL>
1482    <LI><STRONG>The <SAMP>Configure</SAMP> script doesn't recognize your system
1483     environment.</STRONG>
1484     <BR>
1485     This might be either because it's completely unknown or because
1486     the specific environment (include files, OS version, <EM>et
1487     cetera</EM>) isn't explicitly handled.  If this happens, you may
1488     need to port the server to your OS yourself.
1489    </LI>
1490    <LI><STRONG>Your system's C compiler is garbage.</STRONG>
1491     <BR>
1492     Some operating systems include a default C compiler that is either
1493     not ANSI C-compliant or suffers from other deficiencies.  The usual
1494     recommendation in cases like this is to acquire, install, and use
1495     <SAMP>gcc</SAMP>.
1496    </LI>
1497    <LI><STRONG>Your <SAMP>include</SAMP> files may be confused.</STRONG>
1498     <BR>
1499     In some cases, we have found that a compiler installation or system
1500     upgrade has left the C header files in an inconsistent state.  Make
1501     sure that your include directory tree is in sync with the compiler and
1502     the operating system.
1503    </LI>
1504    <LI><STRONG>Your operating system or compiler may be out of
1505     revision.</STRONG>
1506     <BR>
1507     Software vendors (including those that develop operating systems)
1508     issue new releases for a reason; sometimes to add functionality, but
1509     more often to fix bugs that have been discovered.  Try upgrading
1510     your compiler and/or your operating system.
1511    </LI>
1512   </UL>
1513   <P>
1514   The Apache Group tests the ability to build the server on many
1515   different platforms.  Unfortunately, we can't test all of the OS
1516   platforms there are.  If you have verified that none of the above
1517   issues is the cause of your problem, and it hasn't been reported
1518   before, please submit a
1519   <A HREF="http://www.apache.org/bug_report.html">problem report</A>.
1520   Be sure to include <EM>complete</EM> details, such as the compiler
1521   &amp; OS versions and exact error messages.
1522   </P>
1523   <HR>
1524  </LI>
1525
1526  <LI><A NAME="addlog">
1527       <STRONG>How do I add browsers and referrers to my logs?</STRONG>
1528      </A>
1529   <P>
1530   Apache provides a couple of different ways of doing this.  The
1531   recommended method is to compile the
1532   <A HREF="../mod/mod_log_config.html"><SAMP>mod_log_config</SAMP></A>
1533   module into your configuration and use the
1534   <A HREF="../mod/mod_log_config.html#customlog"><SAMP>CustomLog</SAMP></A>
1535   directive.
1536   </P>
1537   <P>
1538   You can either log the additional information in files other than your
1539   normal transfer log, or you can add them to the records already being
1540   written.  For example:
1541   </P>
1542   <P>
1543   <CODE>
1544    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\""
1545   </CODE>
1546   </P>
1547   <P>
1548   This will add the values of the <SAMP>User-agent:</SAMP> and
1549   <SAMP>Referer:</SAMP> headers, which indicate the client and the
1550   referring page, respectively, to the end of each line in the access
1551   log.
1552   </P>
1553   <P>
1554   You may want to check out the <CITE>Apache Week</CITE> article
1555   entitled:
1556   &quot;<A HREF="http://www.apacheweek.com/features/logfiles" REL="Help"
1557         ><CITE>Gathering Visitor Information: Customising Your
1558          Logfiles</CITE></A>&quot;.
1559   </P>
1560   <HR>
1561  </LI>
1562
1563  <LI><A NAME="bind8.1">
1564       <STRONG>Why do I get an error about an undefined reference to
1565       &quot;<SAMP>__inet_ntoa</SAMP>&quot; or other
1566       <SAMP>__inet_*</SAMP> symbols?</STRONG>
1567      </A>
1568   <P>
1569   If you have installed <A HREF="http://www.isc.org/bind.html">BIND-8</A>
1570   then this is normally due to a conflict between your include files
1571   and your libraries.  BIND-8 installs its include files and libraries
1572   <CODE>/usr/local/include/</CODE> and <CODE>/usr/local/lib/</CODE>, while
1573   the resolver that comes with your system is probably installed in
1574   <CODE>/usr/include/</CODE> and <CODE>/usr/lib/</CODE>.  If
1575   your system uses the header files in <CODE>/usr/local/include/</CODE>
1576   before those in <CODE>/usr/include/</CODE> but you do not use the new
1577   resolver library, then the two versions will conflict.
1578   </P>
1579   <P>
1580   To resolve this, you can either make sure you use the include files
1581   and libraries that came with your system or make sure to use the
1582   new include files and libraries.  Adding <CODE>-lbind</CODE> to the
1583   <CODE>EXTRA_LDFLAGS</CODE> line in your <SAMP>Configuration</SAMP>
1584   file, then re-running <SAMP>Configure</SAMP>, should resolve the
1585   problem.  (Apache versions 1.2.* and earlier use
1586   <CODE>EXTRA_LFLAGS</CODE> instead.)
1587   </P>
1588   <P>
1589   <STRONG>Note:</STRONG>As of BIND 8.1.1, the bind libraries and files are
1590   installed under <SAMP>/usr/local/bind</SAMP> by default, so you
1591   should not run into this problem.  Should you want to use the bind
1592   resolvers you'll have to add the following to the respective lines:
1593   </P>
1594   <P>
1595   <DL>
1596    <DD><CODE>EXTRA_CFLAGS=-I/usr/local/bind/include
1597     <BR>
1598     EXTRA_LDFLAGS=-L/usr/local/bind/lib
1599     <BR>
1600     EXTRA_LIBS=-lbind</CODE>
1601    </DD>
1602   </DL>
1603   <P></P>
1604   <HR>
1605  </LI>
1606
1607  <LI><A NAME="set-servername">
1608       <STRONG>Why does accessing directories only work when I include
1609       the trailing &quot;/&quot;
1610       (<EM>e.g.</EM>,&nbsp;<SAMP>http://foo.domain.com/~user/</SAMP>)
1611       but not when I omit it
1612       (<EM>e.g.</EM>,&nbsp;<SAMP>http://foo.domain.com/~user</SAMP>)?</STRONG>
1613      </A>
1614   <P>
1615   When you access a directory without a trailing &quot;/&quot;, Apache needs
1616   to send what is called a redirect to the client to tell it to
1617   add the trailing slash.  If it did not do so, relative URLs would
1618   not work properly.  When it sends the redirect, it needs to know
1619   the name of the server so that it can include it in the redirect.
1620   There are two ways for Apache to find this out; either it can guess,
1621   or you can tell it.  If your DNS is configured correctly, it can
1622   normally guess without any problems.  If it is not, however, then
1623   you need to tell it.
1624   </P>
1625   <P>
1626   Add a <A HREF="../mod/core.html#servername">ServerName</A> directive
1627   to the config file to tell it what the domain name of the server is.
1628   </P>
1629   <HR>
1630  </LI>
1631
1632  <LI><A NAME="user-authentication">
1633       <STRONG>How do I set up Apache to require a username and
1634       password to access certain documents?</STRONG>
1635      </A>
1636   <P>
1637   There are several ways to do this; some of the more popular
1638   ones are to use the <A HREF="../mod/mod_auth.html">mod_auth</A>,
1639   <A HREF="../mod/mod_auth_db.html">mod_auth_db</A>, or
1640   <A HREF="../mod/mod_auth_dbm.html">mod_auth_dbm</A> modules.
1641   </P>
1642   <P>
1643   For an explanation on how to implement these restrictions, see
1644   <A HREF="http://www.apacheweek.com/"><CITE>Apache Week</CITE></A>'s
1645   articles on
1646   <A HREF="http://www.apacheweek.com/features/userauth"
1647   ><CITE>Using User Authentication</CITE></A>
1648   or
1649   <A HREF="http://www.apacheweek.com/features/dbmauth"
1650   ><CITE>DBM User Authentication</CITE></A>.
1651   </P>
1652   <HR>
1653  </LI>
1654
1655  <LI><A NAME="remote-user-var">
1656       <STRONG>Why is the environment variable
1657       <SAMP>REMOTE_USER</SAMP> not set?</STRONG>
1658      </A>
1659   <P>
1660   This variable is set and thus available in SSI or CGI scripts <STRONG>if and
1661   only if</STRONG> the requested document was protected by access
1662   authentication.  For an explanation on how to implement these restrictions,
1663   see
1664   <A HREF="http://www.apacheweek.com/"><CITE>Apache Week</CITE></A>'s
1665   articles on
1666   <A HREF="http://www.apacheweek.com/features/userauth"
1667   ><CITE>Using User Authentication</CITE></A>
1668   or
1669   <A HREF="http://www.apacheweek.com/features/dbmauth"
1670   ><CITE>DBM User Authentication</CITE></A>.
1671   </P>
1672   <P>
1673   Hint: When using a CGI script to receive the data of a HTML <SAMP>FORM</SAMP>
1674   notice that protecting the document containing the <SAMP>FORM</SAMP> is not
1675   sufficient to provide <SAMP>REMOTE_USER</SAMP> to the CGI script.  You have
1676   to protect the CGI script, too. Or alternatively only the CGI script (then
1677   authentication happens only after filling out the form).
1678   </P>
1679   <HR>
1680  </LI>
1681
1682  <LI><A NAME="remote-auth-only">
1683       <STRONG>How do I set up Apache to allow access to certain
1684       documents only if a site is either a local site <EM>or</EM>
1685       the user supplies a password and username?</STRONG>
1686      </A>
1687   <P>
1688   Use the <A HREF="../mod/core.html#satisfy">Satisfy</A> directive,
1689   in particular the <CODE>Satisfy Any</CODE> directive, to require
1690   that only one of the access restrictions be met.  For example,
1691   adding the following configuration to a <SAMP>.htaccess</SAMP>
1692   or server configuration file would restrict access to people who
1693   either are accessing the site from a host under domain.com or
1694   who can supply a valid username and password:
1695   </P>
1696   <P>
1697   <DL>
1698    <DD><CODE>deny from all
1699     <BR>
1700     allow from .domain.com
1701     <BR>
1702     AuthType Basic
1703     <BR>
1704     AuthUserFile /usr/local/apache/conf/htpasswd.users
1705     <BR>
1706     AuthName "special directory"
1707     <BR>
1708     require valid-user
1709     <BR>
1710     satisfy any</CODE>
1711    </DD>
1712   </DL>
1713   <P></P>
1714   <P>
1715   See the <A HREF="#user-authentication">user authentication</A>
1716   question and the <A HREF="../mod/mod_access.html">mod_access</A>
1717   module for details on how the above directives work.
1718   </P>
1719   <HR>
1720  </LI>
1721
1722  <LI><A NAME="no-info-directives">
1723       <STRONG>Why doesn't mod_info list any directives?</STRONG>
1724      </A>
1725   <P>
1726   The <A HREF="../mod/mod_info.html"><SAMP>mod_info</SAMP></A>
1727   module allows you to use a Web browser to see how your server is
1728   configured.  Among the information it displays is the list modules and
1729   their configuration directives.  The &quot;current&quot; values for
1730   the directives are not necessarily those of the running server; they
1731   are extracted from the configuration files themselves at the time of
1732   the request.  If the files have been changed since the server was last
1733   reloaded, the display will will not match the values actively in use.
1734   If the files and the path to the files are not readable by the user as
1735   which the server is running (see the
1736   <A HREF="../mod/core.html#user"><SAMP>User</SAMP></A>
1737   directive), then <SAMP>mod_info</SAMP> cannot read them in order to
1738   list their values.  An entry <EM>will</EM> be made in the error log in
1739   this event, however.
1740   </P>
1741   <HR>
1742  </LI>
1743
1744  <LI><A NAME="linux-shmget">
1745       <STRONG>When I run it under Linux I get &quot;shmget:
1746       function not found&quot;, what should I do?</STRONG>
1747      </A>
1748   <P>
1749   Your kernel has been built without SysV IPC support.  You will have to
1750   rebuild the kernel with that support enabled (it's under the
1751   &quot;General Setup&quot; submenu).  Documentation for
1752   kernel building is beyond the scope of this FAQ; you should consult
1753   the
1754   <A HREF="http://www.linuxhq.com/HOWTO/Kernel-HOWTO.html"
1755   >Kernel HOWTO</A>,
1756   or the documentation provided with your distribution, or a
1757   <A HREF="http://www.linuxhq.com/HOWTO/META-FAQ.html"
1758   >Linux newsgroup/mailing list</A>.
1759   As a last-resort workaround, you can
1760   comment out the <CODE>#define&nbsp;USE_SHMGET_SCOREBOARD</CODE>
1761   definition in the
1762   <SAMP>LINUX</SAMP> section of
1763   <SAMP>src/conf.h</SAMP> and rebuild the server (prior to 1.3b4, simply
1764   removing <CODE>#define&nbsp;HAVE_SHMGET</CODE> would have sufficed).
1765   This will produce a server which is slower and less reliable.
1766   </P>
1767   <HR>
1768  </LI>
1769
1770  <LI><A NAME="authauthoritative">
1771       <STRONG>Why does my authentication give me a server error?</STRONG>
1772      </A>
1773   <P>
1774   Under normal circumstances, the Apache access control modules will
1775   pass unrecognized user IDs on to the next access control module in
1776   line.  Only if the user ID is recognized and the password is validated
1777   (or not) will it give the usual success or &quot;authentication
1778   failed&quot; messages.
1779   </P>
1780   <P>
1781   However, if the last access module in line 'declines' the validation
1782   request (because it has never heard of the user ID or because it is not
1783   configured), the <SAMP>http_request</SAMP> handler will give one of
1784   the following, confusing, errors:
1785   </P>
1786   <UL>
1787    <LI><SAMP>check access</SAMP>
1788    </LI>
1789    <LI><SAMP>check user.  No user file?</SAMP>
1790    </LI>
1791    <LI><SAMP>check access.  No groups file?</SAMP>
1792    </LI>
1793   </UL>
1794   <P>
1795   This does <EM>not</EM> mean that you have to add an
1796   '<SAMP>AuthUserFile&nbsp;/dev/null</SAMP>' line as some magazines suggest!
1797   </P>
1798   <P>
1799   The solution is to ensure that at least the last module is authoritative
1800   and <STRONG>CONFIGURED</STRONG>. By default, <SAMP>mod_auth</SAMP> is
1801   authoritative and will give an OK/Denied, but only if it is configured
1802   with the proper <SAMP>AuthUserFile</SAMP>.  Likewise, if a valid group
1803   is required.  (Remember that the modules are processed in the reverse
1804   order from that in which they appear in your compile-time
1805   <SAMP>Configuration</SAMP> file.)
1806   </P>
1807   <P>
1808   A typical situation for this error is when you are using the
1809   <SAMP>mod_auth_dbm</SAMP>, <SAMP>mod_auth_msql</SAMP>,
1810   <SAMP>mod_auth_mysql</SAMP>, <SAMP>mod_auth_anon</SAMP> or
1811   <SAMP>mod_auth_cookie</SAMP> modules on their own.  These are by
1812   default <STRONG>not</STRONG> authoritative, and this will pass the
1813   buck on to the (non-existent) next authentication module when the
1814   user ID is not in their respective database.  Just add the appropriate
1815   '<SAMP><EM>XXX</EM>Authoritative yes</SAMP>' line to the configuration.
1816   </P>
1817   <P>
1818   In general it is a good idea (though not terribly efficient) to have the
1819   file-based <SAMP>mod_auth</SAMP> a module of last resort. This allows
1820   you to access the web server with a few special passwords even if the
1821   databases are down or corrupted.  This does cost a
1822   file open/seek/close for each request in a protected area.
1823   </P>
1824   <HR>
1825  </LI>
1826
1827  <LI><A NAME="auth-on-same-machine">
1828       <STRONG>Do I have to keep the (mSQL) authentication information
1829       on the same machine?</STRONG>
1830      </A>
1831   <P>
1832   Some organizations feel very strongly about keeping the authentication
1833   information on a different machine than the webserver. With the
1834   <SAMP>mod_auth_msql</SAMP>, <SAMP>mod_auth_mysql</SAMP>, and other SQL
1835   modules connecting to (R)DBMses this is quite possible. Just configure
1836   an explicit host to contact.
1837   </P>
1838   <P>
1839   Be aware that with mSQL and Oracle, opening and closing these database
1840   connections is very expensive and time consuming. You might want to
1841   look at the code in the <SAMP>auth_*</SAMP> modules and play with the
1842   compile time flags to alleviate this somewhat, if your RDBMS licences
1843   allow for it.
1844   </P>
1845   <HR>
1846  </LI>
1847
1848  <LI><A NAME="msql-slow">
1849       <STRONG>Why is my mSQL authentication terribly slow?</STRONG>
1850      </A>
1851   <P>
1852   You have probably configured the Host by specifying a FQHN,
1853   and thus the <SAMP>libmsql</SAMP> will use a full blown TCP/IP socket
1854   to talk to the database, rather than a fast internal device.  The
1855   <SAMP>libmsql</SAMP>, the mSQL FAQ, and the <SAMP>mod_auth_msql</SAMP>
1856   documentation warn you about this.  If you have to use different
1857   hosts, check out the <SAMP>mod_auth_msql</SAMP> code for
1858   some compile time flags which might - or might not - suit you.
1859   </P>
1860   <HR>
1861  </LI>
1862
1863  <LI><A NAME="rewrite-more-config">
1864       <STRONG>Where can I find mod_rewrite rulesets which already solve
1865       particular URL-related problems?</STRONG>
1866      </A>
1867   <P>
1868   There is a collection of
1869   <A HREF="http://www.engelschall.com/pw/apache/rewriteguide/"
1870   >Practical Solutions for URL-Manipulation</A>
1871   where you can
1872   find all typical solutions the author of
1873   <A HREF="../mod/mod_rewrite.html"><SAMP>mod_rewrite</SAMP></A>
1874   currently knows of. If you have more
1875   interesting rulesets which solve particular problems not currently covered in
1876   this document, send it to
1877   <A HREF="mailto:rse@apache.org">Ralf S. Engelschall</A>
1878   for inclusion. The
1879   other webmasters will thank you for avoiding the reinvention of the wheel.
1880   </P>
1881   <HR>
1882  </LI>
1883
1884  <LI><A NAME="rewrite-article">
1885       <STRONG>Where can I find any published information about
1886       URL-manipulations and mod_rewrite?</STRONG>
1887      </A>
1888   <P>
1889   There is an article from
1890   <A HREF="mailto:rse@apache.org"
1891   >Ralf S. Engelschall</A>
1892   about URL-manipulations based on
1893   <A HREF="../mod/mod_rewrite.html"><SAMP>mod_rewrite</SAMP></A>
1894   in the &quot;iX Multiuser Multitasking Magazin&quot; issue #12/96. The
1895   german (original) version
1896   can be read online at
1897   &lt;<A HREF="http://www.heise.de/ix/artikel/9612149/"
1898       >http://www.heise.de/ix/artikel/9612149/</A>&gt;,
1899   the English (translated) version can be found at
1900   &lt;<A HREF="http://www.heise.de/ix/artikel/E/9612149/"
1901       >http://www.heise.de/ix/artikel/E/9612149/</A>&gt;.
1902   </P>
1903   <HR>
1904  </LI>
1905
1906  <LI><A NAME="rewrite-complexity">
1907       <STRONG>Why is mod_rewrite so difficult to learn and seems so
1908       complicated?</STRONG>
1909      </A>
1910   <P>
1911   Hmmm... there are a lot of reasons. First, mod_rewrite itself is a powerful
1912   module which can help you in really <STRONG>all</STRONG> aspects of URL
1913   rewriting, so it can be no trivial module per definition. To accomplish
1914   its hard job it uses software leverage and makes use of a powerful regular
1915   expression
1916   library by Henry Spencer which is an integral part of Apache since its
1917   version 1.2.  And regular expressions itself can be difficult to newbies,
1918   while providing the most flexible power to the advanced hacker.
1919   </P>
1920   <P>
1921   On the other hand mod_rewrite has to work inside the Apache API environment
1922   and needs to do some tricks to fit there. For instance the Apache API as of
1923   1.x really was not designed for URL rewriting at the <TT>.htaccess</TT>
1924   level of processing. Or the problem of multiple rewrites in sequence, which
1925   is also not handled by the API per design. To provide this features
1926   mod_rewrite has to do some special (but API compliant!) handling which leads
1927   to difficult processing inside the Apache kernel. While the user usually
1928   doesn't see anything of this processing, it can be difficult to find
1929   problems when some of your RewriteRules seem not to work.
1930   </P>
1931   <HR>
1932  </LI>
1933
1934  <LI><A NAME="rewrite-dontwork">
1935       <STRONG>What can I do if my RewriteRules don't work as expected?
1936       </STRONG>
1937      </A>
1938   <P>
1939   Use &quot;<SAMP>RewriteLog somefile</SAMP>&quot; and
1940   &quot;<SAMP>RewriteLogLevel 9</SAMP>&quot; and have a precise look at the
1941   steps the rewriting engine performs. This is really the only one and best
1942   way to debug your rewriting configuration.
1943   </P>
1944   <HR>
1945  </LI>
1946
1947  <LI><A NAME="rewrite-prefixdocroot"><STRONG>Why don't some of my URLs
1948       get prefixed with DocumentRoot when using mod_rewrite?</STRONG>
1949      </A>
1950   <P>
1951   If the rule starts with <SAMP>/somedir/...</SAMP> make sure that really no
1952   <SAMP>/somedir</SAMP> exists on the filesystem if you don't want to lead the
1953   URL to match this directory, <EM>i.e.</EM>, there must be no root directory named
1954   <SAMP>somedir</SAMP> on the filesystem. Because if there is such a
1955   directory, the URL will not get prefixed with DocumentRoot. This behaviour
1956   looks ugly, but is really important for some other aspects of URL
1957   rewriting.
1958   </P>
1959   <HR>
1960  </LI>
1961
1962  <LI><A NAME="rewrite-nocase">
1963       <STRONG>How can I make all my URLs case-insensitive with mod_rewrite?
1964       </STRONG>
1965      </A>
1966   <P>
1967   You can't! The reason is: First, case translations for arbitrary length URLs
1968   cannot be done <EM>via</EM> regex patterns and corresponding substitutions.
1969   One need
1970   a per-character pattern like sed/Perl <SAMP>tr|..|..|</SAMP> feature.
1971   Second, just
1972   making URLs always upper or lower case will not resolve the complete problem
1973   of case-INSENSITIVE URLs, because actually the URLs had to be rewritten to
1974   the correct case-variant residing on the filesystem because in later
1975   processing Apache needs to access the file.  And Unix filesystem is always
1976   case-SENSITIVE.
1977   </P>
1978   <P>
1979   But there is a module named <CODE>mod_speling.c</CODE> (yes, it is named
1980   this way!) out there on the net. Try this one.
1981   </P>
1982   <HR>
1983  </LI>
1984
1985  <LI><A NAME="rewrite-virthost">
1986       <STRONG> Why are RewriteRules in my VirtualHost parts ignored?</STRONG>
1987      </A>
1988   <P>
1989   Because you have to enable the engine for every virtual host explicitly due
1990   to security concerns. Just add a &quot;RewriteEngine on&quot; to your
1991   virtual host configuration parts.
1992   </P>
1993   <HR>
1994  </LI>
1995
1996  <LI><A NAME="rewrite-envwhitespace">
1997       <STRONG> How can I use strings with whitespaces in RewriteRule's ENV
1998       flag?</STRONG>
1999      </A>
2000   <P>
2001   There is only one ugly solution: You have to surround the complete flag
2002   argument by quotation marks (<SAMP>"[E=...]"</SAMP>). Notice: The argument
2003   to quote here is not the argument to the E-flag, it is the argument of the
2004   Apache config file parser, <EM>i.e.</EM>, the third argument of the RewriteRule here.
2005   So you have to write <SAMP>"[E=any text with whitespaces]"</SAMP>.
2006   </P>
2007   <HR>
2008  </LI>
2009
2010  <LI><A NAME="cgi-spec">
2011       <STRONG>Where can I find the &quot;CGI specification&quot;?</STRONG>
2012      </A>
2013   <P>
2014   The Common Gateway Interface (CGI) specification can be found at
2015   the original NCSA site
2016   &lt;<A HREF="http://hoohoo.ncsa.uiuc.edu/cgi/interface.html">
2017   <SAMP>http://hoohoo.ncsa.uiuc.edu/cgi/interface.html</SAMP></A>&gt;.
2018   This version hasn't been updated since 1995, and there have been
2019   some efforts to update it.
2020   </P>
2021   <P>
2022   A new draft is being worked on with the intent of making it an informational
2023   RFC; you can find out more about this project at
2024   &lt;<A HREF="http://web.golux.com/coar/cgi/"
2025       ><SAMP>http://web.golux.com/coar/cgi/</SAMP></A>&gt;.
2026   </P>
2027   <HR>
2028  </LI>
2029
2030  <LI><A NAME="year2000">
2031       <STRONG>Is Apache Year 2000 compliant?</STRONG>
2032      </A>
2033   <P>
2034   Yes, Apache is Year 2000 compliant.
2035   </P>
2036   <P>
2037   Apache internally never stores years as two digits.
2038   On the HTTP protocol level RFC1123-style addresses are generated
2039   which is the only format a HTTP/1.1-compliant server should
2040   generate. To be compatible with older applications Apache
2041   recognizes ANSI C's <CODE>asctime()</CODE> and
2042   RFC850-/RFC1036-style date formats, too.
2043   The <CODE>asctime()</CODE> format uses four-digit years,
2044   but the RFC850 and RFC1036 date formats only define a two-digit year.
2045   If Apache sees such a date with a value less than 70 it assumes that
2046   the century is <SAMP>20</SAMP> rather than <SAMP>19</SAMP>.
2047   </P>
2048   <P>
2049   Some aspects of Apache's output may use two-digit years, such as the
2050   automatic listing of directory contents provided by
2051   <A HREF="../mod/mod_autoindex.html"><SAMP>mod_autoindex</SAMP></A>
2052   with the
2053   <A HREF="../mod/mod_autoindex.html#indexoptions"
2054   ><SAMP>FancyIndexing</SAMP></A>
2055   option enabled, but it is improper to depend upon such displays for
2056   specific syntax.  And even that issue is being addressed by the
2057   developers; a future version of Apache should allow you to format that
2058   display as you like.
2059   </P>
2060   <P>
2061   Although Apache is Year 2000 compliant, you may still get problems
2062   if the underlying OS has problems with dates past year 2000
2063   (<EM>e.g.</EM>, OS calls which accept or return year numbers).
2064   Most (UNIX) systems store dates internally as signed 32-bit integers
2065   which contain the number of seconds since 1<SUP>st</SUP> January 1970, so
2066   the magic boundary to worry about is the year 2038 and not 2000.
2067   But modern operating systems shouldn't cause any trouble
2068   at all.
2069   </P>
2070   <HR>
2071  </LI>
2072
2073  <LI><A NAME="namevhost">
2074       <STRONG>I upgraded to Apache 1.3 and now my virtual hosts don't
2075       work!</STRONG>
2076      </A>
2077   <P>
2078   In versions of Apache prior to 1.3b2, there was a lot of confusion
2079   regarding address-based virtual hosts and (HTTP/1.1) name-based
2080   virtual hosts, and the rules concerning how the server processed
2081   <SAMP>&lt;VirtualHost&gt;</SAMP> definitions were very complex and not
2082   well documented.
2083   </P>
2084   <P>
2085   Apache 1.3b2 introduced a new directive,
2086   <A HREF="http://www.apache.org/docs/mod/core.html#namevirtualhost"
2087   ><SAMP>NameVirtualHost</SAMP></A>,
2088   which simplifies the rules quite a bit.  However, changing the rules
2089   like this means that your existing name-based
2090   <SAMP>&lt;VirtualHost&gt;</SAMP> containers probably won't work
2091   correctly immediately following the upgrade.
2092   </P>
2093   <P>
2094   To correct this problem, add the following line to the beginning of
2095   your server configuration file, before defining any virtual hosts:
2096   </P>
2097   <DL>
2098    <DD><CODE>NameVirtualHost <EM>n.n.n.n</EM></CODE>
2099    </DD>
2100   </DL>
2101   <P>
2102   Replace the &quot;<SAMP>n.n.n.n</SAMP>&quot; with the IP address to
2103   which the name-based virtual host names resolve; if you have multiple
2104   name-based hosts on multiple addresses, repeat the directive for each
2105   address.
2106   </P>
2107   <P>
2108   Make sure that your name-based <SAMP>&lt;VirtualHost&gt;</SAMP> blocks
2109   contain <SAMP>ServerName</SAMP> and possibly <SAMP>ServerAlias</SAMP>
2110   directives so Apache can be sure to tell them apart correctly.
2111   </P>
2112   <P>
2113   Please see the
2114   <A HREF="http://www.apache.org/docs/vhosts/">Apache
2115   Virtual Host documentation</A> for further details about configuration.
2116   </P>
2117   <HR>
2118  </LI>
2119
2120  <LI><A NAME="redhat">
2121       <STRONG>I'm using RedHat Linux and I have problems with httpd
2122       dying randomly or not restarting properly</STRONG>
2123      </A>
2124
2125   <P>
2126   RedHat Linux versions 4.x (and possibly earlier) RPMs contain
2127   various nasty scripts which do not stop or restart Apache properly.
2128   These can affect you even if you're not running the RedHat supplied
2129   RPMs.
2130   </P>
2131   <P>
2132   If you're using the default install then you're probably running
2133   Apache 1.1.3, which is outdated.  From RedHat's ftp site you can
2134   pick up a more recent RPM for Apache 1.2.x.  This will solve one of
2135   the problems.
2136   </P>
2137   <P>
2138   If you're using a custom built Apache rather than the RedHat RPMs
2139   then you should <CODE>rpm -e apache</CODE>.  In particular you want
2140   the mildly broken <CODE>/etc/logrotate.d/apache</CODE> script to be
2141   removed, and you want the broken <CODE>/etc/rc.d/init.d/httpd</CODE>
2142   (or <CODE>httpd.init</CODE>) script to be removed.  The latter is
2143   actually fixed by the apache-1.2.5 RPMs but if you're building your
2144   own Apache then you probably don't want the RedHat files.
2145   </P>
2146   <P>
2147   We can't stress enough how important it is for folks, <EM>especially
2148   vendors</EM> to follow the <A HREF="../stopping.html">stopping Apache
2149   directions</A> given in our documentation.  In RedHat's defense,
2150   the broken scripts were necessary with Apache 1.1.x because the
2151   Linux support in 1.1.x was very poor, and there were various race
2152   conditions on all platforms.  None of this should be necessary with
2153   Apache 1.2 and later.
2154   </P>
2155   <HR>
2156  </LI>
2157
2158  <LI><A NAME="stopping">
2159       <STRONG>I upgraded from an Apache version earlier
2160       than 1.2.0 and suddenly I have problems with Apache dying randomly
2161       or not restarting properly</STRONG>
2162      </A>
2163
2164   <P>
2165   You should read <A HREF="#redhat">the previous note</A> about
2166   problems with RedHat installations.  It is entirely likely that your
2167   installation has start/stop/restart scripts which were built for
2168   an earlier version of Apache.  Versions earlier than 1.2.0 had
2169   various race conditions that made it necessary to use
2170   <CODE>kill -9</CODE> at times to take out all the httpd servers.
2171   But that should not be necessary any longer.  You should follow
2172   the <A HREF="../stopping.html">directions on how to stop
2173   and restart Apache</A>.
2174   </P>
2175   <P>As of Apache 1.3 there is a script
2176   <CODE>src/support/apachectl</CODE> which, after a bit of
2177   customization, is suitable for starting, stopping, and restarting
2178   your server.
2179   </P>
2180   <HR>
2181  </LI>
2182
2183  <LI><A NAME="redhat-htm">
2184       <STRONG>I'm using RedHat Linux and my .htm files are showing
2185       up as HTML source rather than being formatted!</STRONG>
2186      </A>
2187
2188   <P>
2189   RedHat messed up and forgot to put a content type for <CODE>.htm</CODE>
2190   files into <CODE>/etc/mime.types</CODE>.  Edit <CODE>/etc/mime.types</CODE>,
2191   find the line containing <CODE>html</CODE> and add <CODE>htm</CODE> to it.
2192   Then restart your httpd server:
2193   </P>
2194   <DL>
2195    <DD><CODE>kill -HUP `cat /var/run/httpd.pid`</CODE>
2196    </DD>
2197   </DL>
2198   <P>
2199   Then <STRONG>clear your browsers' caches</STRONG>.  (Many browsers won't
2200   re-examine the content type after they've reloaded a page.)
2201   </P>
2202   <HR>
2203  </LI>
2204
2205  <LI><A NAME="glibc-crypt">
2206       <STRONG>I'm using RedHat Linux 5.0, or some other
2207       <SAMP>glibc</SAMP>-based Linux system, and I get errors with the
2208       <CODE>crypt</CODE> function when I attempt to build Apache 1.2.</STRONG>
2209      </A>
2210
2211   <P>
2212   <SAMP>glibc</SAMP> puts the <CODE>crypt</CODE> function into a separate
2213   library.  Edit your <CODE>src/Configuration</CODE> file and set this:
2214   </P>
2215   <DL>
2216    <DD><CODE>EXTRA_LIBS=-lcrypt</CODE>
2217    </DD>
2218   </DL>
2219   <P>
2220   Then re-run <SAMP>src/Configure</SAMP> and re-execute the make.
2221   </P>
2222   <HR>
2223  </LI>
2224
2225  <LI><A NAME="nfslocking">
2226       <STRONG>Server hangs, or fails to start, and/or error log
2227       fills with &quot;<SAMP>fcntl: F_SETLKW: No record locks
2228       available</SAMP>&quot; or similar messages</STRONG>
2229      </A>
2230
2231   <P>
2232   These are symptoms of a fine locking problem, which usually means that
2233   the server is trying to use a synchronization file on an NFS filesystem.
2234   </P>
2235   <P>
2236   Because of its parallel-operation model, the Apache Web server needs to
2237   provide some form of synchronization when accessing certain resources.
2238   One of these synchronization methods involves taking out locks on a file,
2239   which means that the filesystem whereon the lockfile resides must support
2240   locking.  In many cases this means it <EM>can't</EM> be kept on an
2241   NFS-mounted filesystem.
2242   </P>
2243   <P>
2244   To cause the Web server to work around the NFS locking limitations, include
2245   a line such as the following in your server configuration files:
2246   </P>
2247   <DL>
2248    <DD><CODE>LockFile /var/run/apache-lock</CODE>
2249    </DD>
2250   </DL>
2251   <P>
2252   The directory should not be generally writable (<EM>e.g.</EM>, don't use
2253   <SAMP>/var/tmp</SAMP>).
2254   See the <A HREF="../mod/core.html#lockfile"><SAMP>LockFile</SAMP></A>
2255   documentation for more information.
2256   </P>
2257   <HR>
2258  </LI>
2259  <LI><A NAME="zoom">
2260       <STRONG>What's the best hardware/operating system/... How do
2261       I get the most out of my Apache Web server?</STRONG>
2262      </A>
2263   <P>
2264   Check out Dean Gaudet's
2265   <A HREF="http://www.apache.org/docs/misc/perf-tuning.html"
2266   >performance tuning page</A>.
2267   </P>
2268   <HR>
2269  </LI>
2270  <LI><A NAME="regex">
2271       <STRONG>What are "regular expressions"?</STRONG></A>
2272    <P>
2273    Regular expressions are a way of describing a pattern - for example, "all
2274    the words that begin with the letter A" or "every 10-digit phone number"
2275    or even "Every sentence with two commas in it, and no capital letter Q".
2276    Regular expressions (aka "regexp"s) are useful in Apache because they
2277    let you apply certain attributes against collections of files or resources
2278    in very flexible ways - for example, all .gif and .jpg files under
2279    any "images" directory could be written as /.*\/images\/.*[jpg|gif]/.
2280    </P>
2281    <P>
2282    The best overview around is probably the one which comes with
2283    Perl.  We implement a simple subset of Perl's regexp support, but
2284    it's still a good way to learn what they mean.  You can start by
2285    going to the
2286    <A
2287     HREF="http://www.perl.com/CPAN-local/doc/manual/html/pod/perlre.html#Version_8_Regular_Expresions"
2288    >CPAN page on regular expressions</A>, and branching out from there.
2289    </P>
2290   <HR>
2291  </LI>
2292  <LI><A NAME="broken-gcc"><STRONG>I'm using gcc and I get some
2293         compilation errors, what is wrong?</STRONG></A>
2294     <P>
2295     GCC parses your system header files and produces a modified subset which
2296     it uses for compiling.  This behaviour ties GCC tightly to the version
2297     of your operating system.  So, for example, if you were running IRIX 5.3
2298     when you built GCC and then upgrade to IRIX 6.2 later, you will have to
2299     rebuild GCC.  Similarly for Solaris 2.4, 2.5, or 2.5.1 when you upgrade
2300     to 2.6.  Sometimes you can type "gcc -v" and it will tell you the version
2301     of the operating system it was built against.
2302     </P>
2303     <P>
2304     If you fail to do this, then it is very likely that Apache will fail
2305     to build.  One of the most common errors is with <CODE>readv</CODE>,
2306     <CODE>writev</CODE>, or <CODE>uio.h</CODE>.  This is <STRONG>not</STRONG> a
2307     bug with Apache.  You will need to re-install GCC.
2308     </P>
2309    <HR>
2310   </LI>
2311   <LI><A NAME="htaccess-work">
2312        <STRONG>My <CODE>.htaccess</CODE> files are being ignored.</STRONG></A>
2313    <P>
2314    This is almost always due to your <A HREF="../mod/core.html#allowoverride">
2315    AllowOverride</A> directive being set incorrectly for the directory in
2316    question.  If it is set to <CODE>None</CODE> then .htaccess files will
2317    not even be looked for.  If you do have one that is set, then be certain
2318    it covers the directory you are trying to use the .htaccess file in.
2319    This is normally accomplished by ensuring it is inside the proper
2320    <A HREF="../mod/core.html#directory">Directory</A> container.
2321    </P>
2322    <HR>
2323   </LI>
2324   <LI><A NAME="submit_patch">
2325        <STRONG>How do I submit a patch to the Apache Group?</STRONG></A>
2326    <P>
2327    The Apache Group encourages patches from outside developers. There are 2
2328    main "types"
2329    of patches: small bugfixes and general improvements. Bugfixes should be
2330    submitting using the
2331    Apache <A HREF="http://www.apache.org/bug_report.html">bug report page</A>.
2332    Improvements, modifications, and additions should follow the instructions
2333    below.
2334    </P>
2335    <P>
2336    In general, the first course of action is to be a member of the
2337    <SAMP>new-httpd@apache.org</SAMP> mailing list. This indicates to the Group
2338    that
2339    you are closely following the latest Apache developments. Your patch file
2340    should be
2341    generated using either '<CODE>diff&nbsp;-c</CODE>' or
2342    '<CODE>diff&nbsp;-u</CODE>' against the
2343    latest CVS tree. To submit your patch, send email to
2344    <SAMP>new-httpd@apache.org</SAMP>
2345    with a <SAMP>Subject:</SAMP> line that starts with <SAMP>[PATCH]</SAMP> and
2346    includes a general description of the patch. In the body of the message, the
2347    patch should be clearly described and then included at the end of the
2348    message.
2349    If the patch-file is long, you can note a URL to the file instead of the
2350    file itself. Use of MIME enclosures/attachments should be avoided.
2351    </P>
2352    <P>
2353    Be prepared to respond to any questions about your patches and possibly
2354    defend
2355    your code. If your patch results in a lot of discussion, you may be asked to
2356    submit an updated patch that incorporate all changes and suggestions.
2357    </P>
2358    <HR>
2359   </LI>
2360   <LI><A NAME="aixccbug"><STRONG>Why am I getting "<SAMP>Expected
2361        &lt/Directory&gt; but saw &lt;/Directory&gt;</SAMP>" when
2362        I try to start Apache?</STRONG></A>
2363    <P>
2364    This is a known problem with certain versions of the AIX C compiler.
2365    IBM are working on a solution, and the issue is being tracked by
2366    <A HREF="http://bugs.apache.org/index/full/2312">problem report #2312</A>.
2367    </P>
2368    <HR>
2369   </LI>
2370   <LI><A NAME="domination"><STRONG>Why has Apache stolen my favourite site's
2371        Internet address?</STRONG></A>
2372    <P>
2373    The simple answer is: "It hasn't."  This misconception is usually
2374    caused by the site in question having migrated to the Apache Web
2375    server software, but not having migrated the site's content yet.  When
2376    Apache is installed, the default page that gets installed tells the
2377    Webmaster the installation was successful.  The expectation is that
2378    this default page will be replaced with the site's real content.
2379    If it doesn't, complain to the Webmaster, not to the Apache project --
2380    we just make the software and aren't responsible for what people
2381    do (or don't do) with it.
2382    </P>
2383    <HR>
2384   </LI>
2385   <LI><A NAME="apspam"><STRONG>Why am I getting spam mail from the
2386        Apache site?</STRONG></A>
2387    <P>
2388    The short answer is: "You aren't."  Usually when someone thinks the
2389    Apache site is originating spam, it's because they've traced the
2390    spam to a Web site, and the Web site says it's using Apache.  See the
2391    <A HREF="#domination">previous FAQ entry</A> for more details on this
2392    phenomenon.
2393    </P>
2394    <P>
2395    No marketing spam originates from the Apache site.  The only mail
2396    that comes from the site goes only to addresses that have been
2397    <EM>requested</EM> to receive the mail.
2398    </P>
2399    <HR>
2400   </LI>
2401   <!-- Don't forget to add HR tags at the end of each list item.. -->
2402
2403 </OL>
2404 <!--#include virtual="footer.html" -->
2405 </BODY>
2406 </HTML>