<!--#include virtual="header.html" -->
<H1 ALIGN="CENTER">Apache Server Frequently Asked Questions</H1>
<P>
- $Revision: 1.1 $ ($Date: 1999/06/24 15:02:52 $)
+ $Revision: 1.2 $ ($Date: 2000/09/09 18:19:54 $)
</P>
<P>
The latest version of this FAQ is always available from the main
</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.
+ You can't! The reasons are: first, that, case translations for
+ arbitrary length URLs cannot be done <EM>via</EM> regex patterns and
+ corresponding substitutions. One needs a per-character pattern like
+ the sed/Perl <SAMP>tr|..|..|</SAMP> feature. Second, just making
+ URLs always upper or lower case does not solve the whole problem of
+ case-INSENSITIVE URLs, because URLs actually have to be rewritten to
+ the correct case-variant for the file residing on the filesystem
+ in order to allow Apache to access the file. And
+ the 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.
+ But there is a module named <CODE><A
+ HREF="../mod/mod_speling.html">mod_speling.c</A></CODE> in the
+ Apache distribution. Try this module to help correct people who use
+ mis-cased URLs.
</P>
<HR>
</LI>
One is that it's possible Apache will die without cleaning up the semaphore
(see the <CODE>ipcs(8)</CODE> man page). The other is that the semaphore
API allows for a denial of service attack by any CGIs running under the
-same uid as the webserver (<EM>i.e.</EM>, all CGIs unless you use something
+same uid as the webserver (<EM>i.e.</EM>, all CGIs, unless you use something
like suexec or cgiwrapper). For these reasons this method is not used
on any architecture except IRIX (where the previous two are prohibitively
expensive on most IRIX boxes).
timeout, but it doesn't prohibit it. On systems without the timeout,
Apache 1.2 induces many sockets stuck forever in the FIN_WAIT_2 state.
In many cases this can be avoided by simply upgrading to the latest
-TCP/IP patches supplied by the vendor, in cases where the vendor has
+TCP/IP patches supplied by the vendor. In cases where the vendor has
never released patches (<EM>i.e.</EM>, SunOS4 -- although folks with a source
license can patch it themselves) we have decided to disable this feature.
There are
<A HREF="http://www.arctic.org/~dgaudet/apache/1.3/">
-several performance patches available for 1.3.</A> But they may
-be slightly out of date by the time Apache 1.3.0 has been released,
+several performance patches available for 1.3.</A> Although they may
+not apply cleanly to the current version,
it shouldn't be difficult for someone with a little C knowledge to
update them. In particular:
<P>Apache's core code is already multithread aware, and Apache version
1.3 is multithreaded on NT. There have been at least two other experimental
implementations of threaded Apache, one using the 1.3 code base on DCE,
-and one using a custom user-level threads package and the 1.0 code base,
-neither are available publically. There is also an experimental port of
+and one using a custom user-level threads package and the 1.0 code base;
+neither is available publically. There is also an experimental port of
Apache 1.3 to <A HREF="http://www.mozilla.org/docs/refList/refNSPR/">
Netscape's Portable Run Time</A>, which
<A HREF="http://www.arctic.org/~dgaudet/apache/2.0/">is available</A>
Each VirtualHost must correspond to a different IP address, different port
number or a
-different host name for the server, in the latter case the server
+different host name for the server, in the former case the server
machine must be configured to accept IP packets for multiple
addresses. (If the machine does not have multiple network interfaces,
then this can be accomplished with the <CODE>ifconfig alias</CODE>
<P>
If no <EM>status</EM> argument is given, the redirect will be
"temporary" (HTTP status 302). This indicates to the client that the
-resources is has moved temporarily. The <EM>status</EM>
+resource has moved temporarily. The <EM>status</EM>
argument can be used to return other HTTP status codes:
<P>
<DL>
directive then requests to that IP address will only ever be served
by matching <VirtualHost>s. The "main server" will
<STRONG>never</STRONG> be served from the specified IP address.
-If you start to use virtual hosts you should stop to use the "main server"
+If you start to use virtual hosts you should stop using the "main server"
as an independent server and rather use it as a place for
configuration directives that are common for all your virtual hosts.
In other words, you should add a <VirtualHost> section for
directive then requests to that IP address will only ever be served
by matching <VirtualHost>s. The "main server" will
<STRONG>never</STRONG> be served from the specified IP address.
-If you start to use virtual hosts you should stop to use the "main server"
+If you start to use virtual hosts you should stop using the "main server"
as an independent server and rather use it as a place for
configuration directives that are common for all your virtual hosts.
In other words, you should add a <VirtualHost> section for
projects / apache / commitdiff