+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>Apache non-IP Virtual Hosts</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 non-IP Virtual Hosts</H1>
-
-<STRONG>See Also:</STRONG>
-<A HREF="virtual-host.html">Virtual Host Support</A>
-
-<HR>
-
-<H2>What is a Virtual Host</H2>
-
-<P>The "Virtual Host" refers to the practice of maintaining more than
-one server on one machine, as differentiated by their apparent
-hostname. For example, it is often desirable for companies sharing a
-web server to have their own domains, with web servers accessible as
-<CODE>www.company1.com</CODE> and <CODE>www.company2.com</CODE>,
-without requiring the user to know any extra path information.</P>
-
-<P>Apache was one of the first servers to support virtual hosts right
-out of the box, but since the base <CODE>HTTP</CODE> (HyperText
-Transport Protocol) standard does not allow any method for the server
-to determine the hostname it is being addressed as, Apache's virtual
-host support has required a separate IP address for each
-server. Documentation on using this approach (which still works very
-well) <A HREF="virtual-host.html">is available</A>.
-
-<P>While the approach described above works, with the available IP
-address space growing smaller, and the number of domains increasing,
-it is not the most elegant solution, and is hard to implement on some
-machines. The <CODE>HTTP/1.1</CODE> protocol contains a method for the
-server to identify what name it is being addressed as. Apache 1.1 and
-later support this approach as well as the traditional
-IP-address-per-hostname method.</P>
-
-<P>The benefits of using the new virtual host support is a practically
-unlimited number of servers, ease of configuration and use, and
-requires no additional hardware or software. The main disadvantage is
-that the user's browser must support this part of the protocol. The
-latest versions of many browsers (including Netscape Navigator 2.0 and
-later) do, but many browsers, especially older ones, do not. This can
-cause problems, although a possible solution is addressed below.</P>
-
-<H2>Using non-IP Virtual Hosts</H2>
-
-<P>Using the new virtual hosts is quite easy, and superficially looks
-like the old method. You simply add to one of the Apache configuration
-files (most likely <CODE>httpd.conf</CODE> or <CODE>srm.conf</CODE>)
-code similar to the following:</P>
-<PRE>
- <VirtualHost www.apache.org>
- ServerName www.apache.org
- DocumentRoot /usr/web/apache
- </VirtualHost>
-</PRE>
-
-<P>Of course, any additional directives can (and should) be placed
-into the <CODE><VirtualHost></CODE> section. To make this work,
-all that is needed is to make sure that the <CODE>www.apache.org</CODE>
-DNS entry points to the same IP address as the main
-server. Optionally, you could simply use that IP address in the
-<VirtualHost> entry.</P>
-
-<P>Additionally, many servers may wish to be accessible by more than
-one name. For example, the Apache server might want to be accessible
-as <CODE>apache.org</CODE>, or <CODE>ftp.apache.org</CODE>, assuming
-the IP addresses pointed to the same server. In fact, one might want it
-so that all addresses at <CODE>apache.org</CODE> were picked up by the
-server. This is possible with the <CODE>ServerAlias</CODE>
-directive, placed inside the <VirtualHost> section. For
-example:</P>
-
-<PRE>
- ServerAlias apache.org *.apache.org
-</PRE>
-
-<P>Note that you can use <CODE>*</CODE> and <CODE>?</CODE> as wild-card
-characters.</P>
-
-<P>You also might need ServerAlias if you are serving local users who
-do not always include the domain name. For example, if local users are
-familiar with typing "www" or "www.physics" then you will need to add
-<CODE>ServerAlias www www.physics</CODE>. It isn't possible for the
-server to know what domain the client uses for their name resolution
-because the client doesn't provide that information in the request.</P>
-
-<H2>Security Considerations</H2>
-
-Apache allows all virtual hosts to be made accessible via the
-<CODE>Host:</CODE> header through all IP interfaces, even those which
-are configured to use different IP interfaces. For example, if the
-configuration for <CODE>www.foo.com</CODE> contained a virtual host
-section for <CODE>www.bar.com</CODE>, and <CODE>www.bar.com</CODE> was
-a separate IP interface, such that
-non-<CODE>Host:</CODE>-header-supporting browsers can use it, as
-before with Apache 1.0. If a request is made to
-<CODE>www.foo.com</CODE> and the request includes the header
-<CODE>Host: www.bar.com</CODE>, a page from <CODE>www.bar.com</CODE>
-will be sent.
-
-<P>
-
-This is a security concern if you are controlling access to a
-particular server based on IP-layer controls, such as from within a
-firewall or router. Let's say <CODE>www.bar.com</CODE> in the above
-example was instead an intra-net server called
-<CODE>private.foo.com</CODE>, and the router used by foo.com only let
-internal users access <CODE>private.foo.com</CODE>. Obviously,
-<CODE>Host:</CODE> header functionality now allows someone who has
-access to <CODE>www.foo.com</CODE> to get
-<CODE>private.foo.com</CODE>, if they send a <CODE>Host:
-private.foo.com</CODE> header. It is important to note that this
-condition exists only if you only implement this policy at the IP
-layer - all security controls used by Apache (<EM>i.e.</EM>, <A
-HREF="../mod/mod_access.html">Allow, Deny from,</A> <EM>etc.</EM>) are
-consistently respected.
-
-<H2>Compatibility with Older Browsers</H2>
-
-<P>As mentioned earlier, a majority of browsers do not send the
-required data for the new virtual hosts to work properly. These
-browsers will always be sent to the main server's pages. There is a
-workaround, albeit a slightly cumbersome one:</P>
-
-<P>To continue the <CODE>www.apache.org</CODE> example (Note: Apache's
-web server does not actually function in this manner), we might use the
-new <CODE>ServerPath</CODE> directive in the <CODE>www.apache.org</CODE>
-virtual host, for example:
-
-<PRE>
- ServerPath /apache
-</PRE>
-<P>What does this mean? It means that a request for any file beginning
-with "<CODE>/apache</CODE>" will be looked for in the Apache
-docs. This means that the pages can be accessed as
-<CODE>http://www.apache.org/apache/</CODE> for all browsers, although
-new browsers can also access it as
-<CODE>http://www.apache.org/</CODE>.</P>
-
-<P>In order to make this work, put a link on your main server's page
-to <CODE>http://www.apache.org/apache/</CODE> (Note: Do not use
-<CODE>http://www.apache.org/</CODE> - this would create an endless
-loop). Then, in the virtual host's pages, be sure to use either purely
-relative links (<EM>e.g.</EM>, "<CODE>file.html</CODE>" or
-"<CODE>../icons/image.gif</CODE>" or links containing the prefacing
-<CODE>/apache/</CODE>
-(<EM>e.g.</EM>, "<CODE>http://www.apache.org/apache/file.html</CODE>" or
-"<CODE>/apache/docs/1.1/index.html</CODE>").</P>
-
-<P>This requires a bit of
-discipline, but adherence to these guidelines will, for the most part,
-ensure that your pages will work with all browsers, new and old. When
-a new browser contacts <CODE>http://www.apache.org/</CODE>, they will
-be directly taken to the Apache pages. Older browsers will be able to
-click on the link from the main server, go to
-<CODE>http://www.apache.org/apache/</CODE>, and then access the
-pages.</P>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>An In-Depth Discussion of VirtualHost Matching</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">An In-Depth Discussion of VirtualHost Matching</H1>
-
-<P>This is a very rough document that was probably out of date the moment
-it was written. It attempts to explain exactly what the code does when
-deciding what virtual host to serve a hit from. It's provided on the
-assumption that something is better than nothing. The server version
-under discussion is Apache 1.2.
-
-<P>If you just want to "make it work" without understanding
-how, there's a <A HREF="#whatworks">What Works</A> section at the bottom.
-
-<H3>Config File Parsing</H3>
-
-<P>There is a main_server which consists of all the definitions appearing
-outside of <CODE>VirtualHost</CODE> sections. There are virtual servers,
-called <EM>vhosts</EM>, which are defined by
-<A
- HREF="../mod/core.html#virtualhost"
-><SAMP>VirtualHost</SAMP></A>
-sections.
-
-<P>The directives
-<A
- HREF="../mod/core.html#port"
-><SAMP>Port</SAMP></A>,
-<A
- HREF="../mod/core.html#servername"
-><SAMP>ServerName</SAMP></A>,
-<A
- HREF="../mod/core.html#serverpath"
-><SAMP>ServerPath</SAMP></A>,
-and
-<A
- HREF="../mod/core.html#serveralias"
-><SAMP>ServerAlias</SAMP></A>
-can appear anywhere within the definition of
-a server. However, each appearance overrides the previous appearance
-(within that server).
-
-<P>The default value of the <CODE>Port</CODE> field for main_server
-is 80. The main_server has no default <CODE>ServerName</CODE>,
-<CODE>ServerPath</CODE>, or <CODE>ServerAlias</CODE>.
-
-<P>In the absence of any
-<A
- HREF="../mod/core.html#listen"
-><SAMP>Listen</SAMP></A>
-directives, the (final if there
-are multiple) <CODE>Port</CODE> directive in the main_server indicates
-which port httpd will listen on.
-
-<P> The <CODE>Port</CODE> and <CODE>ServerName</CODE> directives for
-any server main or virtual are used when generating URLs such as during
-redirects.
-
-<P> Each address appearing in the <CODE>VirtualHost</CODE> directive
-can have an optional port. If the port is unspecified it defaults to
-the value of the main_server's most recent <CODE>Port</CODE> statement.
-The special port <SAMP>*</SAMP> indicates a wildcard that matches any port.
-Collectively the entire set of addresses (including multiple
-<SAMP>A</SAMP> record
-results from DNS lookups) are called the vhost's <EM>address set</EM>.
-
-<P> The magic <CODE>_default_</CODE> address has significance during
-the matching algorithm. It essentially matches any unspecified address.
-
-<P> After parsing the <CODE>VirtualHost</CODE> directive, the vhost server
-is given a default <CODE>Port</CODE> equal to the port assigned to the
-first name in its <CODE>VirtualHost</CODE> directive. The complete
-list of names in the <CODE>VirtualHost</CODE> directive are treated
-just like a <CODE>ServerAlias</CODE> (but are not overridden by any
-<CODE>ServerAlias</CODE> statement). Note that subsequent <CODE>Port</CODE>
-statements for this vhost will not affect the ports assigned in the
-address set.
-
-<P>
-All vhosts are stored in a list which is in the reverse order that
-they appeared in the config file. For example, if the config file is:
-
-<BLOCKQUOTE><PRE>
- <VirtualHost A>
- ...
- </VirtualHost>
-
- <VirtualHost B>
- ...
- </VirtualHost>
-
- <VirtualHost C>
- ...
- </VirtualHost>
-</PRE></BLOCKQUOTE>
-
-Then the list will be ordered: main_server, C, B, A. Keep this in mind.
-
-<P>
-After parsing has completed, the list of servers is scanned, and various
-merges and default values are set. In particular:
-
-<OL>
-<LI>If a vhost has no
- <A
- HREF="../mod/core.html#serveradmin"
- ><CODE>ServerAdmin</CODE></A>,
- <A
- HREF="../mod/core.html#resourceconfig"
- ><CODE>ResourceConfig</CODE></A>,
- <A
- HREF="../mod/core.html#accessconfig"
- ><CODE>AccessConfig</CODE></A>,
- <A
- HREF="../mod/core.html#timeout"
- ><CODE>Timeout</CODE></A>,
- <A
- HREF="../mod/core.html#keepalivetimeout"
- ><CODE>KeepAliveTimeout</CODE></A>,
- <A
- HREF="../mod/core.html#keepalive"
- ><CODE>KeepAlive</CODE></A>,
- <A
- HREF="../mod/core.html#maxkeepaliverequests"
- ><CODE>MaxKeepAliveRequests</CODE></A>,
- or
- <A
- HREF="../mod/core.html#sendbuffersize"
- ><CODE>SendBufferSize</CODE></A>
- directive then the respective value is
- inherited from the main_server. (That is, inherited from whatever
- the final setting of that value is in the main_server.)
-
-<LI>The "lookup defaults" that define the default directory
- permissions
- for a vhost are merged with those of the main server. This includes
- any per-directory configuration information for any module.
-
-<LI>The per-server configs for each module from the main_server are
- merged into the vhost server.
-</OL>
-
-Essentially, the main_server is treated as "defaults" or a
-"base" on
-which to build each vhost. But the positioning of these main_server
-definitions in the config file is largely irrelevant -- the entire
-config of the main_server has been parsed when this final merging occurs.
-So even if a main_server definition appears after a vhost definition
-it might affect the vhost definition.
-
-<P> If the main_server has no <CODE>ServerName</CODE> at this point,
-then the hostname of the machine that httpd is running on is used
-instead. We will call the <EM>main_server address set</EM> those IP
-addresses returned by a DNS lookup on the <CODE>ServerName</CODE> of
-the main_server.
-
-<P> Now a pass is made through the vhosts to fill in any missing
-<CODE>ServerName</CODE> fields and to classify the vhost as either
-an <EM>IP-based</EM> vhost or a <EM>name-based</EM> vhost. A vhost is
-considered a name-based vhost if any of its address set overlaps the
-main_server (the port associated with each address must match the
-main_server's <CODE>Port</CODE>). Otherwise it is considered an IP-based
-vhost.
-
-<P> For any undefined <CODE>ServerName</CODE> fields, a name-based vhost
-defaults to the address given first in the <CODE>VirtualHost</CODE>
-statement defining the vhost. Any vhost that includes the magic
-<SAMP>_default_</SAMP> wildcard is given the same <CODE>ServerName</CODE> as
-the main_server. Otherwise the vhost (which is necessarily an IP-based
-vhost) is given a <CODE>ServerName</CODE> based on the result of a reverse
-DNS lookup on the first address given in the <CODE>VirtualHost</CODE>
-statement.
-
-<P>
-
-<H3>Vhost Matching</H3>
-
-
-<P><STRONG>Apache 1.3 differs from what is documented
-here, and documentation still has to be written.</STRONG>
-
-<P>
-The server determines which vhost to use for a request as follows:
-
-<P> <CODE>find_virtual_server</CODE>: When the connection is first made
-by the client, the local IP address (the IP address to which the client
-connected) is looked up in the server list. A vhost is matched if it
-is an IP-based vhost, the IP address matches and the port matches
-(taking into account wildcards).
-
-<P> If no vhosts are matched then the last occurrence, if it appears,
-of a <SAMP>_default_</SAMP> address (which if you recall the ordering of the
-server list mentioned above means that this would be the first occurrence
-of <SAMP>_default_</SAMP> in the config file) is matched.
-
-<P> In any event, if nothing above has matched, then the main_server is
-matched.
-
-<P> The vhost resulting from the above search is stored with data
-about the connection. We'll call this the <EM>connection vhost</EM>.
-The connection vhost is constant over all requests in a particular TCP/IP
-session -- that is, over all requests in a KeepAlive/persistent session.
-
-<P> For each request made on the connection the following sequence of
-events further determines the actual vhost that will be used to serve
-the request.
-
-<P> <CODE>check_fulluri</CODE>: If the requestURI is an absoluteURI, that
-is it includes <CODE>http://hostname/</CODE>, then an attempt is made to
-determine if the hostname's address (and optional port) match that of
-the connection vhost. If it does then the hostname portion of the URI
-is saved as the <EM>request_hostname</EM>. If it does not match, then the
-URI remains untouched. <STRONG>Note</STRONG>: to achieve this address
-comparison,
-the hostname supplied goes through a DNS lookup unless it matches the
-<CODE>ServerName</CODE> or the local IP address of the client's socket.
-
-<P> <CODE>parse_uri</CODE>: If the URI begins with a protocol
-(<EM>i.e.</EM>, <CODE>http:</CODE>, <CODE>ftp:</CODE>) then the request is
-considered a proxy request. Note that even though we may have stripped
-an <CODE>http://hostname/</CODE> in the previous step, this could still
-be a proxy request.
-
-<P> <CODE>read_request</CODE>: If the request does not have a hostname
-from the earlier step, then any <CODE>Host:</CODE> header sent by the
-client is used as the request hostname.
-
-<P> <CODE>check_hostalias</CODE>: If the request now has a hostname,
-then an attempt is made to match for this hostname. The first step
-of this match is to compare any port, if one was given in the request,
-against the <CODE>Port</CODE> field of the connection vhost. If there's
-a mismatch then the vhost used for the request is the connection vhost.
-(This is a bug, see observations.)
-
-<P>
-If the port matches, then httpd scans the list of vhosts starting with
-the next server <STRONG>after</STRONG> the connection vhost. This scan does not
-stop if there are any matches, it goes through all possible vhosts,
-and in the end uses the last match it found. The comparisons performed
-are as follows:
-
-<UL>
-<LI>Compare the request hostname:port with the vhost
- <CODE>ServerName</CODE> and <CODE>Port</CODE>.
-
-<LI>Compare the request hostname against any and all addresses given in
- the <CODE>VirtualHost</CODE> directive for this vhost.
-
-<LI>Compare the request hostname against the <CODE>ServerAlias</CODE>
- given for the vhost.
-</UL>
-
-<P>
-<CODE>check_serverpath</CODE>: If the request has no hostname
-(back up a few paragraphs) then a scan similar to the one
-in <CODE>check_hostalias</CODE> is performed to match any
-<CODE>ServerPath</CODE> directives given in the vhosts. Note that the
-<STRONG>last match</STRONG> is used regardless (again consider the ordering of
-the virtual hosts).
-
-<H3>Observations</H3>
-
-<UL>
-
-<LI>It is difficult to define an IP-based vhost for the machine's
- "main IP address". You essentially have to create a bogus
- <CODE>ServerName</CODE> for the main_server that does not match the
- machine's IPs.
- <P>
-
-<LI>During the scans in both <CODE>check_hostalias</CODE> and
- <CODE>check_serverpath</CODE> no check is made that the vhost being
- scanned is actually a name-based vhost. This means, for example, that
- it's possible to match an IP-based vhost through another address. But
- because the scan starts in the vhost list at the first vhost that
- matched the local IP address of the connection, not all IP-based vhosts
- can be matched.
- <P>
- Consider the config file above with three vhosts A, B, C. Suppose
- that B is a named-based vhost, and A and C are IP-based vhosts. If
- a request comes in on B or C's address containing a header
- "<SAMP>Host: A</SAMP>" then
- it will be served from A's config. If a request comes in on A's
- address then it will always be served from A's config regardless of
- any Host: header.
- </P>
-
-<LI>Unless you have a <SAMP>_default_</SAMP> vhost,
- it doesn't matter if you mix name-based vhosts in amongst IP-based
- vhosts. During the <CODE>find_virtual_server</CODE> phase above no
- named-based vhost will be matched, so the main_server will remain the
- connection vhost. Then scans will cover all vhosts in the vhost list.
- <P>
- If you do have a <SAMP>_default_</SAMP> vhost, then you cannot place
- named-based vhosts after it in the config. This is because on any
- connection to the main server IPs the connection vhost will always be
- the <SAMP>_default_</SAMP> vhost since none of the name-based are
- considered during <CODE>find_virtual_server</CODE>.
- </P>
-
-<LI>You should never specify DNS names in <CODE>VirtualHost</CODE>
- directives because it will force your server to rely on DNS to boot.
- Furthermore it poses a security threat if you do not control the
- DNS for all the domains listed.
- <A HREF="dns-caveats.html">There's more information
- available on this and the next two topics</A>.
- <P>
-
-<LI><CODE>ServerName</CODE> should always be set for each vhost. Otherwise
- A DNS lookup is required for each vhost.
- <P>
-
-<LI>A DNS lookup is always required for the main_server's
- <CODE>ServerName</CODE> (or to generate that if it isn't specified
- in the config).
- <P>
-
-<LI>If a <CODE>ServerPath</CODE> directive exists which is a prefix of
- another <CODE>ServerPath</CODE> directive that appears later in
- the configuration file, then the former will always be matched
- and the latter will never be matched. (That is assuming that no
- Host header was available to disambiguate the two.)
- <P>
-
-<LI>If a vhost that would otherwise be a name-vhost includes a
- <CODE>Port</CODE> statement that doesn't match the main_server
- <CODE>Port</CODE> then it will be considered an IP-based vhost.
- Then <CODE>find_virtual_server</CODE> will match it (because
- the ports associated with each address in the address set default
- to the port of the main_server) as the connection vhost. Then
- <CODE>check_hostalias</CODE> will refuse to check any other name-based
- vhost because of the port mismatch. The result is that the vhost
- will steal all hits going to the main_server address.
- <P>
-
-<LI>If two IP-based vhosts have an address in common, the vhost appearing
- later in the file is always matched. Such a thing might happen
- inadvertently. If the config has name-based vhosts and for some reason
- the main_server <CODE>ServerName</CODE> resolves to the wrong address
- then all the name-based vhosts will be parsed as ip-based vhosts.
- Then the last of them will steal all the hits.
- <P>
-
-<LI>The last name-based vhost in the config is always matched for any hit
- which doesn't match one of the other name-based vhosts.
-
-</UL>
-
-<H3><A NAME="whatworks">What Works</A></H3>
-
-<P>In addition to the tips on the <A HREF="dns-caveats.html#tips">DNS
-Issues</A> page, here are some further tips:
-
-<UL>
-
-<LI>Place all main_server definitions before any VirtualHost definitions.
-(This is to aid the readability of the configuration -- the post-config
-merging process makes it non-obvious that definitions mixed in around
-virtualhosts might affect all virtualhosts.)
-<P>
-
-<LI>Arrange your VirtualHosts such
-that all name-based virtual hosts come first, followed by IP-based
-virtual hosts, followed by any <SAMP>_default_</SAMP> virtual host
-<P>
-
-<LI>Avoid <CODE>ServerPaths</CODE> which are prefixes of other
-<CODE>ServerPaths</CODE>. If you cannot avoid this then you have to
-ensure that the longer (more specific) prefix vhost appears earlier in
-the configuration file than the shorter (less specific) prefix
-(<EM>i.e.</EM>, "ServerPath /abc" should appear after
-"ServerPath /abcdef").
-<P>
-
-<LI>Do not use <EM>port-based</EM> vhosts in the same server as
-name-based vhosts. A loose definition for port-based is a vhost which
-is determined by the port on the server (<EM>i.e.</EM>, one server with
-ports 8000, 8080, and 80 - all of which have different configurations).
-<P>
-
-</UL>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Apache Server Virtual Host Support</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">Virtual Host Support</H1>
-
-<STRONG>See Also:</STRONG>
-<A HREF="host.html">Non-IP based virtual hosts</A>
-
-<H2>What are virtual hosts?</H2>
-This is the ability of a single machine to be a web server for multiple
-domains. For example, an Internet service provider might have a machine
-called <CODE>www.serve.com</CODE> which provides Web space for several
-organizations including, say, <EM>smallco</EM> and <EM>baygroup</EM>.
-Ordinarily, these groups would be given parts of the Web tree on www.serve.com.
-So smallco's home page would have the URL
-<BLOCKQUOTE>
-http://www.serve.com/smallco/
-</BLOCKQUOTE>
-and baygroup's home page would have the URL
-<BLOCKQUOTE>
-http://www.serve.com/baygroup/
-</BLOCKQUOTE>
-<P>
-For esthetic reasons, however, both organizations would rather their home
-pages appeared under their own names rather than that of the service
-provider's; but they do not want to set up their own Internet links and
-servers.
-<P>
-Virtual hosts are the solution to this problem. smallco and baygroup would
-have their own Internet name registrations, <CODE>www.smallco.com</CODE> and
-<CODE>www.baygroup.org</CODE> respectively. These hostnames would both
-correspond to the service provider's machine (www.serve.com). Thus
-smallco's home page would now have the URL
-<BLOCKQUOTE>
-http://www.smallco.com/
-</BLOCKQUOTE>
-and baygroup's home page would would have the URL
-<BLOCKQUOTE>
-http://www.baygroup.org/
-</BLOCKQUOTE>
-
-<H2>System requirements</H2>
-Due to limitations in the HTTP/1.0 protocol, the web server <STRONG>must have a
-different IP address for each virtual host</STRONG>. This can be achieved
-by the machine having several physical network connections, or by use
-of a <A HREF="../misc/vif-info.html">virtual interface</A> on some operating
-systems.
-
-<H2>How to set up Apache</H2>
-There are two ways of configuring apache to support multiple hosts.
-Either by running a separate httpd daemon for each hostname, or by running a
-single daemon which supports all the virtual hosts.
-<P>
-Use multiple daemons when:
-<UL>
-<LI>The different virtual hosts need very different httpd configurations, such
- as different values for:
- <A HREF="../mod/core.html#servertype">ServerType</A>,
- <A HREF="../mod/core.html#user">User</A>,
- <A HREF="../mod/core.html#group">Group</A>,
- <A HREF="../mod/mod_mime.html#typesconfig">TypesConfig</A> or
- <A HREF="../mod/core.html#serverroot">ServerRoot</A>.
-<LI>The machine does not process a very high request rate.
-</UL>
-Use a single daemon when:
-<UL>
-<LI>Sharing of the httpd configuration between virtual hosts is acceptable.
-<LI>The machine services a large number of requests, and so the performance
- loss in running separate daemons may be significant.
-</UL>
-
-<H2>Setting up multiple daemons</H2>
-Create a separate httpd installation for each virtual host.
-For each installation, use the
-<A HREF="../mod/core.html#bindaddress">BindAddress</A> directive in the
-configuration
-file to select which IP address (or virtual host) that daemon services.
-<EM>E.g.</EM>,
-<BLOCKQUOTE><CODE>BindAddress www.smallco.com</CODE></BLOCKQUOTE>
-This hostname can also be given as an IP address.
-
-<H2>Setting up a single daemon</H2>
-For this case, a single httpd will service requests for all the virtual hosts.
-The <A HREF="../mod/core.html#virtualhost">VirtualHost</A> directive in the
- configuration file is used to set the values of
-<A HREF="../mod/core.html#serveradmin">ServerAdmin</A>,
-<A HREF="../mod/core.html#servername">ServerName</A>,
-<A HREF="../mod/core.html#documentroot">DocumentRoot</A>,
-<A HREF="../mod/core.html#errorlog">ErrorLog</A> and
-<A HREF="../mod/mod_log_config.html#transferlog">TransferLog</A> configuration
-directives to different values for each virtual host.
-<EM>E.g.</EM>,
-<BLOCKQUOTE><CODE>
-<VirtualHost www.smallco.com><BR>
-ServerAdmin webmaster@mail.smallco.com<BR>
-DocumentRoot /groups/smallco/www<BR>
-ServerName www.smallco.com<BR>
-ErrorLog /groups/smallco/logs/error_log<BR>
-TransferLog /groups/smallco/logs/access_log<BR>
-</VirtualHost><BR>
-<BR>
-<VirtualHost www.baygroup.org><BR>
-ServerAdmin webmaster@mail.baygroup.org<BR>
-DocumentRoot /groups/baygroup/www<BR>
-ServerName www.baygroup.org<BR>
-ErrorLog /groups/baygroup/logs/error_log<BR>
-TransferLog /groups/baygroup/logs/access_log<BR>
-</VirtualHost><BR>
-</CODE></BLOCKQUOTE>
-
-This VirtualHost hostnames can also be given as IP addresses.
-
-<P>
-
-Almost <STRONG>ANY</STRONG> configuration directive can be put
-in the VirtualHost directive, with the exception of
-<A HREF="../mod/core.html#servertype">ServerType</A>,
-<A HREF="../mod/core.html#user">User</A>,
-<A HREF="../mod/core.html#group">Group</A>,
-<A HREF="../mod/core.html#startservers">StartServers</A>,
-<A HREF="../mod/core.html#maxspareservers">MaxSpareServers</A>,
-<A HREF="../mod/core.html#minspareservers">MinSpareServers</A>,
-<A HREF="../mod/core.html#maxrequestsperchild">MaxRequestsPerChild</A>,
-<A HREF="../mod/core.html#bindaddress">BindAddress</A>,
-<A HREF="../mod/core.html#pidfile">PidFile</A>,
-<A HREF="../mod/mod_mime.html#typesconfig">TypesConfig</A>, and
-<A HREF="../mod/core.html#serverroot">ServerRoot</A>.
-
-<P>
-
-<EM>SECURITY:</EM> When specifying where to write log files, be aware
-of some security risks which are present if anyone other than the
-user that starts Apache has write access to the directory where they
-are written. See the <A HREF="../misc/security_tips.html">security
-tips</A> document for details.
-
-<P>
-
-<H2>File Handle/Resource Limits:</H2>
-When using a large number of Virtual Hosts, Apache may run out of available
-file descriptors if each Virtual Host specifies different log files.
-The total number of file descriptors used by Apache is one for each distinct
-error log file, one for every other log file directive, plus 10-20 for
-internal use. Unix operating systems limit the number of file descriptors that
-may be used by a process; the limit is typically 64, and may usually be
-increased up to a large hard-limit.
-<P>
-Although Apache attempts to increase the limit as required, this
-may not work if:
-<OL>
-<LI>Your system does not provide the setrlimit() system call.
-<LI>The setrlimit(RLIMIT_NOFILE) call does not function on your system
- (such as Solaris 2.3)
-<LI>The number of file descriptors required exceeds the hard limit.
-<LI>Your system imposes other limits on file descriptors, such as a limit
-on stdio streams only using file descriptors below 256. (Solaris 2)
-</OL>
-
-In the event of problems you can:
-<UL>
-<LI>Reduce the number of log files; don't specify log files in the VirtualHost
-sections, but only log to the main log files.
-<LI>If you system falls into 1 or 2 (above), then increase the file descriptor
-limit before starting Apache, using a script like
-<BLOCKQUOTE><CODE>
-#!/bin/sh <BR>
-ulimit -S -n 100 <BR>
-exec httpd</CODE></BLOCKQUOTE>
-</UL>
-
-The have been reports that Apache may start running out of resources allocated
-for the root process. This will exhibit itself as errors in the error log like
-"unable to fork". There are two ways you can bump this up:
-
-<OL>
-<LI>Have a <CODE>csh</CODE> script wrapper around httpd which sets the
-"rlimit" to some large number, like 512.
-<LI>Edit http_main.c to add calls to setrlimit() from main(), along the lines
-of
-<PRE>
- struct rlimit rlp;
-
- rlp.rlim_cur = rlp.rlim_max = 512;
- if (setrlimit(RLIMIT_NPROC, &rlp)) {
- fprintf(stderr, "setrlimit(RLIMIT_NPROC) failed.\n");
- exit(1);
- }
-</PRE>
-(thanks to "Aaron Gifford <agifford@InfoWest.COM>" for the patch)
-</OL>
-
-The latter will probably manifest itself in a later version of Apache.
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
projects / apache / commitdiff