mirror of
https://github.com/apache/httpd.git
synced 2025-05-19 02:21:09 +03:00
e1c24f8406
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@78088 13f79535-47bb-0310-9956-ffa450edef68
1226 lines
43 KiB
HTML
1226 lines
43 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>Apache Server Frequently Asked Questions</TITLE>
|
|
</HEAD>
|
|
|
|
<BODY>
|
|
<!--#include virtual="header.html" -->
|
|
<H1>Apache Server Frequently Asked Questions</H1>
|
|
<P>
|
|
$Revision: 1.50 $ ($Date: 1997/05/04 14:43:08 $)
|
|
</P>
|
|
<P>
|
|
The latest version of this FAQ is always available from the main
|
|
Apache web site, at
|
|
<<A
|
|
HREF="http://www.apache.org/docs/misc/FAQ"
|
|
REL="Help"
|
|
><SAMP>http://www.apache.org/docs/misc/FAQ</SAMP></A>>.
|
|
</P>
|
|
<!-- Notes about changes: -->
|
|
<!-- - If adding a relative link to another part of the -->
|
|
<!-- documentation, *do* include the ".html" portion. There's a -->
|
|
<!-- good chance that the user will be reading the documentation -->
|
|
<!-- on his own system, which may not be configured for -->
|
|
<!-- multiviews. Leave off the ".html" extension for absolute -->
|
|
<!-- links to sites which are known to run multiviews (e.g., -->
|
|
<!-- apache.org or apacheweek.com). -->
|
|
<!-- - When adding items, make sure they're put in the right place -->
|
|
<!-- - verify that the numbering matches up. -->
|
|
<!-- - Don't 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? -->
|
|
<!-- - How do I add browsers and referrers to my logs? -->
|
|
<!-- - How do I setup an access restriction so that people from -->
|
|
<!-- this domain don't have to authenticate, and all others can -->
|
|
<!-- do so via a username and password? -->
|
|
<!-- - Why do I get "send lost connection" messages in my error -->
|
|
<!-- log? -->
|
|
<!-- - Why won't Apache compile using the (SunOS|HPUX|etc...) -->
|
|
<!-- compiler that comes with the OS? -->
|
|
|
|
|
|
<UL>
|
|
<LI><STRONG>Background</STRONG>
|
|
<OL START=1>
|
|
<LI><A HREF="#what">What is Apache?</A>
|
|
</LI>
|
|
<LI><A HREF="#why">Why was Apache created?</A>
|
|
</LI>
|
|
<LI><A HREF="#relate">How does The Apache Group's work relate to
|
|
other servers?</A>
|
|
</LI>
|
|
<LI><A HREF="#name">Why the name "Apache"?</A>
|
|
</LI>
|
|
<LI><A HREF="#compare">OK, so how does Apache compare to other servers?</A>
|
|
</LI>
|
|
<LI><A HREF="#tested">How thoroughly tested is Apache?</A>
|
|
</LI>
|
|
<LI><A HREF="#future">What are the future plans for Apache?</A>
|
|
</LI>
|
|
<LI><A HREF="#support">Whom do I contact for support?</A>
|
|
</LI>
|
|
<LI><A HREF="#more">Is there any more information on Apache?</A>
|
|
</LI>
|
|
<LI><A HREF="#where">Where can I get Apache?</A>
|
|
</LI>
|
|
</OL>
|
|
</LI>
|
|
<LI><STRONG>Technical Questions</STRONG>
|
|
<OL START=11>
|
|
<LI><A HREF="#what2do">"Why can't I ...? Why won't ...
|
|
work?" What to do in case of problems</A>
|
|
</LI>
|
|
<LI><A HREF="#compatible">How compatible is Apache with my existing
|
|
NCSA 1.3 setup?</A>
|
|
</LI>
|
|
<LI><A HREF="#CGIoutsideScriptAlias">How do I enable CGI execution
|
|
in directories other than the ScriptAlias?</A>
|
|
</LI>
|
|
<LI><A HREF="#premature-script-headers">What does it mean when my
|
|
CGIs fail with "<SAMP>Premature end of script
|
|
headers</SAMP>"?</A>
|
|
</LI>
|
|
<LI><A HREF="#ssi-part-i">How do I enable SSI (parsed HTML)?</A>
|
|
</LI>
|
|
<LI><A HREF="#ssi-part-ii">Why don't my parsed files get cached?</A>
|
|
</LI>
|
|
<LI><A HREF="#ssi-part-iii">How can I have my script output parsed?</A>
|
|
</LI>
|
|
<LI><A HREF="#proxy">Does or will Apache act as a Proxy server?</A>
|
|
</LI>
|
|
<LI><A HREF="#multiviews">What are "multiviews"?</A>
|
|
</LI>
|
|
<LI><A HREF="#fdlim">Why can't I run more than <<EM>n</EM>>
|
|
virtual hosts?</A>
|
|
</LI>
|
|
<LI><A HREF="#limitGET">Why do I keep getting "access denied" for
|
|
form POST requests?</A>
|
|
</LI>
|
|
<LI><A HREF="#passwdauth">Can I use my <SAMP>/etc/passwd</SAMP> file
|
|
for Web page authentication?</A>
|
|
</LI>
|
|
<LI><A HREF="#errordoc401">Why doesn't my <CODE>ErrorDocument
|
|
401</CODE> work?</A>
|
|
</LI>
|
|
<LI><A HREF="#setgid">Why do I get "<SAMP>setgid: Invalid
|
|
argument</SAMP>" at startup?</A>
|
|
</LI>
|
|
<LI><A HREF="#cookies1">Why does Apache send a cookie on every response?</A>
|
|
</LI>
|
|
<LI><A HREF="#cookies2">Why don't my cookies work, I even compiled in
|
|
<SAMP>mod_cookies</SAMP>?</A>
|
|
</LI>
|
|
<LI><A HREF="#jdk1-and-http1.1">Why do my Java app[let]s give me plain text
|
|
when I request an URL from an Apache server?</A>
|
|
</LI>
|
|
<LI><A HREF="#putsupport">Why can't I publish to my Apache server
|
|
using PUT on Netscape Gold and other programs?</A>
|
|
</LI>
|
|
<LI><A HREF="#fastcgi">Why isn't FastCGI included with Apache any
|
|
more?</A>
|
|
</LI>
|
|
<LI><A HREF="#nodelay">Why am I getting "<SAMP>httpd: could not
|
|
set socket option TCP_NODELAY</SAMP>" in my error log?</A>
|
|
</LI>
|
|
<LI><A HREF="#nph-scripts">How can I get my script's output without
|
|
Apache buffering it?</A>
|
|
</LI>
|
|
<LI><A HREF="#linuxiovec">Why do I get complaints about redefinition
|
|
of `struct iovec' when compiling under Linux?</A>
|
|
</LI>
|
|
<LI><A HREF="#wheres-the-dump">The errorlog says Apache dumped core,
|
|
but where's the dump file?</A>
|
|
</LI>
|
|
<LI><A HREF="#dnsauth">Why isn't restricting access by host or domain name
|
|
working correctly?</A>
|
|
</LI>
|
|
<LI><A HREF="#SSL-i">Why doesn't Apache include SSL?</A>
|
|
</LI>
|
|
<LI><A HREF="#HPUX-core">Why do I get core dumps under HPUX using
|
|
HP's ANSI C compiler?</A>
|
|
</LI>
|
|
<LI><A HREF="#midi">How do I get Apache to send a MIDI file so the
|
|
browser can play it?</A>
|
|
</LI>
|
|
</OL>
|
|
</LI>
|
|
</UL>
|
|
|
|
<HR>
|
|
|
|
<H2>The Answers</H2>
|
|
<P>
|
|
</P>
|
|
<H3>
|
|
Background
|
|
</H3>
|
|
<OL START=1>
|
|
<LI><A NAME="what">
|
|
<STRONG>What is Apache?</STRONG>
|
|
</A>
|
|
<P>
|
|
Apache was originally based on code and ideas found in the most
|
|
popular HTTP server of the time.. NCSA httpd 1.3 (early 1995). It has
|
|
since evolved into a far superior system which can rival (and probably
|
|
surpass) almost any other UNIX based HTTP server in terms of functionality,
|
|
efficiency and speed.
|
|
</P>
|
|
<P>
|
|
Since it began, it has been completely rewritten, and includes many new
|
|
features. Apache is, as of January 1997, the most popular WWW server on
|
|
the Internet, according to the
|
|
<A
|
|
HREF="http://www.netcraft.com/Survey/"
|
|
>Netcraft Survey</A>.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="why">
|
|
<STRONG>Why was Apache created?</STRONG>
|
|
</A>
|
|
<P>
|
|
To address the concerns of a group of WWW providers and part-time httpd
|
|
programmers that httpd didn't behave as they wanted it to behave.
|
|
Apache is an entirely volunteer effort, completely funded by its
|
|
members, not by commercial sales.
|
|
<HR>
|
|
</P>
|
|
</LI>
|
|
<LI><A NAME="relate">
|
|
<STRONG>How does The Apache Group's work relate to other
|
|
server efforts, such as NCSA's?</STRONG>
|
|
</A>
|
|
<P>
|
|
We, of course, owe a great debt to NCSA and their programmers for
|
|
making the server Apache was based on. We now, however, have our own
|
|
server, and our project is mostly our own. The Apache Project is an
|
|
entirely independent venture.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="name">
|
|
<STRONG>Why the name "Apache"?</STRONG>
|
|
</A>
|
|
<P>
|
|
A cute name which stuck. Apache is "<STRONG>A
|
|
PA</STRONG>t<STRONG>CH</STRONG>y server". It was
|
|
based on some existing code and a series of "patch files".
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="compare">
|
|
<STRONG>OK, so how does Apache compare to other servers?</STRONG>
|
|
</A>
|
|
<P>
|
|
For an independent assessment, see
|
|
<A
|
|
HREF="http://webcompare.iworld.com/compare/chart.html"
|
|
>Web Compare</A>'s
|
|
comparison chart.
|
|
</P>
|
|
<P>
|
|
Apache has been shown to be substantially faster than many other
|
|
free servers. Although certain commercial servers have claimed to
|
|
surpass Apache's speed (it has not been demonstrated that any of these
|
|
"benchmarks" are a good way of measuring WWW server speed at any
|
|
rate), we feel that it is better to have a mostly-fast free server
|
|
than an extremely-fast server that costs thousands of dollars. Apache
|
|
is run on sites that get millions of hits per day, and they have
|
|
experienced no performance difficulties.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="tested">
|
|
<STRONG>How thoroughly tested is Apache?</STRONG>
|
|
</A>
|
|
<P>
|
|
Apache is run on over 400,000 Internet servers (as of April 1997). It has
|
|
been tested thoroughly by both developers and users. The Apache Group
|
|
maintains rigorous standards before releasing new versions of their
|
|
server, and our server runs without a hitch on over one third of all
|
|
WWW servers available on the Internet. When bugs do show up, we
|
|
release patches and new versions as soon as they are available.
|
|
</P>
|
|
<P>
|
|
The Apache project's web site includes a page with a partial list of
|
|
<A
|
|
HREF="http://www.apache.org/info/apache_users"
|
|
>sites running Apache</A>.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="future">
|
|
<STRONG>What are the future plans for Apache?</STRONG>
|
|
</A>
|
|
<P>
|
|
<UL>
|
|
<LI>to continue as a public domain HTTP server,
|
|
</LI>
|
|
<LI>to keep up with advances in HTTP protocol and web developments in
|
|
general,
|
|
</LI>
|
|
<LI>to collect suggestions for fixes/improvements from its users,
|
|
</LI>
|
|
<LI>to respond to needs of large volume providers as well as
|
|
occasional users.
|
|
</LI>
|
|
</UL>
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="support">
|
|
<STRONG>Whom do I contact for support?</STRONG>
|
|
</A>
|
|
<P>
|
|
There is no official support for Apache. None of the developers want to
|
|
be swamped by a flood of trivial questions that can be resolved elsewhere.
|
|
Bug reports and suggestions should be sent <EM>via</EM>
|
|
<A
|
|
HREF="http://www.apache.org/bug_report"
|
|
>the bug report page</A>.
|
|
Other questions should be directed to the
|
|
<A
|
|
HREF="news:comp.infosystems.www.servers.unix"
|
|
><SAMP>comp.infosystems.www.servers.unix</SAMP></A>
|
|
newsgroup, where some of the Apache team lurk,
|
|
in the company of many other httpd gurus who should be able
|
|
to help.
|
|
</P>
|
|
<P>
|
|
Commercial support for Apache is, however, available from a number
|
|
of third parties.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="more">
|
|
<STRONG>Is there any more information available on
|
|
Apache?</STRONG>
|
|
</A>
|
|
<P>
|
|
Indeed there is. See the main
|
|
<A
|
|
HREF="http://www.apache.org/"
|
|
>Apache web site</A>.
|
|
There is also a regular electronic publication called
|
|
<A
|
|
HREF="http://www.apacheweek.com/"
|
|
REL="Help"
|
|
><CITE>Apache Week</CITE></A>
|
|
available.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="where">
|
|
<STRONG>Where can I get Apache?</STRONG>
|
|
</A>
|
|
<P>
|
|
You can find out how to download the source for Apache at the
|
|
project's
|
|
<A
|
|
HREF="http://www.apache.org/"
|
|
>main web page</A>.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
</OL>
|
|
<H3>
|
|
Technical Questions
|
|
</H3>
|
|
<OL START=11>
|
|
<LI><A NAME="what2do">
|
|
<STRONG>"Why can't I ...? Why won't ... work?" What to
|
|
do in case of problems</STRONG>
|
|
</A>
|
|
<P>
|
|
If you are having trouble with your Apache server software, you should
|
|
take the following steps:
|
|
</P>
|
|
<OL>
|
|
<LI><STRONG>Check the errorlog!</STRONG>
|
|
<P>
|
|
Apache tries to be helpful when it encounters a problem. In many
|
|
cases, it will provide some details by writing one or messages to
|
|
the server error log. Sometimes this is enough for you to diagnose
|
|
& fix the problem yourself (such as file permissions or the like).
|
|
The default location of the error log is
|
|
<CODE>/usr/local/etc/httpd/logs/error_log</CODE>, but see the
|
|
<A
|
|
HREF="../mod/core.html#errorlog"
|
|
><SAMP>ErrorLog</SAMP></A>
|
|
directive in your config files for the location on your server.
|
|
</P>
|
|
</LI>
|
|
<LI><STRONG>Check the
|
|
<A
|
|
HREF="http://www.apache.org/docs/misc/FAQ.html"
|
|
>FAQ</A>!</STRONG>
|
|
<P>
|
|
The latest version of the Apache Frequently-Asked Questions list can
|
|
always be found at the main Apache web site.
|
|
</P>
|
|
</LI>
|
|
<LI><STRONG>Check the Apache bug database</STRONG>
|
|
<P>
|
|
Most problems that get reported to The Apache Group are recorded in
|
|
the
|
|
<A
|
|
HREF="http://www.apache.org/bugdb.cgi"
|
|
>bug database</A>.
|
|
<EM><STRONG>Please</STRONG> check the existing reports, open
|
|
<STRONG>and</STRONG> closed, before adding one.</EM> If you find
|
|
that your issue has already been reported, please <EM>don't</EM> add
|
|
a "me, too" report. If the original report isn't closed
|
|
yet, we suggest that you check it periodically. You might also
|
|
consider contacting the original submitter, because there may be an
|
|
email exchange going on about the issue that isn't getting recorded
|
|
in the database.
|
|
</P>
|
|
</LI>
|
|
<LI><STRONG>Ask in the <SAMP>comp.infosystems.www.servers.unix</SAMP>
|
|
USENET newsgroup</STRONG>
|
|
<P>
|
|
A lot of common problems never make it to the bug database because
|
|
there's already high Q&A traffic about them in the
|
|
<A
|
|
HREF="news:comp.infosystems.www.servers.unix"
|
|
><SAMP>comp.infosystems.www.servers.unix</SAMP></A>
|
|
newsgroup. Many Apache users, and some of the developers, can be
|
|
found roaming its virtual halls, so it is suggested that you seek
|
|
wisdom there. The chances are good that you'll get a faster answer
|
|
there than from the bug database, even if you <EM>don't</EM> see
|
|
your question already posted.
|
|
</P>
|
|
</LI>
|
|
<LI><STRONG>If all else fails, report the problem in the bug
|
|
database</STRONG>
|
|
<P>
|
|
If you've gone through those steps above that are appropriate and
|
|
have obtained no relief, then please <EM>do</EM> let The Apache
|
|
Group know about the problem by
|
|
<A
|
|
HREF="http://www.apache.org/bugdb.cgi"
|
|
>logging a bug report</A>.
|
|
</P>
|
|
<P>
|
|
If your problem involves the server crashing and generating a core
|
|
dump, please include a backtrace (if possible). As an example,
|
|
</P>
|
|
<P>
|
|
<CODE>
|
|
<DL>
|
|
<DD># cd <EM>ServerRoot</EM>
|
|
</DD>
|
|
<DD># dbx httpd core
|
|
</DD>
|
|
<DD>(dbx) where
|
|
</DD>
|
|
</DL>
|
|
</CODE>
|
|
</P>
|
|
<P>
|
|
(Substitute the appropriate locations for your
|
|
<SAMP>ServerRoot</SAMP> and your <SAMP>httpd</SAMP> and
|
|
<SAMP>core</SAMP> files. You may have to use <CODE>gdb</CODE>
|
|
instead of <CODE>dbx</CODE>.)
|
|
</P>
|
|
</LI>
|
|
</OL>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="compatible">
|
|
<STRONG>How compatible is Apache with my existing NCSA 1.3
|
|
setup?</STRONG>
|
|
</A>
|
|
<P>
|
|
Apache attempts to offer all the features and configuration options
|
|
of NCSA httpd 1.3, as well as many of the additional features found in
|
|
NCSA httpd 1.4 and NCSA httpd 1.5.
|
|
</P>
|
|
<P>
|
|
NCSA httpd appears to be moving toward adding experimental features
|
|
which are not generally required at the moment. Some of the experiments
|
|
will succeed while others will inevitably be dropped. The Apache
|
|
philosophy is to add what's needed as and when it is needed.
|
|
</P>
|
|
<P>
|
|
Friendly interaction between Apache and NCSA developers should ensure
|
|
that fundamental feature enhancements stay consistent between the two
|
|
servers for the foreseeable future.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="CGIoutsideScriptAlias">
|
|
<STRONG>How do I enable CGI execution in directories other than
|
|
the ScriptAlias?</STRONG>
|
|
</A>
|
|
<P>
|
|
Apache recognizes all files in a directory named as a
|
|
<A
|
|
HREF="../mod/mod_alias.html#scriptalias"
|
|
><SAMP>ScriptAlias</SAMP></A>
|
|
as being eligible for execution rather than processing as normal
|
|
documents. This applies regardless of the file name, so scripts in a
|
|
ScriptAlias directory don't need to be named
|
|
"<SAMP>*.cgi</SAMP>" or "<SAMP>*.pl</SAMP>" or
|
|
whatever. In other words, <EM>all</EM> files in a ScriptAlias
|
|
directory are scripts, as far as Apache is concerned.
|
|
</P>
|
|
<P>
|
|
To persuade Apache to execute scripts in other locations, such as in
|
|
directories where normal documents may also live, you must tell it how
|
|
to recognize them - and also that it's okay to execute them. For
|
|
this, you need to use something like the
|
|
<A
|
|
HREF="../mod/mod_mime.html#addhandler"
|
|
><SAMP>AddHandler</SAMP></A>
|
|
directive.
|
|
</P>
|
|
<OL>
|
|
<LI>In an appropriate section of your server configuration files, add
|
|
a line such as
|
|
<P>
|
|
<DL>
|
|
<DD><CODE>AddHandler cgi-script .cgi</CODE>
|
|
</DD>
|
|
</DL>
|
|
</P>
|
|
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.
|
|
</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>
|
|
<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. The most common cause of this (aside from people not
|
|
outputting the required headers at all) a result of an interaction
|
|
with perl's output buffering. To make perl flush its buffers
|
|
after each output statement, insert the following statements before your
|
|
first <CODE>print</CODE> or <CODE>write</CODE> statement:
|
|
</P>
|
|
<P>
|
|
<CODE>
|
|
<DL>
|
|
<DD>$cfh = select (STDOUT);
|
|
</DD>
|
|
<DD>$| = 1;
|
|
</DD>
|
|
<DD>select ($cfh);
|
|
</DD>
|
|
</DL>
|
|
</CODE>
|
|
</P>
|
|
<P>
|
|
This is generally only necessary when you are calling external
|
|
programs from your script that send output to stdout.
|
|
<P>
|
|
If your script isn't written in Perl, do the equivalent thing for
|
|
whatever language you <EM>are</EM> using (<EM>e.g.</EM>, for C, call
|
|
<CODE>fflush()</CODE> after writing the headers).
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="ssi-part-i">
|
|
<STRONG>How do I enable SSI (parsed HTML)?</STRONG>
|
|
</A>
|
|
<P>
|
|
SSI (an acronym for Server-Side Include) directives allow static HTML
|
|
documents to be enhanced at run-time (<EM>e.g.</EM>, when delivered to
|
|
a client by Apache). The format of SSI directives is covered
|
|
in the <A HREF="../mod/mod_include.html">mod_include manual</A>;
|
|
suffice it to say that Apache supports not only SSI but
|
|
xSSI (eXtended SSI) directives.
|
|
</P>
|
|
<P>
|
|
Processing a document at run-time is called <EM>parsing</EM> it; hence
|
|
the term "parsed HTML" sometimes used for documents that
|
|
contain SSI instructions. Parsing tends to be <EM>extremely</EM>
|
|
resource-consumptive, and is not enabled by default.
|
|
</P>
|
|
<P>
|
|
To enable SSI processing, you need to
|
|
</P>
|
|
<UL>
|
|
<LI>Build your server with the
|
|
<A
|
|
HREF="../mod/mod_include.html"
|
|
><SAMP>mod_include</SAMP></A>
|
|
module. This is normally compiled in by default.
|
|
</LI>
|
|
<LI>Make sure your server configuration files have an
|
|
<A
|
|
HREF="../mod/core.html#options"
|
|
><SAMP>Options</SAMP></A>
|
|
directive which permits <SAMP>Includes</SAMP>.
|
|
</LI>
|
|
<LI>Make sure that the directory where you want the SSI documents to
|
|
live is covered by the "server-parsed" content handler,
|
|
either explicitly or in some ancestral location. That can be done
|
|
with the following
|
|
<A
|
|
HREF="../mod/mod_mime.html#addhandler"
|
|
><SAMP>AddHandler</SAMP></A>
|
|
directive:
|
|
<P>
|
|
<DL>
|
|
<DD><CODE>AddHandler server-parsed .shtml</CODE>
|
|
</DD>
|
|
</DL>
|
|
</P>
|
|
This indicates that all files ending in ".shtml" in that
|
|
location (or its descendants) should be parsed. Note that using
|
|
".html" will cause all normal HTML files to be parsed,
|
|
which may put an inordinate load on your server.
|
|
</LI>
|
|
</UL>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="ssi-part-ii">
|
|
<STRONG>Why don't my parsed files get cached?</STRONG>
|
|
</A>
|
|
<P>
|
|
Since the server is performing run-time processing of your SSI
|
|
directives, which may change the content shipped to the client, it
|
|
can't know at the time it starts parsing what the final size of the
|
|
result will be, or whether the parsed result will always be the same.
|
|
This means that it can't generate <SAMP>Content-Length</SAMP> or
|
|
<SAMP>Last-Modified</SAMP> headers. Caches commonly work by comparing
|
|
the <SAMP>Last-Modified</SAMP> of what's in the cache with that being
|
|
delivered by the server. Since the server isn't sending that header
|
|
for a parsed document, whatever's doing the caching can't tell whether
|
|
the document has changed or not - and so fetches it again to be on the
|
|
safe side.
|
|
</P>
|
|
<P>
|
|
You can work around this in some cases by causing an
|
|
<SAMP>Expires</SAMP> header to be generated. (See the
|
|
<A
|
|
HREF="../mod/mod_expires.html"
|
|
REL="Help"
|
|
><SAMP>mod_expires</SAMP></A>
|
|
documentation for more details.) Another possibility is to use the
|
|
<A
|
|
HREF="../mod/mod_include.html#xbithack"
|
|
REL="Help"
|
|
><SAMP>XBitHack Full</SAMP></A>
|
|
mechanism, which tells Apache to send (under certain circumstances
|
|
detailed in the XBitHack directive description) a
|
|
<SAMP>Last-Modified</SAMP> header based upon the last modification
|
|
time of the file being parsed. Note that this may actually be lying
|
|
to the client if the parsed file doesn't change but the SSI-inserted
|
|
content does; if the included content changes often, this can result
|
|
in stale copies being cached.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="ssi-part-iii">
|
|
<STRONG>How can I have my script output parsed?</STRONG>
|
|
</A>
|
|
<P>
|
|
So you want to include SSI directives in the output from your CGI
|
|
script, but can't figure out how to do it?
|
|
The short answer is "you can't." This is potentially
|
|
a security liability and, more importantly, it can not be cleanly
|
|
implemented under the current server API. The best workaround
|
|
is for your script itself to do what the SSIs would be doing.
|
|
After all, it's generating the rest of the content.
|
|
</P>
|
|
<P>
|
|
This is a feature The Apache Group hopes to add in the next major
|
|
release after 1.2.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="proxy">
|
|
<STRONG>Does or will Apache act as a Proxy server?</STRONG>
|
|
</A>
|
|
<P>
|
|
Apache version 1.1 and above comes with a proxy module. 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.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="fdlim">
|
|
<STRONG>Why can't I run more than <<EM>n</EM>>
|
|
virtual hosts?</STRONG>
|
|
</A>
|
|
<P>
|
|
You are probably running into resource limitations in your
|
|
operating system. The most common limitation is the
|
|
<EM>per</EM>-process limit on <STRONG>file descriptors</STRONG>,
|
|
which is almost always the cause of problems seen when adding
|
|
virtual hosts. Apache often does not give an intuitive error
|
|
message because it is normally some library routine (such as
|
|
<CODE>gethostbyname()</CODE>) which needs file descriptors and
|
|
doesn't complain intelligibly when it can't get them.
|
|
</P>
|
|
<P>
|
|
Each log file requires a file descriptor, which means that if you are
|
|
using separate access and error logs for each virtual host, each
|
|
virtual host needs two file descriptors. Each
|
|
<A
|
|
HREF="../mod/core.html#listen"
|
|
><SAMP>Listen</SAMP></A>
|
|
directive also needs a file descriptor.
|
|
</P>
|
|
<P>
|
|
Typical values for <<EM>n</EM>> that we've seen are in
|
|
the neighborhood of 128 or 250. When the server bumps into the file
|
|
descriptor limit, it may dump core with a SIGSEGV, it might just
|
|
hang, or it may limp along and you'll see (possibly meaningful) errors
|
|
in the error log. One common problem that occurs when you run into
|
|
a file descriptor limit is that CGI scripts stop being executed
|
|
properly.
|
|
</P>
|
|
<P>
|
|
As to what you can do about this:
|
|
</P>
|
|
<OL>
|
|
<LI>Reduce the number of
|
|
<A
|
|
HREF="../mod/core.html#listen"
|
|
><SAMP>Listen</SAMP></A>
|
|
directives. If there are no other servers running on the machine
|
|
and all of them are running on the same port, you normally don't
|
|
need any Listen directives at all.
|
|
</LI>
|
|
<LI>Reduce the number of log files. You can use
|
|
<A
|
|
HREF="../mod/mod_log_config.html"
|
|
><SAMP>mod_log_config</SAMP></A>
|
|
to log all requests to a single log file while including the name
|
|
of the virtual host in the log file. You can then write a
|
|
script to split the logfile into separate files later if
|
|
necessary.
|
|
</LI>
|
|
<LI>Increase the number of file descriptors available to the server
|
|
(see your system's documentation on the <CODE>limit</CODE> or
|
|
<CODE>ulimit</CODE> commands). For some systems, information on
|
|
how to do this is available in the
|
|
<A
|
|
HREF="perf.html"
|
|
>performance hints</A>
|
|
page.
|
|
</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>
|
|
<HR>
|
|
<LI><A NAME="limitGET">
|
|
<STRONG>Why do I keep getting "access denied" for form POST
|
|
requests?</STRONG>
|
|
</A>
|
|
<P>
|
|
The most common cause of this is a <SAMP><Limit></SAMP> section
|
|
that only names the <SAMP>GET</SAMP> method. Look in your
|
|
configuration files for something that resembles the following and
|
|
would affect the location where the POST-handling script resides:
|
|
</P>
|
|
<P>
|
|
<CODE>
|
|
<DL>
|
|
<DD><Limit GET>
|
|
</DD>
|
|
<DD> :
|
|
</DD>
|
|
</DL>
|
|
</CODE>
|
|
</P>
|
|
<P>
|
|
Change that to <SAMP><Limit GET POST></SAMP> and the problem
|
|
will probably go away.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="passwdauth">
|
|
<STRONG>Can I use my <SAMP>/etc/passwd</SAMP> file
|
|
for Web page authentication?</STRONG>
|
|
</A>
|
|
<P>
|
|
Yes, you can - but it's a <STRONG>very bad idea</STRONG>. Here are
|
|
some of the reasons:
|
|
</P>
|
|
<UL>
|
|
<LI>The Web technology provides no governors on how often or how
|
|
rapidly password (authentication failure) retries can be made. That
|
|
means that someone can hammer away at your system's
|
|
<SAMP>root</SAMP> password using the Web, using a dictionary or
|
|
similar mass attack, just as fast as the wire and your server can
|
|
handle the requests. Most operating systems these days include
|
|
attack detection (such as <EM>n</EM> failed passwords for the same
|
|
account within <EM>m</EM> seconds) and evasion (breaking the
|
|
connection, disabling the account under attack, disabling
|
|
<EM>all</EM> logins from that source, <EM>et cetera</EM>), but the
|
|
Web does not.
|
|
</LI>
|
|
<LI>An account under attack isn't notified (unless the server is
|
|
heavily modified); there's no "You have 19483 login
|
|
failures" message when the legitimate owner logs in.
|
|
</LI>
|
|
<LI>Without an exhaustive and error-prone examination of the server
|
|
logs, you can't tell whether an account has been compromised.
|
|
Detecting that an attack has occurred, or is in progress, is fairly
|
|
obvious, though - <EM>if</EM> you look at the logs.
|
|
</LI>
|
|
<LI>Web authentication passwords (at least for Basic authentication)
|
|
generally fly across the wire, and through intermediate proxy
|
|
systems, in what amounts to plaintext. "O'er the net we
|
|
go/Caching all the way;/O what fun it is to surf/Giving my password
|
|
away!"
|
|
</LI>
|
|
<LI>Since HTTP is stateless, information about the authentication is
|
|
transmitted <EM>each and every time</EM> a request is made to the
|
|
server. Essentially, the client caches it after the first
|
|
successful access, and transmits it without asking for all
|
|
subsequent requests to the same server.
|
|
</LI>
|
|
<LI>It's relatively trivial for someone on your system to put up a
|
|
page that will steal the cached password from a client's cache
|
|
without them knowing. Can you say "password grabber"?
|
|
</LI>
|
|
</UL>
|
|
<P>
|
|
If you still want to do this in light of the above disadvantages, the
|
|
method is left as an exercise for the reader. It'll void your Apache
|
|
warranty, though, and you'll lose all accumulated UNIX guru points.
|
|
</P>
|
|
<HR>
|
|
<LI><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 "/foo/bar" and not one
|
|
with a method and hostname such as "http://host/foo/bar". See the
|
|
<A
|
|
HREF="../mod/core.html#errordocument"
|
|
><SAMP>ErrorDocument</SAMP></A>
|
|
documentation for details. This was incorrectly documented in the past.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="setgid">
|
|
<STRONG>Why do I get "<SAMP>setgid: Invalid
|
|
argument</SAMP>" at startup?</STRONG>
|
|
</A>
|
|
<P>
|
|
Your
|
|
<A
|
|
HREF="../mod/core.html#group"
|
|
><SAMP>Group</SAMP></A>
|
|
directive (probably in <SAMP>conf/httpd.conf</SAMP>) needs to name a
|
|
group that actually exists in the <SAMP>/etc/group</SAMP> file (or
|
|
your system's equivalent).
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="cookies1">
|
|
<STRONG>Why does Apache send a cookie on every response?</STRONG>
|
|
</A>
|
|
<P>
|
|
Apache does <EM>not</EM> send automatically send a cookie on every
|
|
response, unless you have re-compiled it with the
|
|
<A
|
|
HREF="../mod/mod_cookies.html"
|
|
><SAMP>mod_cookies</SAMP></A>
|
|
module.
|
|
This module was distributed with Apache prior to 1.2.
|
|
This module may help track users, and uses cookies to do this. If
|
|
you are not using the data generated by <SAMP>mod_cookies</SAMP>, do
|
|
not compile it into Apache. Note that in 1.2 this module was renamed
|
|
to the more correct name
|
|
<A
|
|
HREF="../mod/mod_usertrack.html"
|
|
><SAMP>mod_usertrack</SAMP></A>,
|
|
and cookies
|
|
have to be specifically enabled with the
|
|
<A
|
|
HREF="../mod/mod_usertrack.html#cookietracking"
|
|
><SAMP>CookieTracking</SAMP></A>
|
|
directive.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="cookies2">
|
|
<STRONG>Why don't my cookies work, I even compiled in
|
|
<SAMP>mod_cookies</SAMP>?
|
|
</STRONG>
|
|
</A>
|
|
<P>
|
|
Firstly, you do <EM>not</EM> need to compile in
|
|
<SAMP>mod_cookies</SAMP> in order for your scripts to work (see the
|
|
<A
|
|
HREF="#cookies1"
|
|
>previous question</A>
|
|
for more about <SAMP>mod_cookies</SAMP>). Apache passes on your
|
|
<SAMP>Set-Cookie</SAMP> header fine, with or without this module. If
|
|
cookies do not work it will be because your script does not work
|
|
properly or your browser does not use cookies or is not set-up to
|
|
accept them.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="jdk1-and-http1.1">
|
|
<STRONG>Why do my Java app[let]s give me plain text when I request
|
|
an URL from an Apache server?</STRONG>
|
|
</A>
|
|
<P>
|
|
As of version 1.2, Apache is an HTTP/1.1 (HyperText Transfer Protocol
|
|
version 1.1) server. This fact is reflected in the protocol version
|
|
that's included in the response headers sent to a client when
|
|
processing a request. Unfortunately, the URL methods (URLConnection
|
|
and friends) in the Java Development Kit (JDK) versions 1.0.2 through
|
|
1.1.1 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, but it's unclear when (or
|
|
whether) it will be fixed. 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 HotJava/1.0 force-response-1.0</CODE>
|
|
</DD>
|
|
</DL>
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="putsupport">
|
|
<STRONG>Why can't I publish to my Apache server using PUT on
|
|
Netscape Gold and other programs?</STRONG>
|
|
</A>
|
|
<P>
|
|
Because you need to install and configure a script to handle
|
|
the uploaded files. This script is often called a "PUT" handler.
|
|
There are several available, but they may have security problems.
|
|
Using FTP uploads may be easier and more secure, at least for now.
|
|
For more information, see the <CITE>Apache Week</CITE> article
|
|
<A
|
|
HREF="http://www.apacheweek.com/features/put"
|
|
><CITE>Publishing Pages with PUT</CITE></A>.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="fastcgi">
|
|
<STRONG>Why isn't FastCGI included with Apache any more?</STRONG>
|
|
</A>
|
|
<P>
|
|
The simple answer is that it was becoming too difficult to keep the
|
|
version being included with Apache synchronized with the master copy
|
|
at the
|
|
<A
|
|
HREF="http://www.fastcgi.com/servers/apache/"
|
|
>FastCGI web site</A>. When a new version of Apache was released, the
|
|
version of the FastCGI module included with it would soon be out of date.
|
|
</P>
|
|
<P>
|
|
You can still obtain the FastCGI module for Apache from the master
|
|
FastCGI web site.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="nodelay">
|
|
<STRONG>Why am I getting "<SAMP>httpd: could not set socket
|
|
option TCP_NODELAY</SAMP>" in my error log?</STRONG>
|
|
</A>
|
|
<P>
|
|
This message almost always indicates that the client disconnected
|
|
before Apache reached the point of calling <CODE>setsockopt()</CODE>
|
|
for the connection. It shouldn't occur for more than about 1% of the
|
|
requests your server handles, and it's advisory only in any case.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="nph-scripts">
|
|
<STRONG>How can I get my script's output without Apache buffering
|
|
it?</STRONG>
|
|
</A>
|
|
<P>
|
|
In order to improve network performance, Apache buffers script output
|
|
into relatively large chunks. If you have a script that sends
|
|
information in bursts (such as partial-done messages in a multi-commit
|
|
database transaction, perhaps), the client will not necessarily get
|
|
the output as the script is generating it.
|
|
</P>
|
|
<P>
|
|
To avoid this, Apache recognizes scripts whose names begin with
|
|
"<SAMP>nph-</SAMP>" as <EM>non-parsed-header</EM> scripts.
|
|
That is, Apache won't buffer their output, but connect it directly to
|
|
the socket going back to the client.
|
|
</P>
|
|
<P>
|
|
While this will probably do what you want, there <EM>are</EM> some
|
|
disadvantages to it:
|
|
</P>
|
|
<UL>
|
|
<LI><STRONG>YOU</STRONG> (the script) are responsible for generating
|
|
<STRONG>ALL</STRONG> of the HTTP headers, and no longer
|
|
<EM>just</EM> the "<SAMP>Content-type</SAMP>" or
|
|
"<SAMP>Location</SAMP>" headers
|
|
</LI>
|
|
<LI>Unless your script generates its output carefully, you will see a
|
|
performance penalty as excessive numbers of packets go back and forth
|
|
</LI>
|
|
</UL>
|
|
<P>
|
|
As an example how you might handle the former (in a Perl script):
|
|
</P>
|
|
<CODE>
|
|
<DL>
|
|
<DD>if ($0 =~ m:/*nph-:) {
|
|
<BR>
|
|
|
|
$HTTP_headers =
|
|
"HTTP/1.1 200 OK\015\012";
|
|
<BR>
|
|
|
|
$HTTP_headers .=
|
|
"Connection: close\015\012";
|
|
<BR>
|
|
|
|
printf ($HTTP_headers);
|
|
<BR>
|
|
};
|
|
</DD>
|
|
</DL>
|
|
</CODE>
|
|
<P>
|
|
and then follow with your normal non-<SAMP>nph</SAMP> headers.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="linuxiovec">
|
|
<STRONG>Why do I get complaints about redefinition
|
|
of `struct iovec' 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>
|
|
<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>
|
|
<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 (beginning with 1.2b8), the error log message
|
|
about dumped core includes the directory where the dump file should be
|
|
located. However, many Unixes do not allow a process that has
|
|
called <CODE>setuid()</CODE> to dump core for security reasons;
|
|
the typical Apache setup has the server started as root to bind to
|
|
port 80, after which it changes UIDs to a non-privileged user to
|
|
serve requests.
|
|
</P>
|
|
<P>
|
|
Dealing with this is extremely operating system-specific, and may
|
|
require rebuilding your system kernel. Consult your operating system
|
|
documentation or vendor for more information about whether your system
|
|
does this and how to bypass it. If there <EM>is</EM> a documented way
|
|
of bypassing it, it is recommended that you bypass it only for the
|
|
<SAMP>httpd</SAMP> server process if possible.
|
|
</P>
|
|
<P>
|
|
The canonical location for Apache's core-dump files is the
|
|
<A
|
|
HREF="../mod/core.html#serverroot"
|
|
>ServerRoot</A>
|
|
directory.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="dnsauth">
|
|
<STRONG>Why isn't restricting access by host or domain name
|
|
working correctly?</STRONG>
|
|
</A>
|
|
<P>
|
|
Two of the most common causes of this are:
|
|
</P>
|
|
<OL>
|
|
<LI><STRONG>An error, inconsistency, or unexpected mapping in the DNS
|
|
registration</STRONG>
|
|
<BR>
|
|
This happens frequently: your configuration restricts access to
|
|
<SAMP>Host.FooBar.Com</SAMP>, but you can't get in from that host.
|
|
The usual reason for this is that <SAMP>Host.FooBar.Com</SAMP> is
|
|
actually an alias for another name, and when Apache performs the
|
|
address-to-name lookup it's getting the <EM>real</EM> name, not
|
|
<SAMP>Host.FooBar.Com</SAMP>. You can verify this by checking the
|
|
reverse lookup yourself. The easiest way to work around it is to
|
|
specify the correct host name in your configuration.
|
|
</LI>
|
|
<LI><STRONG>Inadequate checking and verification in your
|
|
configuration of Apache</STRONG>
|
|
<BR>
|
|
If you intend to perform access checking and restriction based upon
|
|
the client's host or domain name, you really need to configure
|
|
Apache to double-check the origin information it's supplied. You do
|
|
this by adding the <SAMP>-DMAXIMUM_DNS</SAMP> clause to the
|
|
<SAMP>EXTRA_CFLAGS</SAMP> definition in your
|
|
<SAMP>Configuration</SAMP> file. For example:
|
|
<DL>
|
|
<DD><CODE>EXTRA_CFLAGS=-DMAXIMUM_DNS</CODE>
|
|
</DD>
|
|
</DL>
|
|
<P>
|
|
This will cause Apache to be very paranoid about making sure a
|
|
particular host address is <EM>really</EM> assigned to the name it
|
|
claims to be. Note that this <EM>can</EM> incur a significant
|
|
performance penalty, however, because of all the name resolution
|
|
requests being sent to a nameserver.
|
|
</P>
|
|
</LI>
|
|
</OL>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="SSL-i">
|
|
<STRONG>Why doesn't Apache include SSL?</STRONG>
|
|
</A>
|
|
<P>
|
|
SSL (Secure Socket Layer) data transport requires encryption, and many
|
|
governments have restrictions upon the import, export, and use of
|
|
encryption technology. If Apache included SSL in the base package,
|
|
its distribution would involve all sorts of legal and bureaucratic
|
|
issues, and it would no longer be freely available. Also, some of
|
|
the technology required to talk to current clients using SSL is
|
|
patented by <A HREF="http://www.rsa.com/">RSA Data Security</A>,
|
|
who restricts its use without a license.
|
|
</P>
|
|
<P>
|
|
Some SSL implementations of Apache are available, however; see the
|
|
"<A
|
|
HREF="http://www.apache.org/related_projects"
|
|
>related projects</A>"
|
|
page at the main Apache web site.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="HPUX-core">
|
|
<STRONG>Why do I get core dumps under HPUX using HP's ANSI
|
|
C compiler?</STRONG>
|
|
</A>
|
|
<P>
|
|
We have had numerous reports of Apache dumping core when compiled
|
|
with HP's ANSI C compiler using optimization. Disabling the compiler
|
|
optimiation has fixed these problems.
|
|
</P>
|
|
<HR>
|
|
</LI>
|
|
<LI><A NAME="midi">
|
|
<STRONG>How do I get Apache to send a MIDI file so the browser can
|
|
play it?</STRONG>
|
|
</A>
|
|
<P>
|
|
Even though the registered MIME type for MIDI files is
|
|
<SAMP>audio/midi</SAMP>, some browsers are not set up to recognize it
|
|
as such; instead, they look for <SAMP>audio/x-midi</SAMP>. There are
|
|
two things you can do to address this:
|
|
</P>
|
|
<OL>
|
|
<LI>Configure your browser to treat documents of type
|
|
<SAMP>audio/midi</SAMP> correctly. This is the type that Apache
|
|
sends by default. This may not be workable, however, if you have
|
|
many client installations to change, or if some or many of the
|
|
clients are not under your control.
|
|
</LI>
|
|
<LI>Instruct Apache to send a different <SAMP>Content-type</SAMP>
|
|
header for these files by adding the following line to your server's
|
|
configuration files:
|
|
<DL>
|
|
<DD><CODE>AddType audio/x-midi .mid .midi .kar</CODE>
|
|
</DD>
|
|
</DL>
|
|
<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>
|
|
<!-- Don't forget to add HR tags at the end of each list item.. -->
|
|
</LI>
|
|
</OL>
|
|
<!--#include virtual="footer.html" -->
|
|
</BODY>
|
|
</HTML>
|