This link has been bookmarked by 49 people . It was first bookmarked on 30 Jul 2006, by Matt Clausen.
-
08 Oct 14
-
19 Aug 13
-
25 May 12
-
Some ancient clients are not compatible with name-based virtual hosting. For name-based virtual hosting to work, the client must send the HTTP Host header. This is required by HTTP/1.1, and is implemented by all modern HTTP/1.0 browsers as an extension. If you need to support obsolete clients and still use name-based virtual hosting, a possible technique is discussed at the end of this document.
-
Name-based virtual hosting cannot be used with SSL secure servers because of the nature of the SSL protocol.
-
-
12 Apr 12
-
need to
-
IP address
-
determine
-
correct virtual host to serve
-
separate IP address for each host
-
IP-based
-
server relies on the client to report the hostname as part of the HTTP headers
-
name-based
-
many different hosts
-
can share the same IP address
-
-
13 Feb 12
-
20 Jan 12
-
05 May 11
-
25 Mar 10
-
14 Jan 10
-
27 Dec 09
-
20 Nov 09
-
IP-based virtual hosts use the IP address of the connection to determine the correct virtual host to serve. Therefore you need to have a separate IP address for each host.
-
Name-based virtual hosting is usually simpler, since you need only configure your DNS server to map each hostname to the correct IP address and then configure the Apache HTTP Server to recognize the different hostnames.
-
Name-based virtual hosting cannot be used with SSL secure servers because of the nature of the SSL protocol.
-
The wildcard characters
*and?can be used to match names. Of course, you can't just make up names and place them inServerNameorServerAlias. You must first have your DNS server properly configured to map those names to an IP address associated with your server.
-
-
03 Nov 09
-
01 Nov 09
-
26 Dec 08
-
20 Oct 08
-
27 May 08
-
14 Apr 08
-
22 Mar 08
-
In the normal case where any and all IP addresses on the server should be used, you can use
*as the argument toNameVirtualHost. -
The argument to the
<VirtualHost>directive should be the same as the argument to theNameVirtualHostdirective (ie, an IP address, or*for all addresses) -
If you are adding virtual hosts to an existing web server, you must also create a
<VirtualHost>block for the existing host. TheServerNameandDocumentRootincluded in this virtual host should be the same as the globalServerNameandDocumentRoot. List this virtual host first in the configuration file so that it will act as the default host. -
ServerAlias domain.tld *.domain.tldthen requests for all hosts in the
domain.tlddomain will be served by thewww.domain.tldvirtual host. The wildcard characters*and?can be used to match names. -
the first listed virtual host is the default virtual host. The
DocumentRootfrom the main server will never be used when an IP address matches theNameVirtualHostdirective. If you would like to have a special configuration for requests that do not match any particular virtual host, simply put that configuration in a<VirtualHost>container and list it first in the configuration file.
-
-
07 Nov 07
-
05 Oct 07
-
19 Sep 07
-
24 Mar 07
-
13 Apr 06
-
19 Feb 06
-
The next step is to create a
block for each different host that you would like to serve. The argument to the directive should be the same as the argument to the NameVirtualHost directive (ie, an IP address, or * for all addresses). Inside each block, you will need at minimum a ServerName directive to designate which host is served and a DocumentRoot directive to show where in the filesystem the content for that host lives.
-
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.