| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> |
| <HTML> |
| <HEAD> |
| <TITLE>Apache Server Frequently Asked Questions</TITLE> |
| </HEAD> |
| <!-- Background white, links blue (unvisited), navy (visited), red (active) --> |
| <BODY |
| BGCOLOR="#FFFFFF" |
| TEXT="#000000" |
| LINK="#0000FF" |
| VLINK="#000080" |
| ALINK="#FF0000" |
| > |
| <!--#include virtual="header.html" --> |
| <H1 ALIGN="CENTER">Apache Server Frequently Asked Questions</H1> |
| <P> |
| $Revision: 1.144 $ ($Date: 1999/05/27 16:49:26 $) |
| </P> |
| <P> |
| The latest version of this FAQ is always available from the main |
| Apache web site, at |
| <<A |
| HREF="http://www.apache.org/docs/misc/FAQ.html" |
| REL="Help" |
| ><SAMP>http://www.apache.org/docs/misc/FAQ.html</SAMP></A>>. |
| </P> |
| <!-- Notes about changes: --> |
| <!-- - If adding a relative link to another part of the --> |
| <!-- documentation, *do* include the ".html" portion. There's a --> |
| <!-- good chance that the user will be reading the documentation --> |
| <!-- on his own system, which may not be configured for --> |
| <!-- multiviews. --> |
| <!-- - When adding items, make sure they're put in the right place --> |
| <!-- - verify that the numbering matches up. --> |
| <!-- - *Don't* use <PRE></PRE> blocks - they don't appear --> |
| <!-- correctly in a reliable way when this is converted to text --> |
| <!-- with Lynx. Use <DL><DD><CODE>xxx<BR>xx</CODE></DD></DL> --> |
| <!-- blocks inside a <P></P> instead. This is necessary to get --> |
| <!-- the horizontal and vertical indenting right. --> |
| <!-- - Don't forget to include an HR tag after the last /P tag --> |
| <!-- but before the /LI in an item. --> |
| <P> |
| If you are reading a text-only version of this FAQ, you may find numbers |
| enclosed in brackets (such as "[12]"). These refer to the list of |
| reference URLs to be found at the end of the document. These references |
| do not appear, and are not needed, for the hypertext version. |
| </P> |
| <H2>The Questions</H2> |
| <!-- Stuff to Add: --> |
| <!-- - can't bind to port 80 --> |
| <!-- - permission denied --> |
| <!-- - address already in use --> |
| <!-- - mod_auth & passwd lines "user:pw:.*" - ++1st colon onward is --> |
| <!-- treated as pw, not just ++1st to --2nd. --> |
| <!-- - SSL: --> |
| <!-- - Can I use Apache-SSL for free in Canada? --> |
| <!-- - Why can't I use Apache-SSL in the U.S.? --> |
| <!-- - How can I found out how many visitors my site gets? --> |
| <!-- - How do I add a counter? --> |
| <!-- - How do I configure Apache as a proxy? --> |
| <!-- - What browsers support HTTP/1.1? --> |
| <!-- - What's the point of vhosts-by-name is there aren't any --> |
| <!-- HTTP/1.1 browsers? --> |
| <!-- - Is there an Apache for W95/WNT? --> |
| <!-- - Why does Apache die when a vhost can't be DNS-resolved? --> |
| <!-- - Why do I get "send lost connection" messages in my error --> |
| <!-- log? --> |
| <!-- - specifically consider .pdf files which seem to cause this --> |
| <!-- a lot when accessed via the plugin ... and also mention --> |
| <!-- how range-requests can cause bytes served < file size --> |
| <!-- - Why do directory indexes appear as garbage? (A: -lucb) --> |
| <!-- - How do I add a footer to all pages offered by my server? --> |
| <!-- - Fix midi question; a bigger problem than midi vs. x-midi is --> |
| <!-- the simple fact that older versions of Apache (and new ones --> |
| <!-- that have been upgraded without upgrading the mime.types --> |
| <!-- file) don't have the type listed at all. --> |
| <!-- - RewriteRule /~fraggle/* /cgi-bin/fraggle.pl does not work --> |
| <!-- - how do I disable authentication for a subdirectory? --> |
| <!-- (A: you can't but "satisfy any; allow from all" can be close --> |
| <!-- - '400 malformed request' on Win32 might mean stale proxy; see --> |
| <!-- PR #2300. --> |
| <!-- - how do I tell what version of Apache I am running? --> |
| <UL> |
| <LI><STRONG>A. Background</STRONG> |
| <OL> |
| <LI><A HREF="#what">What is Apache?</A> |
| </LI> |
| <LI><A HREF="#why">Why was Apache created?</A> |
| </LI> |
| <LI><A HREF="#relate">How does The Apache Group's work relate to |
| other servers?</A> |
| </LI> |
| <LI><A HREF="#name">Why the name "Apache"?</A> |
| </LI> |
| <LI><A HREF="#compare">OK, so how does Apache compare to other servers?</A> |
| </LI> |
| <LI><A HREF="#tested">How thoroughly tested is Apache?</A> |
| </LI> |
| <LI><A HREF="#future">What are the future plans for Apache?</A> |
| </LI> |
| <LI><A HREF="#support">Whom do I contact for support?</A> |
| </LI> |
| <LI><A HREF="#more">Is there any more information on Apache?</A> |
| </LI> |
| <LI><A HREF="#where">Where can I get Apache?</A> |
| </LI> |
| </OL> |
| </LI> |
| <LI><STRONG>B. General Technical Questions</STRONG> |
| <OL> |
| <LI><A HREF="#what2do">"Why can't I ...? Why won't ... |
| work?" What to do in case of problems</A> |
| </LI> |
| <LI><A HREF="#compatible">How compatible is Apache with my existing |
| NCSA 1.3 setup?</A> |
| </LI> |
| <LI><A HREF="#year2000">Is Apache Year 2000 compliant?</A> |
| </LI> |
| <LI><A HREF="#submit_patch">How do I submit a patch to the Apache Group?</A> |
| </LI> |
| <LI><A HREF="#domination">Why has Apache stolen my favourite site's |
| Internet address?</A> |
| </LI> |
| <LI><A HREF="#apspam">Why am I getting spam mail from the Apache site?</A> |
| </LI> |
| <LI><A HREF="#redist">May I include the Apache software on a CD or other |
| package I'm distributing?</A> |
| </LI> |
| <LI><A HREF="#zoom">What's the best hardware/operating system/... How do |
| I get the most out of my Apache Web server?</A> |
| </LI> |
| <LI><A HREF="#regex">What are "regular expressions"?</A> |
| </LI> |
| </OL> |
| </LI> |
| <LI><STRONG>C. Building Apache</STRONG> |
| <OL> |
| <LI><A HREF="#bind8.1">Why do I get an error about an undefined |
| reference to "<SAMP>__inet_ntoa</SAMP>" or other |
| <SAMP>__inet_*</SAMP> symbols?</A> |
| </LI> |
| <LI><A HREF="#cantbuild">Why won't Apache compile with my |
| system's <SAMP>cc</SAMP>?</A> |
| </LI> |
| <LI><A HREF="#linuxiovec">Why do I get complaints about redefinition |
| of "<CODE>struct iovec</CODE>" when compiling under Linux?</A> |
| </LI> |
| <LI><A HREF="#broken-gcc">I'm using gcc and I get some compilation errors, |
| what is wrong?</A> |
| </LI> |
| <LI><A HREF="#glibc-crypt">I'm using RedHat Linux 5.0, or some other |
| <SAMP>glibc</SAMP>-based Linux system, and I get errors with the |
| <CODE>crypt</CODE> function when I attempt to build Apache 1.2.</A> |
| </LI> |
| </OL> |
| </LI> |
| |
| <LI><STRONG>D. Error Log Messages and Problems Starting Apache</STRONG> |
| <OL> |
| <LI><A HREF="#setgid">Why do I get "<SAMP>setgid: Invalid |
| argument</SAMP>" at startup?</A> |
| </LI> |
| <LI><A HREF="#nodelay">Why am I getting "<SAMP>httpd: could not |
| set socket option TCP_NODELAY</SAMP>" in my error log?</A> |
| </LI> |
| <LI><A HREF="#peerreset">Why am I getting "<SAMP>connection |
| reset by peer</SAMP>" in my error log?</A> |
| </LI> |
| <LI><A HREF="#wheres-the-dump">The errorlog says Apache dumped core, |
| but where's the dump file?</A> |
| </LI> |
| <LI><A HREF="#linux-shmget">When I run it under Linux I get "shmget: |
| function not found", what should I do?</A> |
| </LI> |
| <LI><A HREF="#nfslocking">Server hangs, or fails to start, and/or error log |
| fills with "<SAMP>fcntl: F_SETLKW: No record locks |
| available</SAMP>" or similar messages</A> |
| </LI> |
| <LI><A HREF="#aixccbug">Why am I getting "<SAMP>Expected </Directory> |
| but saw </Directory></SAMP>" when I try to start Apache?</A> |
| </LI> |
| <LI><A HREF="#redhat">I'm using RedHat Linux and I have problems with httpd |
| dying randomly or not restarting properly</A> |
| </LI> |
| <LI><A HREF="#stopping">I upgraded from an Apache version earlier |
| than 1.2.0 and suddenly I have problems with Apache dying randomly |
| or not restarting properly</A> |
| </LI> |
| </OL> |
| </LI> |
| |
| <LI><STRONG>E. Configuration Questions</STRONG> |
| <OL> |
| <LI><A HREF="#fdlim">Why can't I run more than <<EM>n</EM>> |
| virtual hosts?</A> |
| </LI> |
| <LI><A HREF="#freebsd-setsize">Can I increase <SAMP>FD_SETSIZE</SAMP> |
| on FreeBSD?</A> |
| </LI> |
| <LI><A HREF="#errordoc401">Why doesn't my <CODE>ErrorDocument |
| 401</CODE> work?</A> |
| </LI> |
| <LI><A HREF="#cookies1">Why does Apache send a cookie on every response?</A> |
| </LI> |
| <LI><A HREF="#cookies2">Why don't my cookies work, I even compiled in |
| <SAMP>mod_cookies</SAMP>?</A> |
| </LI> |
| <LI><A HREF="#jdk1-and-http1.1">Why do my Java app[let]s give me plain text |
| when I request an URL from an Apache server?</A> |
| </LI> |
| <LI><A HREF="#midi">How do I get Apache to send a MIDI file so the |
| browser can play it?</A> |
| </LI> |
| <LI><A HREF="#addlog">How do I add browsers and referrers to my logs?</A> |
| </LI> |
| <LI><A HREF="#set-servername">Why does accessing directories only work |
| when I include the trailing "/" |
| (<EM>e.g.</EM>, <SAMP>http://foo.domain.com/~user/</SAMP>) but |
| not when I omit it |
| (<EM>e.g.</EM>, <SAMP>http://foo.domain.com/~user</SAMP>)?</A> |
| </LI> |
| <LI><A HREF="#no-info-directives">Why doesn't mod_info list any |
| directives?</A> |
| </LI> |
| <LI><A HREF="#namevhost">I upgraded to Apache 1.3 and now my |
| virtual hosts don't work!</A> |
| </LI> |
| <LI><A HREF="#redhat-htm">I'm using RedHat Linux and my .htm files are |
| showing up as HTML source rather than being formatted!</A> |
| </LI> |
| <LI><A HREF="#htaccess-work">My <CODE>.htaccess</CODE> files are being |
| ignored.</A> |
| </LI> |
| </OL> |
| </LI> |
| |
| <LI><STRONG>F. Dynamic Content (CGI and SSI)</STRONG> |
| <OL> |
| <LI><A HREF="#CGIoutsideScriptAlias">How do I enable CGI execution |
| in directories other than the ScriptAlias?</A> |
| </LI> |
| <LI><A HREF="#premature-script-headers">What does it mean when my |
| CGIs fail with "<SAMP>Premature end of script |
| headers</SAMP>"?</A> |
| </LI> |
| <LI><A HREF="#POSTnotallowed">Why do I keep getting "Method Not |
| Allowed" for form POST requests?</A> |
| </LI> |
| <LI><A HREF="#nph-scripts">How can I get my script's output without |
| Apache buffering it? Why doesn't my server push work?</A> |
| </LI> |
| <LI><A HREF="#cgi-spec">Where can I find the "CGI |
| specification"?</A> |
| </LI> |
| <LI><A HREF="#fastcgi">Why isn't FastCGI included with Apache any |
| more?</A> |
| </LI> |
| <LI><A HREF="#ssi-part-i">How do I enable SSI (parsed HTML)?</A> |
| </LI> |
| <LI><A HREF="#ssi-part-ii">Why don't my parsed files get cached?</A> |
| </LI> |
| <LI><A HREF="#ssi-part-iii">How can I have my script output parsed?</A> |
| </LI> |
| <LI><A HREF="#ssi-part-iv">SSIs don't work for VirtualHosts and/or |
| user home directories</A> |
| </LI> |
| <LI><A HREF="#errordocssi">How can I use <CODE>ErrorDocument</CODE> |
| and SSI to simplify customized error messages?</A> |
| </LI> |
| <LI><A HREF="#remote-user-var">Why is the environment variable |
| <SAMP>REMOTE_USER</SAMP> not set?</A> |
| </LI> |
| </OL> |
| </LI> |
| <LI><STRONG>G. Authentication and Access Restrictions</STRONG> |
| <OL> |
| <LI><A HREF="#dnsauth">Why isn't restricting access by host or domain name |
| working correctly?</A> |
| </LI> |
| <LI><A HREF="#user-authentication">How do I set up Apache to require |
| a username and password to access certain documents?</A> |
| </LI> |
| <LI><A HREF="#remote-auth-only">How do I set up Apache to allow access |
| to certain documents only if a site is either a local site |
| <EM>or</EM> the user supplies a password and username?</A> |
| </LI> |
| <LI><A HREF="#authauthoritative">Why does my authentication give |
| me a server error?</A> |
| </LI> |
| <LI><A HREF="#auth-on-same-machine">Do I have to keep the (mSQL) |
| authentication information on the same machine?</A> |
| </LI> |
| <LI><A HREF="#msql-slow">Why is my mSQL authentication terribly slow?</A> |
| </LI> |
| <LI><A HREF="#passwdauth">Can I use my <SAMP>/etc/passwd</SAMP> file |
| for Web page authentication?</A> |
| </LI> |
| </OL> |
| </LI> |
| <LI><STRONG>H. URL Rewriting</STRONG> |
| <OL> |
| <LI><A HREF="#rewrite-more-config">Where can I find mod_rewrite rulesets |
| which already solve particular URL-related problems?</A> |
| </LI> |
| <LI><A HREF="#rewrite-article">Where can I find any published information |
| about URL-manipulations and mod_rewrite?</A> |
| </LI> |
| <LI><A HREF="#rewrite-complexity">Why is mod_rewrite so difficult to learn |
| and seems so complicated?</A> |
| </LI> |
| <LI><A HREF="#rewrite-dontwork">What can I do if my RewriteRules don't work |
| as expected?</A> |
| </LI> |
| <LI><A HREF="#rewrite-prefixdocroot">Why don't some of my URLs get |
| prefixed with DocumentRoot when using mod_rewrite?</A> |
| </LI> |
| <LI><A HREF="#rewrite-nocase">How can I make all my URLs case-insensitive |
| with mod_rewrite?</A> |
| </LI> |
| <LI><A HREF="#rewrite-virthost">Why are RewriteRules in my VirtualHost |
| parts ignored?</A> |
| </LI> |
| <LI><A HREF="#rewrite-envwhitespace">How can I use strings with whitespaces |
| in RewriteRule's ENV flag?</A> |
| </LI> |
| </OL> |
| </LI> |
| <LI><STRONG>I. Features</STRONG> |
| <OL> |
| <LI><A HREF="#proxy">Does or will Apache act as a Proxy server?</A> |
| </LI> |
| <LI><A HREF="#multiviews">What are "multiviews"?</A> |
| </LI> |
| <LI><A HREF="#putsupport">Why can't I publish to my Apache server |
| using PUT on Netscape Gold and other programs?</A> |
| </LI> |
| <LI><A HREF="#SSL-i">Why doesn't Apache include SSL?</A> |
| </LI> |
| </OL> |
| </LI> |
| </UL> |
| |
| <HR> |
| |
| <H2>The Answers</H2> |
| <H3>A. Background</H3> |
| <OL> |
| <LI><A NAME="what"> |
| <STRONG>What is Apache?</STRONG> |
| </A> |
| <P> |
| Apache was originally based on code and ideas found in the most |
| popular HTTP server of the time.. NCSA httpd 1.3 (early 1995). It has |
| since evolved into a far superior system which can rival (and probably |
| surpass) almost any other UNIX based HTTP server in terms of functionality, |
| efficiency and speed. |
| </P> |
| <P> |
| Since it began, it has been completely rewritten, and includes many new |
| features. Apache is, as of January 1997, the most popular WWW server on |
| the Internet, according to the |
| <A HREF="http://www.netcraft.com/Survey/">Netcraft Survey</A>. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="why"> |
| <STRONG>Why was Apache created?</STRONG> |
| </A> |
| <P> |
| To address the concerns of a group of WWW providers and part-time httpd |
| programmers that httpd didn't behave as they wanted it to behave. |
| Apache is an entirely volunteer effort, completely funded by its |
| members, not by commercial sales. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="relate"> |
| <STRONG>How does The Apache Group's work relate to other |
| server efforts, such as NCSA's?</STRONG> |
| </A> |
| <P> |
| We, of course, owe a great debt to NCSA and their programmers for |
| making the server Apache was based on. We now, however, have our own |
| server, and our project is mostly our own. The Apache Project is an |
| entirely independent venture. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="name"> |
| <STRONG>Why the name "Apache"?</STRONG> |
| </A> |
| <P> |
| A cute name which stuck. Apache is "<STRONG>A |
| PA</STRONG>t<STRONG>CH</STRONG>y server". It was |
| based on some existing code and a series of "patch files". |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="compare"> |
| <STRONG>OK, so how does Apache compare to other servers?</STRONG> |
| </A> |
| <P> |
| For an independent assessment, see |
| <A HREF="http://webcompare.internet.com/chart.html">Web Compare</A>'s |
| comparison chart. |
| </P> |
| <P> |
| Apache has been shown to be substantially faster than many other |
| free servers. Although certain commercial servers have claimed to |
| surpass Apache's speed (it has not been demonstrated that any of these |
| "benchmarks" are a good way of measuring WWW server speed at any |
| rate), we feel that it is better to have a mostly-fast free server |
| than an extremely-fast server that costs thousands of dollars. Apache |
| is run on sites that get millions of hits per day, and they have |
| experienced no performance difficulties. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="tested"> |
| <STRONG>How thoroughly tested is Apache?</STRONG> |
| </A> |
| <P> |
| Apache is run on over 1.2 million Internet servers (as of July 1998). It has |
| been tested thoroughly by both developers and users. The Apache Group |
| maintains rigorous standards before releasing new versions of their |
| server, and our server runs without a hitch on over one half of all |
| WWW servers available on the Internet. When bugs do show up, we |
| release patches and new versions as soon as they are available. |
| </P> |
| <P> |
| The Apache project's web site includes a page with a partial list of |
| <A HREF="http://www.apache.org/info/apache_users.html">sites running |
| Apache</A>. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="future"> |
| <STRONG>What are the future plans for Apache?</STRONG> |
| </A> |
| <P> |
| <UL> |
| <LI>to continue to be an "open source" no-charge-for-use HTTP server, |
| </LI> |
| <LI>to keep up with advances in HTTP protocol and web developments in |
| general, |
| </LI> |
| <LI>to collect suggestions for fixes/improvements from its users, |
| </LI> |
| <LI>to respond to needs of large volume providers as well as |
| occasional users. |
| </LI> |
| </UL> |
| <P></P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="support"> |
| <STRONG>Whom do I contact for support?</STRONG> |
| </A> |
| <P> |
| There is no official support for Apache. None of the developers want to |
| be swamped by a flood of trivial questions that can be resolved elsewhere. |
| Bug reports and suggestions should be sent <EM>via</EM> |
| <A HREF="http://www.apache.org/bug_report.html">the bug report page</A>. |
| Other questions should be directed to the |
| <A HREF="news:comp.infosystems.www.servers.unix" |
| >comp.infosystems.www.servers.unix</A> or <A HREF= |
| "news:comp.infosystems.www.servers.ms-windows" |
| >comp.infosystems.www.servers.ms-windows</A> |
| newsgroup (as appropriate for the platform you use), where some of the |
| Apache team lurk, in the company of many other httpd gurus who |
| should be able to help. |
| </P> |
| <P> |
| Commercial support for Apache is, however, available from a number |
| of third parties. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="more"> |
| <STRONG>Is there any more information available on |
| Apache?</STRONG> |
| </A> |
| <P> |
| Indeed there is. See the main |
| <A HREF="http://www.apache.org/">Apache web site</A>. |
| There is also a regular electronic publication called |
| <A HREF="http://www.apacheweek.com/" REL="Help"><CITE>Apache Week</CITE></A> |
| available. Links to relevant <CITE>Apache Week</CITE> articles are |
| included below where appropriate. There are also some |
| <A HREF="http://www.apache.org/info/apache_books.html" |
| >Apache-specific books</A> available. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="where"> |
| <STRONG>Where can I get Apache?</STRONG> |
| </A> |
| <P> |
| You can find out how to download the source for Apache at the |
| project's |
| <A HREF="http://www.apache.org/">main web page</A>. |
| </P> |
| <HR> |
| </LI> |
| </OL> |
| |
| <H3>B. General Technical Questions</H3> |
| <OL> |
| |
| <LI><A NAME="what2do"> |
| <STRONG>"Why can't I ...? Why won't ... work?" What to |
| do in case of problems</STRONG> |
| </A> |
| <P> |
| If you are having trouble with your Apache server software, you should |
| take the following steps: |
| </P> |
| <OL> |
| <LI><STRONG>Check the errorlog!</STRONG> |
| <P> |
| Apache tries to be helpful when it encounters a problem. In many |
| cases, it will provide some details by writing one or messages to |
| the server error log. Sometimes this is enough for you to diagnose |
| & fix the problem yourself (such as file permissions or the like). |
| The default location of the error log is |
| <SAMP>/usr/local/apache/logs/error_log</SAMP>, but see the |
| <A HREF="../mod/core.html#errorlog"><SAMP>ErrorLog</SAMP></A> |
| directive in your config files for the location on your server. |
| </P> |
| </LI> |
| <LI><STRONG>Check the |
| <A HREF="http://www.apache.org/docs/misc/FAQ.html">FAQ</A>!</STRONG> |
| <P> |
| The latest version of the Apache Frequently-Asked Questions list can |
| always be found at the main Apache web site. |
| </P> |
| </LI> |
| <LI><STRONG>Check the Apache bug database</STRONG> |
| <P> |
| Most problems that get reported to The Apache Group are recorded in |
| the |
| <A HREF="http://bugs.apache.org/">bug database</A>. |
| <EM><STRONG>Please</STRONG> check the existing reports, open |
| <STRONG>and</STRONG> closed, before adding one.</EM> If you find |
| that your issue has already been reported, please <EM>don't</EM> add |
| a "me, too" report. If the original report isn't closed |
| yet, we suggest that you check it periodically. You might also |
| consider contacting the original submitter, because there may be an |
| email exchange going on about the issue that isn't getting recorded |
| in the database. |
| </P> |
| </LI> |
| <LI><STRONG>Ask in the <SAMP>comp.infosystems.www.servers.unix</SAMP> |
| or <SAMP>comp.infosystems.www.servers.ms-windows</SAMP> USENET |
| newsgroup (as appropriate for the platform you use).</STRONG> |
| <P> |
| A lot of common problems never make it to the bug database because |
| there's already high Q&A traffic about them in the |
| <A HREF="news:comp.infosystems.www.servers.unix" |
| ><SAMP>comp.infosystems.www.servers.unix</SAMP></A> |
| newsgroup. Many Apache users, and some of the developers, can be |
| found roaming its virtual halls, so it is suggested that you seek |
| wisdom there. The chances are good that you'll get a faster answer |
| there than from the bug database, even if you <EM>don't</EM> see |
| your question already posted. |
| </P> |
| </LI> |
| <LI><STRONG>If all else fails, report the problem in the bug |
| database</STRONG> |
| <P> |
| If you've gone through those steps above that are appropriate and |
| have obtained no relief, then please <EM>do</EM> let The Apache |
| Group know about the problem by |
| <A HREF="http://www.apache.org/bug_report.html">logging a bug report</A>. |
| </P> |
| <P> |
| If your problem involves the server crashing and generating a core |
| dump, please include a backtrace (if possible). As an example, |
| </P> |
| <P> |
| <DL> |
| <DD><CODE># cd <EM>ServerRoot</EM><BR> |
| # dbx httpd core<BR> |
| (dbx) where</CODE> |
| </DD> |
| </DL> |
| <P></P> |
| <P> |
| (Substitute the appropriate locations for your |
| <SAMP>ServerRoot</SAMP> and your <SAMP>httpd</SAMP> and |
| <SAMP>core</SAMP> files. You may have to use <CODE>gdb</CODE> |
| instead of <CODE>dbx</CODE>.) |
| </P> |
| </LI> |
| </OL> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="compatible"> |
| <STRONG>How compatible is Apache with my existing NCSA 1.3 |
| setup?</STRONG> |
| </A> |
| <P> |
| Apache attempts to offer all the features and configuration options |
| of NCSA httpd 1.3, as well as many of the additional features found in |
| NCSA httpd 1.4 and NCSA httpd 1.5. |
| </P> |
| <P> |
| NCSA httpd appears to be moving toward adding experimental features |
| which are not generally required at the moment. Some of the experiments |
| will succeed while others will inevitably be dropped. The Apache |
| philosophy is to add what's needed as and when it is needed. |
| </P> |
| <P> |
| Friendly interaction between Apache and NCSA developers should ensure |
| that fundamental feature enhancements stay consistent between the two |
| servers for the foreseeable future. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="year2000"> |
| <STRONG>Is Apache Year 2000 compliant?</STRONG> |
| </A> |
| <P> |
| Yes, Apache is Year 2000 compliant. |
| </P> |
| <P> |
| Apache internally never stores years as two digits. |
| On the HTTP protocol level RFC1123-style addresses are generated |
| which is the only format a HTTP/1.1-compliant server should |
| generate. To be compatible with older applications Apache |
| recognizes ANSI C's <CODE>asctime()</CODE> and |
| RFC850-/RFC1036-style date formats, too. |
| The <CODE>asctime()</CODE> format uses four-digit years, |
| but the RFC850 and RFC1036 date formats only define a two-digit year. |
| If Apache sees such a date with a value less than 70 it assumes that |
| the century is <SAMP>20</SAMP> rather than <SAMP>19</SAMP>. |
| </P> |
| <P> |
| Although Apache is Year 2000 compliant, you may still get problems |
| if the underlying OS has problems with dates past year 2000 |
| (<EM>e.g.</EM>, OS calls which accept or return year numbers). |
| Most (UNIX) systems store dates internally as signed 32-bit integers |
| which contain the number of seconds since 1<SUP>st</SUP> January 1970, so |
| the magic boundary to worry about is the year 2038 and not 2000. |
| But modern operating systems shouldn't cause any trouble |
| at all. |
| </P> |
| <P> |
| Users of Apache 1.2.x should upgrade to a current version of Apache 1.3 |
| (see <A HREF="../new_features_1_3.html#misc">year-2000 improvements in |
| Apache 1.3</A> for details). |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="submit_patch"> |
| <STRONG>How do I submit a patch to the Apache Group?</STRONG></A> |
| <P> |
| The Apache Group encourages patches from outside developers. There |
| are 2 main "types" of patches: small bugfixes and general |
| improvements. Bugfixes should be submitting using the Apache <A |
| HREF="http://www.apache.org/bug_report.html">bug report page</A>. |
| Improvements, modifications, and additions should follow the |
| instructions below. |
| </P> |
| <P> |
| In general, the first course of action is to be a member of the |
| <SAMP>new-httpd@apache.org</SAMP> mailing list. This indicates to |
| the Group that you are closely following the latest Apache |
| developments. Your patch file should be generated using either |
| '<CODE>diff -c</CODE>' or '<CODE>diff -u</CODE>' against |
| the latest CVS tree. To submit your patch, send email to |
| <SAMP>new-httpd@apache.org</SAMP> with a <SAMP>Subject:</SAMP> line |
| that starts with <SAMP>[PATCH]</SAMP> and includes a general |
| description of the patch. In the body of the message, the patch |
| should be clearly described and then included at the end of the |
| message. If the patch-file is long, you can note a URL to the file |
| instead of the file itself. Use of MIME enclosures/attachments |
| should be avoided. |
| </P> |
| <P> |
| Be prepared to respond to any questions about your patches and |
| possibly defend your code. If your patch results in a lot of |
| discussion, you may be asked to submit an updated patch that |
| incorporate all changes and suggestions. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="domination"><STRONG>Why has Apache stolen my favourite site's |
| Internet address?</STRONG></A> |
| <P> |
| The simple answer is: "It hasn't." This misconception is usually |
| caused by the site in question having migrated to the Apache Web |
| server software, but not having migrated the site's content yet. When |
| Apache is installed, the default page that gets installed tells the |
| Webmaster the installation was successful. The expectation is that |
| this default page will be replaced with the site's real content. |
| If it doesn't, complain to the Webmaster, not to the Apache project -- |
| we just make the software and aren't responsible for what people |
| do (or don't do) with it. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="apspam"><STRONG>Why am I getting spam mail from the |
| Apache site?</STRONG></A> |
| <P> |
| The short answer is: "You aren't." Usually when someone thinks the |
| Apache site is originating spam, it's because they've traced the |
| spam to a Web site, and the Web site says it's using Apache. See the |
| <A HREF="#domination">previous FAQ entry</A> for more details on this |
| phenomenon. |
| </P> |
| <P> |
| No marketing spam originates from the Apache site. The only mail |
| that comes from the site goes only to addresses that have been |
| <EM>requested</EM> to receive the mail. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="redist"><STRONG>May I include the Apache software on a |
| CD or other package I'm distributing?</STRONG></A> |
| <P> |
| The detailed answer to this question can be found in the |
| Apache license, which is included in the Apache distribution in |
| the file <CODE>LICENSE</CODE>. You can also find it on the Web at |
| <SAMP><<A HREF="http://www.apache.org/LICENSE.txt" |
| >http://www.apache.org/LICENSE.txt</A>></SAMP>. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="zoom"> |
| <STRONG>What's the best hardware/operating system/... How do |
| I get the most out of my Apache Web server?</STRONG> |
| </A> |
| <P> |
| Check out Dean Gaudet's |
| <A HREF="http://www.apache.org/docs/misc/perf-tuning.html" |
| >performance tuning page</A>. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="regex"> |
| <STRONG>What are "regular expressions"?</STRONG></A> |
| <P> |
| Regular expressions are a way of describing a pattern - for example, "all |
| the words that begin with the letter A" or "every 10-digit phone number" |
| or even "Every sentence with two commas in it, and no capital letter Q". |
| Regular expressions (aka "regexp"s) are useful in Apache because they |
| let you apply certain attributes against collections of files or resources |
| in very flexible ways - for example, all .gif and .jpg files under |
| any "images" directory could be written as /.*\/images\/.*[jpg|gif]/. |
| </P> |
| <P> |
| The best overview around is probably the one which comes with Perl. |
| We implement a simple subset of Perl's regexp support, but it's |
| still a good way to learn what they mean. You can start by going |
| to the <A |
| HREF="http://www.perl.com/CPAN-local/doc/manual/html/pod/perlre.html#Version_8_Regular_Expresions" |
| >CPAN page on regular expressions</A>, and branching out from |
| there. |
| </P> |
| <HR> |
| </LI> |
| </OL> |
| |
| <H3>C. Building Apache</H3> |
| <OL> |
| |
| <LI><A NAME="bind8.1"> |
| <STRONG>Why do I get an error about an undefined reference to |
| "<SAMP>__inet_ntoa</SAMP>" or other |
| <SAMP>__inet_*</SAMP> symbols?</STRONG> |
| </A> |
| <P> |
| If you have installed <A HREF="http://www.isc.org/bind.html">BIND-8</A> |
| then this is normally due to a conflict between your include files |
| and your libraries. BIND-8 installs its include files and libraries |
| <CODE>/usr/local/include/</CODE> and <CODE>/usr/local/lib/</CODE>, while |
| the resolver that comes with your system is probably installed in |
| <CODE>/usr/include/</CODE> and <CODE>/usr/lib/</CODE>. If |
| your system uses the header files in <CODE>/usr/local/include/</CODE> |
| before those in <CODE>/usr/include/</CODE> but you do not use the new |
| resolver library, then the two versions will conflict. |
| </P> |
| <P> |
| To resolve this, you can either make sure you use the include files |
| and libraries that came with your system or make sure to use the |
| new include files and libraries. Adding <CODE>-lbind</CODE> to the |
| <CODE>EXTRA_LDFLAGS</CODE> line in your <SAMP>Configuration</SAMP> |
| file, then re-running <SAMP>Configure</SAMP>, should resolve the |
| problem. (Apache versions 1.2.* and earlier use |
| <CODE>EXTRA_LFLAGS</CODE> instead.) |
| </P> |
| <P> |
| <STRONG>Note:</STRONG>As of BIND 8.1.1, the bind libraries and files are |
| installed under <SAMP>/usr/local/bind</SAMP> by default, so you |
| should not run into this problem. Should you want to use the bind |
| resolvers you'll have to add the following to the respective lines: |
| </P> |
| <P> |
| <DL> |
| <DD><CODE>EXTRA_CFLAGS=-I/usr/local/bind/include |
| <BR> |
| EXTRA_LDFLAGS=-L/usr/local/bind/lib |
| <BR> |
| EXTRA_LIBS=-lbind</CODE> |
| </DD> |
| </DL> |
| <P></P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="cantbuild"> |
| <STRONG>Why won't Apache compile with my system's |
| <SAMP>cc</SAMP>?</STRONG> |
| </A> |
| <P> |
| If the server won't compile on your system, it is probably due to one |
| of the following causes: |
| </P> |
| <UL> |
| <LI><STRONG>The <SAMP>Configure</SAMP> script doesn't recognize your system |
| environment.</STRONG> |
| <BR> |
| This might be either because it's completely unknown or because |
| the specific environment (include files, OS version, <EM>et |
| cetera</EM>) isn't explicitly handled. If this happens, you may |
| need to port the server to your OS yourself. |
| </LI> |
| <LI><STRONG>Your system's C compiler is garbage.</STRONG> |
| <BR> |
| Some operating systems include a default C compiler that is either |
| not ANSI C-compliant or suffers from other deficiencies. The usual |
| recommendation in cases like this is to acquire, install, and use |
| <SAMP>gcc</SAMP>. |
| </LI> |
| <LI><STRONG>Your <SAMP>include</SAMP> files may be confused.</STRONG> |
| <BR> |
| In some cases, we have found that a compiler installation or system |
| upgrade has left the C header files in an inconsistent state. Make |
| sure that your include directory tree is in sync with the compiler and |
| the operating system. |
| </LI> |
| <LI><STRONG>Your operating system or compiler may be out of |
| revision.</STRONG> |
| <BR> |
| Software vendors (including those that develop operating systems) |
| issue new releases for a reason; sometimes to add functionality, but |
| more often to fix bugs that have been discovered. Try upgrading |
| your compiler and/or your operating system. |
| </LI> |
| </UL> |
| <P> |
| The Apache Group tests the ability to build the server on many |
| different platforms. Unfortunately, we can't test all of the OS |
| platforms there are. If you have verified that none of the above |
| issues is the cause of your problem, and it hasn't been reported |
| before, please submit a |
| <A HREF="http://www.apache.org/bug_report.html">problem report</A>. |
| Be sure to include <EM>complete</EM> details, such as the compiler |
| & OS versions and exact error messages. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="linuxiovec"> |
| <STRONG>Why do I get complaints about redefinition |
| of "<CODE>struct iovec</CODE>" when |
| compiling under Linux?</STRONG> |
| </A> |
| <P> |
| This is a conflict between your C library includes and your kernel |
| includes. You need to make sure that the versions of both are matched |
| properly. There are two workarounds, either one will solve the problem: |
| </P> |
| <P> |
| <UL> |
| <LI>Remove the definition of <CODE>struct iovec</CODE> from your C |
| library includes. It is located in <CODE>/usr/include/sys/uio.h</CODE>. |
| <STRONG>Or,</STRONG> |
| </LI> |
| <LI>Add <CODE>-DNO_WRITEV</CODE> to the <CODE>EXTRA_CFLAGS</CODE> |
| line in your <SAMP>Configuration</SAMP> and reconfigure/rebuild. |
| This hurts performance and should only be used as a last resort. |
| </LI> |
| </UL> |
| <P></P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="broken-gcc"><STRONG>I'm using gcc and I get some |
| compilation errors, what is wrong?</STRONG></A> |
| <P> |
| GCC parses your system header files and produces a modified subset which |
| it uses for compiling. This behaviour ties GCC tightly to the version |
| of your operating system. So, for example, if you were running IRIX 5.3 |
| when you built GCC and then upgrade to IRIX 6.2 later, you will have to |
| rebuild GCC. Similarly for Solaris 2.4, 2.5, or 2.5.1 when you upgrade |
| to 2.6. Sometimes you can type "gcc -v" and it will tell you the version |
| of the operating system it was built against. |
| </P> |
| <P> |
| If you fail to do this, then it is very likely that Apache will fail |
| to build. One of the most common errors is with <CODE>readv</CODE>, |
| <CODE>writev</CODE>, or <CODE>uio.h</CODE>. This is <STRONG>not</STRONG> a |
| bug with Apache. You will need to re-install GCC. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="glibc-crypt"> |
| <STRONG>I'm using RedHat Linux 5.0, or some other |
| <SAMP>glibc</SAMP>-based Linux system, and I get errors with the |
| <CODE>crypt</CODE> function when I attempt to build Apache 1.2.</STRONG> |
| </A> |
| |
| <P> |
| <SAMP>glibc</SAMP> puts the <CODE>crypt</CODE> function into a separate |
| library. Edit your <CODE>src/Configuration</CODE> file and set this: |
| </P> |
| <DL> |
| <DD><CODE>EXTRA_LIBS=-lcrypt</CODE> |
| </DD> |
| </DL> |
| <P> |
| Then re-run <SAMP>src/Configure</SAMP> and re-execute the make. |
| </P> |
| <HR> |
| </LI> |
| |
| </OL> |
| |
| |
| <H3>D. Error Log Messages and Problems Starting Apache</H3> |
| <OL> |
| |
| <LI><A NAME="setgid"> |
| <STRONG>Why do I get "<SAMP>setgid: Invalid |
| argument</SAMP>" at startup?</STRONG> |
| </A> |
| <P> |
| Your |
| <A HREF="../mod/core.html#group"><SAMP>Group</SAMP></A> |
| directive (probably in <SAMP>conf/httpd.conf</SAMP>) needs to name a |
| group that actually exists in the <SAMP>/etc/group</SAMP> file (or |
| your system's equivalent). This problem is also frequently seen when |
| a negative number is used in the <CODE>Group</CODE> directive |
| (<EM>e.g.</EM>, "<CODE>Group #-1</CODE>"). Using a group name |
| -- not group number -- found in your system's group database should |
| solve this problem in all cases. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="nodelay"> |
| <STRONG>Why am I getting "<SAMP>httpd: could not set socket |
| option TCP_NODELAY</SAMP>" in my error log?</STRONG> |
| </A> |
| <P> |
| This message almost always indicates that the client disconnected |
| before Apache reached the point of calling <CODE>setsockopt()</CODE> |
| for the connection. It shouldn't occur for more than about 1% of the |
| requests your server handles, and it's advisory only in any case. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="peerreset"> |
| <STRONG>Why am I getting "<SAMP>connection reset by |
| peer</SAMP>" in my error log?</STRONG> |
| </A> |
| <P> |
| This is a normal message and nothing about which to be alarmed. It simply |
| means that the client canceled the connection before it had been |
| completely set up - such as by the end-user pressing the "Stop" |
| button. People's patience being what it is, sites with response-time |
| problems or slow network links may experiences this more than |
| high-capacity ones or those with large pipes to the network. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="wheres-the-dump"> |
| <STRONG>The errorlog says Apache dumped core, but where's the dump |
| file?</STRONG> |
| </A> |
| <P> |
| In Apache version 1.2, the error log message |
| about dumped core includes the directory where the dump file should be |
| located. However, many Unixes do not allow a process that has |
| called <CODE>setuid()</CODE> to dump core for security reasons; |
| the typical Apache setup has the server started as root to bind to |
| port 80, after which it changes UIDs to a non-privileged user to |
| serve requests. |
| </P> |
| <P> |
| Dealing with this is extremely operating system-specific, and may |
| require rebuilding your system kernel. Consult your operating system |
| documentation or vendor for more information about whether your system |
| does this and how to bypass it. If there <EM>is</EM> a documented way |
| of bypassing it, it is recommended that you bypass it only for the |
| <SAMP>httpd</SAMP> server process if possible. |
| </P> |
| <P> |
| The canonical location for Apache's core-dump files is the |
| <A HREF="../mod/core.html#serverroot">ServerRoot</A> |
| directory. As of Apache version 1.3, the location can be set <EM>via</EM> |
| the |
| <A HREF="../mod/core.html#coredumpdirectory" |
| ><SAMP>CoreDumpDirectory</SAMP></A> |
| directive to a different directory. Make sure that this directory is |
| writable by the user the server runs as (as opposed to the user the server |
| is <EM>started</EM> as). |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="linux-shmget"> |
| <STRONG>When I run it under Linux I get "shmget: |
| function not found", what should I do?</STRONG> |
| </A> |
| <P> |
| Your kernel has been built without SysV IPC support. You will have |
| to rebuild the kernel with that support enabled (it's under the |
| "General Setup" submenu). Documentation for kernel |
| building is beyond the scope of this FAQ; you should consult the <A |
| HREF="http://www.linuxhq.com/HOWTO/Kernel-HOWTO.html" >Kernel |
| HOWTO</A>, or the documentation provided with your distribution, or |
| a <A HREF="http://www.linuxhq.com/HOWTO/META-FAQ.html" >Linux |
| newsgroup/mailing list</A>. As a last-resort workaround, you can |
| comment out the <CODE>#define USE_SHMGET_SCOREBOARD</CODE> |
| definition in the <SAMP>LINUX</SAMP> section of |
| <SAMP>src/conf.h</SAMP> and rebuild the server (prior to 1.3b4, |
| simply removing <CODE>#define HAVE_SHMGET</CODE> would have |
| sufficed). This will produce a server which is slower and less |
| reliable. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="nfslocking"> |
| <STRONG>Server hangs, or fails to start, and/or error log |
| fills with "<SAMP>fcntl: F_SETLKW: No record locks |
| available</SAMP>" or similar messages</STRONG> |
| </A> |
| |
| <P> |
| These are symptoms of a fine locking problem, which usually means that |
| the server is trying to use a synchronization file on an NFS filesystem. |
| </P> |
| <P> |
| Because of its parallel-operation model, the Apache Web server needs to |
| provide some form of synchronization when accessing certain resources. |
| One of these synchronization methods involves taking out locks on a file, |
| which means that the filesystem whereon the lockfile resides must support |
| locking. In many cases this means it <EM>can't</EM> be kept on an |
| NFS-mounted filesystem. |
| </P> |
| <P> |
| To cause the Web server to work around the NFS locking limitations, include |
| a line such as the following in your server configuration files: |
| </P> |
| <DL> |
| <DD><CODE>LockFile /var/run/apache-lock</CODE> |
| </DD> |
| </DL> |
| <P> |
| The directory should not be generally writable (<EM>e.g.</EM>, don't use |
| <SAMP>/var/tmp</SAMP>). |
| See the <A HREF="../mod/core.html#lockfile"><SAMP>LockFile</SAMP></A> |
| documentation for more information. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="aixccbug"><STRONG>Why am I getting "<SAMP>Expected |
| </Directory> but saw </Directory></SAMP>" when |
| I try to start Apache?</STRONG></A> |
| <P> |
| This is a known problem with certain versions of the AIX C compiler. |
| IBM are working on a solution, and the issue is being tracked by |
| <A HREF="http://bugs.apache.org/index/full/2312">problem report #2312</A>. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="redhat"> |
| <STRONG>I'm using RedHat Linux and I have problems with httpd |
| dying randomly or not restarting properly</STRONG> |
| </A> |
| |
| <P> |
| RedHat Linux versions 4.x (and possibly earlier) RPMs contain |
| various nasty scripts which do not stop or restart Apache properly. |
| These can affect you even if you're not running the RedHat supplied |
| RPMs. |
| </P> |
| <P> |
| If you're using the default install then you're probably running |
| Apache 1.1.3, which is outdated. From RedHat's ftp site you can |
| pick up a more recent RPM for Apache 1.2.x. This will solve one of |
| the problems. |
| </P> |
| <P> |
| If you're using a custom built Apache rather than the RedHat RPMs |
| then you should <CODE>rpm -e apache</CODE>. In particular you want |
| the mildly broken <CODE>/etc/logrotate.d/apache</CODE> script to be |
| removed, and you want the broken <CODE>/etc/rc.d/init.d/httpd</CODE> |
| (or <CODE>httpd.init</CODE>) script to be removed. The latter is |
| actually fixed by the apache-1.2.5 RPMs but if you're building your |
| own Apache then you probably don't want the RedHat files. |
| </P> |
| <P> |
| We can't stress enough how important it is for folks, <EM>especially |
| vendors</EM> to follow the <A HREF="../stopping.html">stopping Apache |
| directions</A> given in our documentation. In RedHat's defense, |
| the broken scripts were necessary with Apache 1.1.x because the |
| Linux support in 1.1.x was very poor, and there were various race |
| conditions on all platforms. None of this should be necessary with |
| Apache 1.2 and later. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="stopping"> |
| <STRONG>I upgraded from an Apache version earlier |
| than 1.2.0 and suddenly I have problems with Apache dying randomly |
| or not restarting properly</STRONG> |
| </A> |
| |
| <P> |
| You should read <A HREF="#redhat">the previous note</A> about |
| problems with RedHat installations. It is entirely likely that your |
| installation has start/stop/restart scripts which were built for |
| an earlier version of Apache. Versions earlier than 1.2.0 had |
| various race conditions that made it necessary to use |
| <CODE>kill -9</CODE> at times to take out all the httpd servers. |
| But that should not be necessary any longer. You should follow |
| the <A HREF="../stopping.html">directions on how to stop |
| and restart Apache</A>. |
| </P> |
| <P>As of Apache 1.3 there is a script |
| <CODE>src/support/apachectl</CODE> which, after a bit of |
| customization, is suitable for starting, stopping, and restarting |
| your server. |
| </P> |
| <HR> |
| </LI> |
| |
| </OL> |
| |
| <H3>E. Configuration Questions</H3> |
| <OL> |
| |
| <LI><A NAME="fdlim"> |
| <STRONG>Why can't I run more than <<EM>n</EM>> |
| virtual hosts?</STRONG> |
| </A> |
| <P> |
| You are probably running into resource limitations in your |
| operating system. The most common limitation is the |
| <EM>per</EM>-process limit on <STRONG>file descriptors</STRONG>, |
| which is almost always the cause of problems seen when adding |
| virtual hosts. Apache often does not give an intuitive error |
| message because it is normally some library routine (such as |
| <CODE>gethostbyname()</CODE>) which needs file descriptors and |
| doesn't complain intelligibly when it can't get them. |
| </P> |
| <P> |
| Each log file requires a file descriptor, which means that if you are |
| using separate access and error logs for each virtual host, each |
| virtual host needs two file descriptors. Each |
| <A HREF="../mod/core.html#listen"><SAMP>Listen</SAMP></A> |
| directive also needs a file descriptor. |
| </P> |
| <P> |
| Typical values for <<EM>n</EM>> that we've seen are in |
| the neighborhood of 128 or 250. When the server bumps into the file |
| descriptor limit, it may dump core with a SIGSEGV, it might just |
| hang, or it may limp along and you'll see (possibly meaningful) errors |
| in the error log. One common problem that occurs when you run into |
| a file descriptor limit is that CGI scripts stop being executed |
| properly. |
| </P> |
| <P> |
| As to what you can do about this: |
| </P> |
| <OL> |
| <LI>Reduce the number of |
| <A HREF="../mod/core.html#listen"><SAMP>Listen</SAMP></A> |
| directives. If there are no other servers running on the machine |
| on the same port then you normally don't |
| need any Listen directives at all. By default Apache listens to |
| all addresses on port 80. |
| </LI> |
| <LI>Reduce the number of log files. You can use |
| <A HREF="../mod/mod_log_config.html"><SAMP>mod_log_config</SAMP></A> |
| to log all requests to a single log file while including the name |
| of the virtual host in the log file. You can then write a |
| script to split the logfile into separate files later if |
| necessary. Such a script is provided with the Apache 1.3 distribution |
| in the <SAMP>src/support/split-logfile</SAMP> file. |
| </LI> |
| <LI>Increase the number of file descriptors available to the server |
| (see your system's documentation on the <CODE>limit</CODE> or |
| <CODE>ulimit</CODE> commands). For some systems, information on |
| how to do this is available in the |
| <A HREF="perf.html">performance hints</A> page. There is a specific |
| note for <A HREF="#freebsd-setsize">FreeBSD</A> below. |
| <P> |
| For Windows 95, try modifying your <SAMP>C:\CONFIG.SYS</SAMP> file to |
| include a line like |
| </P> |
| <DL> |
| <DD><CODE>FILES=300</CODE> |
| </DD> |
| </DL> |
| <P> |
| Remember that you'll need to reboot your Windows 95 system in order |
| for the new value to take effect. |
| </P> |
| </LI> |
| <LI>"Don't do that" - try to run with fewer virtual hosts |
| </LI> |
| <LI>Spread your operation across multiple server processes (using |
| <A HREF="../mod/core.html#listen"><SAMP>Listen</SAMP></A> |
| for example, but see the first point) and/or ports. |
| </LI> |
| </OL> |
| <P> |
| Since this is an operating-system limitation, there's not much else |
| available in the way of solutions. |
| </P> |
| <P> |
| As of 1.2.1 we have made attempts to work around various limitations |
| involving running with many descriptors. |
| <A HREF="descriptors.html">More information is available.</A> |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="freebsd-setsize"> |
| <STRONG>Can I increase <SAMP>FD_SETSIZE</SAMP> on FreeBSD?</STRONG> |
| </A> |
| <P> |
| On versions of FreeBSD before 3.0, the <SAMP>FD_SETSIZE</SAMP> define |
| defaults to 256. This means that you will have trouble usefully using |
| more than 256 file descriptors in Apache. This can be increased, but |
| doing so can be tricky. |
| </P> |
| <P> |
| If you are using a version prior to 2.2, you need to recompile your |
| kernel with a larger <SAMP>FD_SETSIZE</SAMP>. This can be done by adding a |
| line such as: |
| </P> |
| <DL> |
| <DD><CODE>options FD_SETSIZE <EM>nnn</EM></CODE> |
| </DD> |
| </DL> |
| <P> |
| to your kernel config file. Starting at version 2.2, this is no |
| longer necessary. |
| </P> |
| <P> |
| If you are using a version of 2.1-stable from after 1997/03/10 or |
| 2.2 or 3.0-current from before 1997/06/28, there is a limit in |
| the resolver library that prevents it from using more file descriptors |
| than what <SAMP>FD_SETSIZE</SAMP> is set to when libc is compiled. To |
| increase this, you have to recompile libc with a higher |
| <SAMP>FD_SETSIZE</SAMP>. |
| </P> |
| <P> |
| In FreeBSD 3.0, the default <SAMP>FD_SETSIZE</SAMP> has been increased to |
| 1024 and the above limitation in the resolver library |
| has been removed. |
| </P> |
| <P> |
| After you deal with the appropriate changes above, you can increase |
| the setting of <SAMP>FD_SETSIZE</SAMP> at Apache compilation time |
| by adding "<SAMP>-DFD_SETSIZE=<EM>nnn</EM></SAMP>" to the |
| <SAMP>EXTRA_CFLAGS</SAMP> line in your <SAMP>Configuration</SAMP> |
| file. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="errordoc401"> |
| <STRONG>Why doesn't my <CODE>ErrorDocument 401</CODE> work?</STRONG> |
| </A> |
| <P> |
| You need to use it with a URL in the form |
| "<SAMP>/foo/bar</SAMP>" and not one with a method and |
| hostname such as "<SAMP>http://host/foo/bar</SAMP>". See the |
| <A HREF="../mod/core.html#errordocument"><SAMP>ErrorDocument</SAMP></A> |
| documentation for details. This was incorrectly documented in the past. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="cookies1"> |
| <STRONG>Why does Apache send a cookie on every response?</STRONG> |
| </A> |
| <P> |
| Apache does <EM>not</EM> automatically send a cookie on every |
| response, unless you have re-compiled it with the |
| <A HREF="../mod/mod_usertrack.html"><SAMP>mod_usertrack</SAMP></A> |
| module, and specifically enabled it with the |
| <A HREF="../mod/mod_usertrack.html#cookietracking" |
| ><SAMP>CookieTracking</SAMP></A> |
| directive. |
| This module has been in Apache since version 1.2. |
| This module may help track users, and uses cookies to do this. If |
| you are not using the data generated by <SAMP>mod_usertrack</SAMP>, do |
| not compile it into Apache. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="cookies2"> |
| <STRONG>Why don't my cookies work, I even compiled in |
| <SAMP>mod_cookies</SAMP>? |
| </STRONG> |
| </A> |
| <P> |
| Firstly, you do <EM>not</EM> need to compile in |
| <SAMP>mod_cookies</SAMP> in order for your scripts to work (see the |
| <A HREF="#cookies1">previous question</A> |
| for more about <SAMP>mod_cookies</SAMP>). Apache passes on your |
| <SAMP>Set-Cookie</SAMP> header fine, with or without this module. If |
| cookies do not work it will be because your script does not work |
| properly or your browser does not use cookies or is not set-up to |
| accept them. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="jdk1-and-http1.1"> |
| <STRONG>Why do my Java app[let]s give me plain text when I request |
| an URL from an Apache server?</STRONG> |
| </A> |
| <P> |
| As of version 1.2, Apache is an HTTP/1.1 (HyperText Transfer Protocol |
| version 1.1) server. This fact is reflected in the protocol version |
| that's included in the response headers sent to a client when |
| processing a request. Unfortunately, low-level Web access classes |
| included in the Java Development Kit (JDK) version 1.0.2 expect to see |
| the version string "HTTP/1.0" and do not correctly interpret |
| the "HTTP/1.1" value Apache is sending (this part of the |
| response is a declaration of what the server can do rather than a |
| declaration of the dialect of the response). The result |
| is that the JDK methods do not correctly parse the headers, and |
| include them with the document content by mistake. |
| </P> |
| <P> |
| This is definitely a bug in the JDK 1.0.2 foundation classes from Sun, |
| and it has been fixed in version 1.1. However, the classes in |
| question are part of the virtual machine environment, which means |
| they're part of the Web browser (if Java-enabled) or the Java |
| environment on the client system - so even if you develop |
| <EM>your</EM> classes with a recent JDK, the eventual users might |
| encounter the problem. |
| The classes involved are replaceable by vendors implementing the |
| Java virtual machine environment, and so even those that are based |
| upon the 1.0.2 version may not have this problem. |
| </P> |
| <P> |
| In the meantime, a workaround is to tell |
| Apache to "fake" an HTTP/1.0 response to requests that come |
| from the JDK methods; this can be done by including a line such as the |
| following in your server configuration files: |
| </P> |
| <P> |
| <DL> |
| <DD><CODE>BrowserMatch Java1.0 force-response-1.0 |
| <BR> |
| BrowserMatch JDK/1.0 force-response-1.0</CODE> |
| </DD> |
| </DL> |
| <P></P> |
| <P> |
| More information about this issue can be found in the |
| <A HREF="http://www.apache.org/info/jdk-102.html" |
| ><CITE>Java and HTTP/1.1</CITE></A> |
| page at the Apache web site. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="midi"> |
| <STRONG>How do I get Apache to send a MIDI file so the browser can |
| play it?</STRONG> |
| </A> |
| <P> |
| Even though the registered MIME type for MIDI files is |
| <SAMP>audio/midi</SAMP>, some browsers are not set up to recognize it |
| as such; instead, they look for <SAMP>audio/x-midi</SAMP>. There are |
| two things you can do to address this: |
| </P> |
| <OL> |
| <LI>Configure your browser to treat documents of type |
| <SAMP>audio/midi</SAMP> correctly. This is the type that Apache |
| sends by default. This may not be workable, however, if you have |
| many client installations to change, or if some or many of the |
| clients are not under your control. |
| </LI> |
| <LI>Instruct Apache to send a different <SAMP>Content-type</SAMP> |
| header for these files by adding the following line to your server's |
| configuration files: |
| <P> |
| <DL> |
| <DD><CODE>AddType audio/x-midi .mid .midi .kar</CODE> |
| </DD> |
| </DL> |
| <P></P> |
| <P> |
| Note that this may break browsers that <EM>do</EM> recognize the |
| <SAMP>audio/midi</SAMP> MIME type unless they're prepared to also |
| handle <SAMP>audio/x-midi</SAMP> the same way. |
| </P> |
| </LI> |
| </OL> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="addlog"> |
| <STRONG>How do I add browsers and referrers to my logs?</STRONG> |
| </A> |
| <P> |
| Apache provides a couple of different ways of doing this. The |
| recommended method is to compile the |
| <A HREF="../mod/mod_log_config.html"><SAMP>mod_log_config</SAMP></A> |
| module into your configuration and use the |
| <A HREF="../mod/mod_log_config.html#customlog"><SAMP>CustomLog</SAMP></A> |
| directive. |
| </P> |
| <P> |
| You can either log the additional information in files other than your |
| normal transfer log, or you can add them to the records already being |
| written. For example: |
| </P> |
| <P> |
| <CODE> |
| CustomLog logs/access_log "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-Agent}i\"" |
| </CODE> |
| </P> |
| <P> |
| This will add the values of the <SAMP>User-agent:</SAMP> and |
| <SAMP>Referer:</SAMP> headers, which indicate the client and the |
| referring page, respectively, to the end of each line in the access |
| log. |
| </P> |
| <P> |
| You may want to check out the <CITE>Apache Week</CITE> article |
| entitled: |
| "<A HREF="http://www.apacheweek.com/features/logfiles" REL="Help" |
| ><CITE>Gathering Visitor Information: Customizing Your |
| Logfiles</CITE></A>". |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="set-servername"> |
| <STRONG>Why does accessing directories only work when I include |
| the trailing "/" |
| (<EM>e.g.</EM>, <SAMP>http://foo.domain.com/~user/</SAMP>) |
| but not when I omit it |
| (<EM>e.g.</EM>, <SAMP>http://foo.domain.com/~user</SAMP>)?</STRONG> |
| </A> |
| <P> |
| When you access a directory without a trailing "/", Apache needs |
| to send what is called a redirect to the client to tell it to |
| add the trailing slash. If it did not do so, relative URLs would |
| not work properly. When it sends the redirect, it needs to know |
| the name of the server so that it can include it in the redirect. |
| There are two ways for Apache to find this out; either it can guess, |
| or you can tell it. If your DNS is configured correctly, it can |
| normally guess without any problems. If it is not, however, then |
| you need to tell it. |
| </P> |
| <P> |
| Add a <A HREF="../mod/core.html#servername">ServerName</A> directive |
| to the config file to tell it what the domain name of the server is. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="no-info-directives"> |
| <STRONG>Why doesn't mod_info list any directives?</STRONG> |
| </A> |
| <P> |
| The <A HREF="../mod/mod_info.html"><SAMP>mod_info</SAMP></A> |
| module allows you to use a Web browser to see how your server is |
| configured. Among the information it displays is the list modules and |
| their configuration directives. The "current" values for |
| the directives are not necessarily those of the running server; they |
| are extracted from the configuration files themselves at the time of |
| the request. If the files have been changed since the server was last |
| reloaded, the display will will not match the values actively in use. |
| If the files and the path to the files are not readable by the user as |
| which the server is running (see the |
| <A HREF="../mod/core.html#user"><SAMP>User</SAMP></A> |
| directive), then <SAMP>mod_info</SAMP> cannot read them in order to |
| list their values. An entry <EM>will</EM> be made in the error log in |
| this event, however. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="namevhost"> |
| <STRONG>I upgraded to Apache 1.3 and now my virtual hosts don't |
| work!</STRONG> |
| </A> |
| <P> |
| In versions of Apache prior to 1.3b2, there was a lot of confusion |
| regarding address-based virtual hosts and (HTTP/1.1) name-based |
| virtual hosts, and the rules concerning how the server processed |
| <SAMP><VirtualHost></SAMP> definitions were very complex and not |
| well documented. |
| </P> |
| <P> |
| Apache 1.3b2 introduced a new directive, |
| <A HREF="http://www.apache.org/docs/mod/core.html#namevirtualhost" |
| ><SAMP>NameVirtualHost</SAMP></A>, |
| which simplifies the rules quite a bit. However, changing the rules |
| like this means that your existing name-based |
| <SAMP><VirtualHost></SAMP> containers probably won't work |
| correctly immediately following the upgrade. |
| </P> |
| <P> |
| To correct this problem, add the following line to the beginning of |
| your server configuration file, before defining any virtual hosts: |
| </P> |
| <DL> |
| <DD><CODE>NameVirtualHost <EM>n.n.n.n</EM></CODE> |
| </DD> |
| </DL> |
| <P> |
| Replace the "<SAMP>n.n.n.n</SAMP>" with the IP address to |
| which the name-based virtual host names resolve; if you have multiple |
| name-based hosts on multiple addresses, repeat the directive for each |
| address. |
| </P> |
| <P> |
| Make sure that your name-based <SAMP><VirtualHost></SAMP> blocks |
| contain <SAMP>ServerName</SAMP> and possibly <SAMP>ServerAlias</SAMP> |
| directives so Apache can be sure to tell them apart correctly. |
| </P> |
| <P> |
| Please see the |
| <A HREF="http://www.apache.org/docs/vhosts/">Apache |
| Virtual Host documentation</A> for further details about configuration. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="redhat-htm"> |
| <STRONG>I'm using RedHat Linux and my .htm files are showing |
| up as HTML source rather than being formatted!</STRONG> |
| </A> |
| |
| <P> |
| RedHat messed up and forgot to put a content type for <CODE>.htm</CODE> |
| files into <CODE>/etc/mime.types</CODE>. Edit <CODE>/etc/mime.types</CODE>, |
| find the line containing <CODE>html</CODE> and add <CODE>htm</CODE> to it. |
| Then restart your httpd server: |
| </P> |
| <DL> |
| <DD><CODE>kill -HUP `cat /var/run/httpd.pid`</CODE> |
| </DD> |
| </DL> |
| <P> |
| Then <STRONG>clear your browsers' caches</STRONG>. (Many browsers won't |
| re-examine the content type after they've reloaded a page.) |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="htaccess-work"> |
| <STRONG>My <CODE>.htaccess</CODE> files are being ignored.</STRONG></A> |
| <P> |
| This is almost always due to your <A HREF="../mod/core.html#allowoverride"> |
| AllowOverride</A> directive being set incorrectly for the directory in |
| question. If it is set to <CODE>None</CODE> then .htaccess files will |
| not even be looked for. If you do have one that is set, then be certain |
| it covers the directory you are trying to use the .htaccess file in. |
| This is normally accomplished by ensuring it is inside the proper |
| <A HREF="../mod/core.html#directory">Directory</A> container. |
| </P> |
| <HR> |
| </LI> |
| </OL> |
| |
| <H3>F. Dynamic Content (CGI and SSI)</H3> |
| <OL> |
| |
| <LI><A NAME="CGIoutsideScriptAlias"> |
| <STRONG>How do I enable CGI execution in directories other than |
| the ScriptAlias?</STRONG> |
| </A> |
| <P> |
| Apache recognizes all files in a directory named as a |
| <A HREF="../mod/mod_alias.html#scriptalias"><SAMP>ScriptAlias</SAMP></A> |
| as being eligible for execution rather than processing as normal |
| documents. This applies regardless of the file name, so scripts in a |
| ScriptAlias directory don't need to be named |
| "<SAMP>*.cgi</SAMP>" or "<SAMP>*.pl</SAMP>" or |
| whatever. In other words, <EM>all</EM> files in a ScriptAlias |
| directory are scripts, as far as Apache is concerned. |
| </P> |
| <P> |
| To persuade Apache to execute scripts in other locations, such as in |
| directories where normal documents may also live, you must tell it how |
| to recognize them - and also that it's okay to execute them. For |
| this, you need to use something like the |
| <A HREF="../mod/mod_mime.html#addhandler"><SAMP>AddHandler</SAMP></A> |
| directive. |
| </P> |
| <P> |
| <OL> |
| <LI>In an appropriate section of your server configuration files, add |
| a line such as |
| <P> |
| <DL> |
| <DD><CODE>AddHandler cgi-script .cgi</CODE> |
| </DD> |
| </DL> |
| <P></P> |
| <P> |
| The server will then recognize that all files in that location (and |
| its logical descendants) that end in "<SAMP>.cgi</SAMP>" |
| are script files, not documents. |
| </P> |
| </LI> |
| <LI>Make sure that the directory location is covered by an |
| <A HREF="../mod/core.html#options"><SAMP>Options</SAMP></A> |
| declaration that includes the <SAMP>ExecCGI</SAMP> option. |
| </LI> |
| </OL> |
| <P></P> |
| <P> |
| In some situations, you might not want to actually |
| allow all files named "<SAMP>*.cgi</SAMP>" to be executable. |
| Perhaps all you want is to enable a particular file in a normal directory to |
| be executable. This can be alternatively accomplished |
| <EM>via</EM> <A HREF="../mod/mod_rewrite.html"><SAMP>mod_rewrite</SAMP></A> |
| and the following steps: |
| </P> |
| <P> |
| <OL> |
| <LI>Locally add to the corresponding <SAMP>.htaccess</SAMP> file a ruleset |
| similar to this one: |
| <P> |
| <DL> |
| <DD><CODE>RewriteEngine on |
| <BR> |
| RewriteBase /~foo/bar/ |
| <BR> |
| RewriteRule ^quux\.cgi$ - [T=application/x-httpd-cgi]</CODE> |
| </DD> |
| </DL> |
| <P></P> |
| </LI> |
| <LI>Make sure that the directory location is covered by an |
| <A HREF="../mod/core.html#options"><SAMP>Options</SAMP></A> |
| declaration that includes the <SAMP>ExecCGI</SAMP> and |
| <SAMP>FollowSymLinks</SAMP> option. |
| </LI> |
| </OL> |
| <P></P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="premature-script-headers"> |
| <STRONG>What does it mean when my CGIs fail with |
| "<SAMP>Premature end of script headers</SAMP>"?</STRONG> |
| </A> |
| <P> |
| It means just what it says: the server was expecting a complete set of |
| HTTP headers (one or more followed by a blank line), and didn't get |
| them. |
| </P> |
| <P> |
| The most common cause of this problem is the script dying before |
| sending the complete set of headers, or possibly any at all, to the |
| server. To see if this is the case, try running the script standalone |
| from an interactive session, rather than as a script under the server. |
| If you get error messages, this is almost certainly the cause of the |
| "premature end of script headers" message. |
| </P> |
| <P> |
| The second most common cause of this (aside from people not |
| outputting the required headers at all) is a result of an interaction |
| with Perl's output buffering. To make Perl flush its buffers |
| after each output statement, insert the following statements around |
| the <CODE>print</CODE> or <CODE>write</CODE> statements that send your |
| HTTP headers: |
| </P> |
| <P> |
| <DL> |
| <DD><CODE>{<BR> |
| local ($oldbar) = $|;<BR> |
| $cfh = select (STDOUT);<BR> |
| $| = 1;<BR> |
| #<BR> |
| # print your HTTP headers here<BR> |
| #<BR> |
| $| = $oldbar;<BR> |
| select ($cfh);<BR> |
| }</CODE> |
| </DD> |
| </DL> |
| <P></P> |
| <P> |
| This is generally only necessary when you are calling external |
| programs from your script that send output to stdout, or if there will |
| be a long delay between the time the headers are sent and the actual |
| content starts being emitted. To maximize performance, you should |
| turn buffer-flushing back <EM>off</EM> (with <CODE>$| = 0</CODE> or the |
| equivalent) after the statements that send the headers, as displayed |
| above. |
| </P> |
| <P> |
| If your script isn't written in Perl, do the equivalent thing for |
| whatever language you <EM>are</EM> using (<EM>e.g.</EM>, for C, call |
| <CODE>fflush()</CODE> after writing the headers). |
| </P> |
| <P> |
| Another cause for the "premature end of script headers" |
| message are the RLimitCPU and RLimitMEM directives. You may |
| get the message if the CGI script was killed due to a |
| resource limit. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="POSTnotallowed"> |
| <STRONG>Why do I keep getting "Method Not Allowed" for |
| form POST requests?</STRONG> |
| </A> |
| <P> |
| This is almost always due to Apache not being configured to treat the |
| file you are trying to POST to as a CGI script. You can not POST |
| to a normal HTML file; the operation has no meaning. See the FAQ |
| entry on <A HREF="#CGIoutsideScriptAlias">CGIs outside ScriptAliased |
| directories</A> for details on how to configure Apache to treat the |
| file in question as a CGI. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="nph-scripts"> |
| <STRONG>How can I get my script's output without Apache buffering |
| it? Why doesn't my server push work?</STRONG> |
| </A> |
| <P> |
| As of Apache 1.3, CGI scripts are essentially not buffered. Every time |
| your script does a "flush" to output data, that data gets relayed on to |
| the client. Some scripting languages, for example Perl, have their own |
| buffering for output - this can be disabled by setting the <CODE>$|</CODE> |
| special variable to 1. Of course this does increase the overall number |
| of packets being transmitted, which can result in a sense of slowness for |
| the end user. |
| </P> |
| <P>Prior to 1.3, you needed to use "nph-" scripts to accomplish |
| non-buffering. Today, the only difference between nph scripts and |
| normal scripts is that nph scripts require the full HTTP headers to |
| be sent. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="cgi-spec"> |
| <STRONG>Where can I find the "CGI specification"?</STRONG> |
| </A> |
| <P> |
| The Common Gateway Interface (CGI) specification can be found at |
| the original NCSA site |
| <<A HREF="http://hoohoo.ncsa.uiuc.edu/cgi/interface.html"> |
| <SAMP>http://hoohoo.ncsa.uiuc.edu/cgi/interface.html</SAMP></A>>. |
| This version hasn't been updated since 1995, and there have been |
| some efforts to update it. |
| </P> |
| <P> |
| A new draft is being worked on with the intent of making it an informational |
| RFC; you can find out more about this project at |
| <<A HREF="http://web.golux.com/coar/cgi/" |
| ><SAMP>http://web.golux.com/coar/cgi/</SAMP></A>>. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="fastcgi"> |
| <STRONG>Why isn't FastCGI included with Apache any more?</STRONG> |
| </A> |
| <P> |
| The simple answer is that it was becoming too difficult to keep the |
| version being included with Apache synchronized with the master copy |
| at the |
| <A HREF="http://www.fastcgi.com/" |
| >FastCGI web site</A>. When a new version of Apache was released, the |
| version of the FastCGI module included with it would soon be out of date. |
| </P> |
| <P> |
| You can still obtain the FastCGI module for Apache from the master |
| FastCGI web site. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="ssi-part-i"> |
| <STRONG>How do I enable SSI (parsed HTML)?</STRONG> |
| </A> |
| <P> |
| SSI (an acronym for Server-Side Include) directives allow static HTML |
| documents to be enhanced at run-time (<EM>e.g.</EM>, when delivered to |
| a client by Apache). The format of SSI directives is covered |
| in the <A HREF="../mod/mod_include.html">mod_include manual</A>; |
| suffice it to say that Apache supports not only SSI but |
| xSSI (eXtended SSI) directives. |
| </P> |
| <P> |
| Processing a document at run-time is called <EM>parsing</EM> it; hence |
| the term "parsed HTML" sometimes used for documents that |
| contain SSI instructions. Parsing tends to be <EM>extremely</EM> |
| resource-consumptive, and is not enabled by default. It can also |
| interfere with the cachability of your documents, which can put a |
| further load on your server. (see the |
| <A HREF="#ssi-part-ii">next question</A> for more information about this.) |
| </P> |
| <P> |
| To enable SSI processing, you need to |
| </P> |
| <UL> |
| <LI>Build your server with the |
| <A HREF="../mod/mod_include.html"><SAMP>mod_include</SAMP></A> |
| module. This is normally compiled in by default. |
| </LI> |
| <LI>Make sure your server configuration files have an |
| <A HREF="../mod/core.html#options"><SAMP>Options</SAMP></A> |
| directive which permits <SAMP>Includes</SAMP>. |
| </LI> |
| <LI>Make sure that the directory where you want the SSI documents to |
| live is covered by the "server-parsed" content handler, |
| either explicitly or in some ancestral location. That can be done |
| with the following |
| <A HREF="../mod/mod_mime.html#addhandler"><SAMP>AddHandler</SAMP></A> |
| directive: |
| <P> |
| <DL> |
| <DD><CODE>AddHandler server-parsed .shtml</CODE> |
| </DD> |
| </DL> |
| <P></P> |
| <P> |
| This indicates that all files ending in ".shtml" in that |
| location (or its descendants) should be parsed. Note that using |
| ".html" will cause all normal HTML files to be parsed, |
| which may put an inordinate load on your server. |
| </P> |
| </LI> |
| </UL> |
| <P> |
| For additional information, see the <CITE>Apache Week</CITE> article on |
| <A HREF="http://www.apacheweek.com/features/ssi" REL="Help" |
| ><CITE>Using Server Side Includes</CITE></A>. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="ssi-part-ii"> |
| <STRONG>Why don't my parsed files get cached?</STRONG> |
| </A> |
| <P> |
| Since the server is performing run-time processing of your SSI |
| directives, which may change the content shipped to the client, it |
| can't know at the time it starts parsing what the final size of the |
| result will be, or whether the parsed result will always be the same. |
| This means that it can't generate <SAMP>Content-Length</SAMP> or |
| <SAMP>Last-Modified</SAMP> headers. Caches commonly work by comparing |
| the <SAMP>Last-Modified</SAMP> of what's in the cache with that being |
| delivered by the server. Since the server isn't sending that header |
| for a parsed document, whatever's doing the caching can't tell whether |
| the document has changed or not - and so fetches it again to be on the |
| safe side. |
| </P> |
| <P> |
| You can work around this in some cases by causing an |
| <SAMP>Expires</SAMP> header to be generated. (See the |
| <A HREF="../mod/mod_expires.html" REL="Help"><SAMP>mod_expires</SAMP></A> |
| documentation for more details.) Another possibility is to use the |
| <A HREF="../mod/mod_include.html#xbithack" REL="Help" |
| ><SAMP>XBitHack Full</SAMP></A> |
| mechanism, which tells Apache to send (under certain circumstances |
| detailed in the XBitHack directive description) a |
| <SAMP>Last-Modified</SAMP> header based upon the last modification |
| time of the file being parsed. Note that this may actually be lying |
| to the client if the parsed file doesn't change but the SSI-inserted |
| content does; if the included content changes often, this can result |
| in stale copies being cached. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="ssi-part-iii"> |
| <STRONG>How can I have my script output parsed?</STRONG> |
| </A> |
| <P> |
| So you want to include SSI directives in the output from your CGI |
| script, but can't figure out how to do it? |
| The short answer is "you can't." This is potentially |
| a security liability and, more importantly, it can not be cleanly |
| implemented under the current server API. The best workaround |
| is for your script itself to do what the SSIs would be doing. |
| After all, it's generating the rest of the content. |
| </P> |
| <P> |
| This is a feature The Apache Group hopes to add in the next major |
| release after 1.3. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="ssi-part-iv"> |
| <STRONG>SSIs don't work for VirtualHosts and/or |
| user home directories.</STRONG> |
| </A> |
| <P> |
| This is almost always due to having some setting in your config file that |
| sets "Options Includes" or some other setting for your DocumentRoot |
| but not for other directories. If you set it inside a Directory |
| section, then that setting will only apply to that directory. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="errordocssi"> |
| <STRONG>How can I use <CODE>ErrorDocument</CODE> |
| and SSI to simplify customized error messages?</STRONG> |
| </A> |
| <P> |
| Have a look at <A HREF="custom_errordocs.html">this document</A>. |
| It shows in example form how you can a combination of XSSI and |
| negotiation to tailor a set of <CODE>ErrorDocument</CODE>s to your |
| personal taste, and returning different internationalized error |
| responses based on the client's native language. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="remote-user-var"> |
| <STRONG>Why is the environment variable |
| <SAMP>REMOTE_USER</SAMP> not set?</STRONG> |
| </A> |
| <P> |
| This variable is set and thus available in SSI or CGI scripts <STRONG>if and |
| only if</STRONG> the requested document was protected by access |
| authentication. For an explanation on how to implement these restrictions, |
| see |
| <A HREF="http://www.apacheweek.com/"><CITE>Apache Week</CITE></A>'s |
| articles on |
| <A HREF="http://www.apacheweek.com/features/userauth" |
| ><CITE>Using User Authentication</CITE></A> |
| or |
| <A HREF="http://www.apacheweek.com/features/dbmauth" |
| ><CITE>DBM User Authentication</CITE></A>. |
| </P> |
| <P> |
| Hint: When using a CGI script to receive the data of a HTML <SAMP>FORM</SAMP> |
| notice that protecting the document containing the <SAMP>FORM</SAMP> is not |
| sufficient to provide <SAMP>REMOTE_USER</SAMP> to the CGI script. You have |
| to protect the CGI script, too. Or alternatively only the CGI script (then |
| authentication happens only after filling out the form). |
| </P> |
| <HR> |
| </LI> |
| |
| </OL> |
| |
| <H3>G. Authentication and Access Restrictions</H3> |
| <OL> |
| |
| <LI><A NAME="dnsauth"> |
| <STRONG>Why isn't restricting access by host or domain name |
| working correctly?</STRONG> |
| </A> |
| <P> |
| Two of the most common causes of this are: |
| </P> |
| <OL> |
| <LI><STRONG>An error, inconsistency, or unexpected mapping in the DNS |
| registration</STRONG> |
| <BR> |
| This happens frequently: your configuration restricts access to |
| <SAMP>Host.FooBar.Com</SAMP>, but you can't get in from that host. |
| The usual reason for this is that <SAMP>Host.FooBar.Com</SAMP> is |
| actually an alias for another name, and when Apache performs the |
| address-to-name lookup it's getting the <EM>real</EM> name, not |
| <SAMP>Host.FooBar.Com</SAMP>. You can verify this by checking the |
| reverse lookup yourself. The easiest way to work around it is to |
| specify the correct host name in your configuration. |
| </LI> |
| <LI><STRONG>Inadequate checking and verification in your |
| configuration of Apache</STRONG> |
| <BR> |
| If you intend to perform access checking and restriction based upon |
| the client's host or domain name, you really need to configure |
| Apache to double-check the origin information it's supplied. You do |
| this by adding the <SAMP>-DMAXIMUM_DNS</SAMP> clause to the |
| <SAMP>EXTRA_CFLAGS</SAMP> definition in your |
| <SAMP>Configuration</SAMP> file. For example: |
| <P> |
| <DL> |
| <DD><CODE>EXTRA_CFLAGS=-DMAXIMUM_DNS</CODE> |
| </DD> |
| </DL> |
| <P></P> |
| <P> |
| This will cause Apache to be very paranoid about making sure a |
| particular host address is <EM>really</EM> assigned to the name it |
| claims to be. Note that this <EM>can</EM> incur a significant |
| performance penalty, however, because of all the name resolution |
| requests being sent to a nameserver. |
| </P> |
| </LI> |
| </OL> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="user-authentication"> |
| <STRONG>How do I set up Apache to require a username and |
| password to access certain documents?</STRONG> |
| </A> |
| <P> |
| There are several ways to do this; some of the more popular |
| ones are to use the <A HREF="../mod/mod_auth.html">mod_auth</A>, |
| <A HREF="../mod/mod_auth_db.html">mod_auth_db</A>, or |
| <A HREF="../mod/mod_auth_dbm.html">mod_auth_dbm</A> modules. |
| </P> |
| <P> |
| For an explanation on how to implement these restrictions, see |
| <A HREF="http://www.apacheweek.com/"><CITE>Apache Week</CITE></A>'s |
| articles on |
| <A HREF="http://www.apacheweek.com/features/userauth" |
| ><CITE>Using User Authentication</CITE></A> |
| or |
| <A HREF="http://www.apacheweek.com/features/dbmauth" |
| ><CITE>DBM User Authentication</CITE></A>. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="remote-auth-only"> |
| <STRONG>How do I set up Apache to allow access to certain |
| documents only if a site is either a local site <EM>or</EM> |
| the user supplies a password and username?</STRONG> |
| </A> |
| <P> |
| Use the <A HREF="../mod/core.html#satisfy">Satisfy</A> directive, |
| in particular the <CODE>Satisfy Any</CODE> directive, to require |
| that only one of the access restrictions be met. For example, |
| adding the following configuration to a <SAMP>.htaccess</SAMP> |
| or server configuration file would restrict access to people who |
| either are accessing the site from a host under domain.com or |
| who can supply a valid username and password: |
| </P> |
| <P> |
| <DL> |
| <DD><CODE>deny from all |
| <BR> |
| allow from .domain.com |
| <BR> |
| AuthType Basic |
| <BR> |
| AuthUserFile /usr/local/apache/conf/htpasswd.users |
| <BR> |
| AuthName "special directory" |
| <BR> |
| require valid-user |
| <BR> |
| satisfy any</CODE> |
| </DD> |
| </DL> |
| <P></P> |
| <P> |
| See the <A HREF="#user-authentication">user authentication</A> |
| question and the <A HREF="../mod/mod_access.html">mod_access</A> |
| module for details on how the above directives work. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="authauthoritative"> |
| <STRONG>Why does my authentication give me a server error?</STRONG> |
| </A> |
| <P> |
| Under normal circumstances, the Apache access control modules will |
| pass unrecognized user IDs on to the next access control module in |
| line. Only if the user ID is recognized and the password is validated |
| (or not) will it give the usual success or "authentication |
| failed" messages. |
| </P> |
| <P> |
| However, if the last access module in line 'declines' the validation |
| request (because it has never heard of the user ID or because it is not |
| configured), the <SAMP>http_request</SAMP> handler will give one of |
| the following, confusing, errors: |
| </P> |
| <UL> |
| <LI><SAMP>check access</SAMP> |
| </LI> |
| <LI><SAMP>check user. No user file?</SAMP> |
| </LI> |
| <LI><SAMP>check access. No groups file?</SAMP> |
| </LI> |
| </UL> |
| <P> |
| This does <EM>not</EM> mean that you have to add an |
| '<SAMP>AuthUserFile /dev/null</SAMP>' line as some magazines suggest! |
| </P> |
| <P> |
| The solution is to ensure that at least the last module is authoritative |
| and <STRONG>CONFIGURED</STRONG>. By default, <SAMP>mod_auth</SAMP> is |
| authoritative and will give an OK/Denied, but only if it is configured |
| with the proper <SAMP>AuthUserFile</SAMP>. Likewise, if a valid group |
| is required. (Remember that the modules are processed in the reverse |
| order from that in which they appear in your compile-time |
| <SAMP>Configuration</SAMP> file.) |
| </P> |
| <P> |
| A typical situation for this error is when you are using the |
| <SAMP>mod_auth_dbm</SAMP>, <SAMP>mod_auth_msql</SAMP>, |
| <SAMP>mod_auth_mysql</SAMP>, <SAMP>mod_auth_anon</SAMP> or |
| <SAMP>mod_auth_cookie</SAMP> modules on their own. These are by |
| default <STRONG>not</STRONG> authoritative, and this will pass the |
| buck on to the (non-existent) next authentication module when the |
| user ID is not in their respective database. Just add the appropriate |
| '<SAMP><EM>XXX</EM>Authoritative yes</SAMP>' line to the configuration. |
| </P> |
| <P> |
| In general it is a good idea (though not terribly efficient) to have the |
| file-based <SAMP>mod_auth</SAMP> a module of last resort. This allows |
| you to access the web server with a few special passwords even if the |
| databases are down or corrupted. This does cost a |
| file open/seek/close for each request in a protected area. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="auth-on-same-machine"> |
| <STRONG>Do I have to keep the (mSQL) authentication information |
| on the same machine?</STRONG> |
| </A> |
| <P> |
| Some organizations feel very strongly about keeping the authentication |
| information on a different machine than the webserver. With the |
| <SAMP>mod_auth_msql</SAMP>, <SAMP>mod_auth_mysql</SAMP>, and other SQL |
| modules connecting to (R)DBMses this is quite possible. Just configure |
| an explicit host to contact. |
| </P> |
| <P> |
| Be aware that with mSQL and Oracle, opening and closing these database |
| connections is very expensive and time consuming. You might want to |
| look at the code in the <SAMP>auth_*</SAMP> modules and play with the |
| compile time flags to alleviate this somewhat, if your RDBMS licences |
| allow for it. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="msql-slow"> |
| <STRONG>Why is my mSQL authentication terribly slow?</STRONG> |
| </A> |
| <P> |
| You have probably configured the Host by specifying a FQHN, |
| and thus the <SAMP>libmsql</SAMP> will use a full blown TCP/IP socket |
| to talk to the database, rather than a fast internal device. The |
| <SAMP>libmsql</SAMP>, the mSQL FAQ, and the <SAMP>mod_auth_msql</SAMP> |
| documentation warn you about this. If you have to use different |
| hosts, check out the <SAMP>mod_auth_msql</SAMP> code for |
| some compile time flags which might - or might not - suit you. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="passwdauth"> |
| <STRONG>Can I use my <SAMP>/etc/passwd</SAMP> file |
| for Web page authentication?</STRONG> |
| </A> |
| <P> |
| Yes, you can - but it's a <STRONG>very bad idea</STRONG>. Here are |
| some of the reasons: |
| </P> |
| <UL> |
| <LI>The Web technology provides no governors on how often or how |
| rapidly password (authentication failure) retries can be made. That |
| means that someone can hammer away at your system's |
| <SAMP>root</SAMP> password using the Web, using a dictionary or |
| similar mass attack, just as fast as the wire and your server can |
| handle the requests. Most operating systems these days include |
| attack detection (such as <EM>n</EM> failed passwords for the same |
| account within <EM>m</EM> seconds) and evasion (breaking the |
| connection, disabling the account under attack, disabling |
| <EM>all</EM> logins from that source, <EM>et cetera</EM>), but the |
| Web does not. |
| </LI> |
| <LI>An account under attack isn't notified (unless the server is |
| heavily modified); there's no "You have 19483 login |
| failures" message when the legitimate owner logs in. |
| </LI> |
| <LI>Without an exhaustive and error-prone examination of the server |
| logs, you can't tell whether an account has been compromised. |
| Detecting that an attack has occurred, or is in progress, is fairly |
| obvious, though - <EM>if</EM> you look at the logs. |
| </LI> |
| <LI>Web authentication passwords (at least for Basic authentication) |
| generally fly across the wire, and through intermediate proxy |
| systems, in what amounts to plain text. "O'er the net we |
| go/Caching all the way;/O what fun it is to surf/Giving my password |
| away!" |
| </LI> |
| <LI>Since HTTP is stateless, information about the authentication is |
| transmitted <EM>each and every time</EM> a request is made to the |
| server. Essentially, the client caches it after the first |
| successful access, and transmits it without asking for all |
| subsequent requests to the same server. |
| </LI> |
| <LI>It's relatively trivial for someone on your system to put up a |
| page that will steal the cached password from a client's cache |
| without them knowing. Can you say "password grabber"? |
| </LI> |
| </UL> |
| <P> |
| If you still want to do this in light of the above disadvantages, the |
| method is left as an exercise for the reader. It'll void your Apache |
| warranty, though, and you'll lose all accumulated UNIX guru points. |
| </P> |
| <HR> |
| </LI> |
| </OL> |
| |
| <H3>H. URL Rewriting</H3> |
| <OL> |
| |
| <LI><A NAME="rewrite-more-config"> |
| <STRONG>Where can I find mod_rewrite rulesets which already solve |
| particular URL-related problems?</STRONG> |
| </A> |
| <P> |
| There is a collection of |
| <A HREF="http://www.engelschall.com/pw/apache/rewriteguide/" |
| >Practical Solutions for URL-Manipulation</A> |
| where you can |
| find all typical solutions the author of |
| <A HREF="../mod/mod_rewrite.html"><SAMP>mod_rewrite</SAMP></A> |
| currently knows of. If you have more |
| interesting rulesets which solve particular problems not currently covered in |
| this document, send it to |
| <A HREF="mailto:rse@apache.org">Ralf S. Engelschall</A> |
| for inclusion. The |
| other webmasters will thank you for avoiding the reinvention of the wheel. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="rewrite-article"> |
| <STRONG>Where can I find any published information about |
| URL-manipulations and mod_rewrite?</STRONG> |
| </A> |
| <P> |
| There is an article from |
| <A HREF="mailto:rse@apache.org" |
| >Ralf S. Engelschall</A> |
| about URL-manipulations based on |
| <A HREF="../mod/mod_rewrite.html"><SAMP>mod_rewrite</SAMP></A> |
| in the "iX Multiuser Multitasking Magazin" issue #12/96. The |
| german (original) version |
| can be read online at |
| <<A HREF="http://www.heise.de/ix/artikel/9612149/" |
| >http://www.heise.de/ix/artikel/9612149/</A>>, |
| the English (translated) version can be found at |
| <<A HREF="http://www.heise.de/ix/artikel/E/9612149/" |
| >http://www.heise.de/ix/artikel/E/9612149/</A>>. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="rewrite-complexity"> |
| <STRONG>Why is mod_rewrite so difficult to learn and seems so |
| complicated?</STRONG> |
| </A> |
| <P> |
| Hmmm... there are a lot of reasons. First, mod_rewrite itself is a powerful |
| module which can help you in really <STRONG>all</STRONG> aspects of URL |
| rewriting, so it can be no trivial module per definition. To accomplish |
| its hard job it uses software leverage and makes use of a powerful regular |
| expression |
| library by Henry Spencer which is an integral part of Apache since its |
| version 1.2. And regular expressions itself can be difficult to newbies, |
| while providing the most flexible power to the advanced hacker. |
| </P> |
| <P> |
| On the other hand mod_rewrite has to work inside the Apache API environment |
| and needs to do some tricks to fit there. For instance the Apache API as of |
| 1.x really was not designed for URL rewriting at the <TT>.htaccess</TT> |
| level of processing. Or the problem of multiple rewrites in sequence, which |
| is also not handled by the API per design. To provide this features |
| mod_rewrite has to do some special (but API compliant!) handling which leads |
| to difficult processing inside the Apache kernel. While the user usually |
| doesn't see anything of this processing, it can be difficult to find |
| problems when some of your RewriteRules seem not to work. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="rewrite-dontwork"> |
| <STRONG>What can I do if my RewriteRules don't work as expected? |
| </STRONG> |
| </A> |
| <P> |
| Use "<SAMP>RewriteLog somefile</SAMP>" and |
| "<SAMP>RewriteLogLevel 9</SAMP>" and have a precise look at the |
| steps the rewriting engine performs. This is really the only one and best |
| way to debug your rewriting configuration. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="rewrite-prefixdocroot"><STRONG>Why don't some of my URLs |
| get prefixed with DocumentRoot when using mod_rewrite?</STRONG> |
| </A> |
| <P> |
| If the rule starts with <SAMP>/somedir/...</SAMP> make sure that |
| really no <SAMP>/somedir</SAMP> exists on the filesystem if you |
| don't want to lead the URL to match this directory, <EM>i.e.</EM>, |
| there must be no root directory named <SAMP>somedir</SAMP> on the |
| filesystem. Because if there is such a directory, the URL will not |
| get prefixed with DocumentRoot. This behaviour looks ugly, but is |
| really important for some other aspects of URL rewriting. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="rewrite-nocase"> |
| <STRONG>How can I make all my URLs case-insensitive with mod_rewrite? |
| </STRONG> |
| </A> |
| <P> |
| You can't! The reason is: First, case translations for arbitrary |
| length URLs cannot be done <EM>via</EM> regex patterns and |
| corresponding substitutions. One need a per-character pattern like |
| sed/Perl <SAMP>tr|..|..|</SAMP> feature. Second, just making URLs |
| always upper or lower case will not resolve the complete problem of |
| case-INSENSITIVE URLs, because actually the URLs had to be rewritten |
| to the correct case-variant residing on the filesystem because in |
| later processing Apache needs to access the file. And Unix |
| filesystem is always case-SENSITIVE. |
| </P> |
| <P> |
| But there is a module named <CODE>mod_speling.c</CODE> (yes, it is named |
| this way!) out there on the net. Try this one. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="rewrite-virthost"> |
| <STRONG> Why are RewriteRules in my VirtualHost parts ignored?</STRONG> |
| </A> |
| <P> |
| Because you have to enable the engine for every virtual host explicitly due |
| to security concerns. Just add a "RewriteEngine on" to your |
| virtual host configuration parts. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="rewrite-envwhitespace"> |
| <STRONG> How can I use strings with whitespaces in RewriteRule's ENV |
| flag?</STRONG> |
| </A> |
| <P> |
| There is only one ugly solution: You have to surround the complete |
| flag argument by quotation marks (<SAMP>"[E=...]"</SAMP>). Notice: |
| The argument to quote here is not the argument to the E-flag, it is |
| the argument of the Apache config file parser, <EM>i.e.</EM>, the |
| third argument of the RewriteRule here. So you have to write |
| <SAMP>"[E=any text with whitespaces]"</SAMP>. |
| </P> |
| <HR> |
| </LI> |
| </OL> |
| |
| <H3>I. Features</H3> |
| <OL> |
| |
| <LI><A NAME="proxy"> |
| <STRONG>Does or will Apache act as a Proxy server?</STRONG> |
| </A> |
| <P> |
| Apache version 1.1 and above comes with a |
| <A HREF="../mod/mod_proxy.html">proxy module</A>. |
| If compiled in, this will make Apache act as a caching-proxy server. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="multiviews"> |
| <STRONG>What are "multiviews"?</STRONG> |
| </A> |
| <P> |
| "Multiviews" is the general name given to the Apache |
| server's ability to provide language-specific document variants in |
| response to a request. This is documented quite thoroughly in the |
| <A HREF="../content-negotiation.html" REL="Help">content negotiation</A> |
| description page. In addition, <CITE>Apache Week</CITE> carried an |
| article on this subject entitled |
| "<A HREF="http://www.apacheweek.com/features/negotiation" REL="Help" |
| ><CITE>Content Negotiation Explained</CITE></A>". |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="putsupport"> |
| <STRONG>Why can't I publish to my Apache server using PUT on |
| Netscape Gold and other programs?</STRONG> |
| </A> |
| <P> |
| Because you need to install and configure a script to handle |
| the uploaded files. This script is often called a "PUT" handler. |
| There are several available, but they may have security problems. |
| Using FTP uploads may be easier and more secure, at least for now. |
| For more information, see the <CITE>Apache Week</CITE> article |
| <A HREF="http://www.apacheweek.com/features/put" |
| ><CITE>Publishing Pages with PUT</CITE></A>. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="SSL-i"> |
| <STRONG>Why doesn't Apache include SSL?</STRONG> |
| </A> |
| <P> |
| SSL (Secure Socket Layer) data transport requires encryption, and many |
| governments have restrictions upon the import, export, and use of |
| encryption technology. If Apache included SSL in the base package, |
| its distribution would involve all sorts of legal and bureaucratic |
| issues, and it would no longer be freely available. Also, some of |
| the technology required to talk to current clients using SSL is |
| patented by <A HREF="http://www.rsa.com/">RSA Data Security</A>, |
| who restricts its use without a license. |
| </P> |
| <P> |
| Some SSL implementations of Apache are available, however; see the |
| "<A HREF="http://www.apache.org/related_projects.html" |
| >related projects</A>" |
| page at the main Apache web site. |
| </P> |
| <P> |
| You can find out more about this topic in the <CITE>Apache Week</CITE> |
| article about |
| <A HREF="http://www.apacheweek.com/features/ssl" REL="Help" |
| ><CITE>Apache and Secure Transactions</CITE></A>. |
| </P> |
| <HR> |
| </LI> |
| </OL> |
| <!-- Don't forget to add HR tags at the end of each list item.. --> |
| |
| <!--#include virtual="footer.html" --> |
| </BODY> |
| </HTML> |
