Understanding Directives and More with the Oracle HTTP Server - Virtual Hosting
(Page 4 of 4 )
Virtual hosting is the maintenance of multiple Web sites on a single machine. For example, you may run both www.mycompany1.com and www.mycompany2.com Web sites from the same server. You can define IP-based or name-based virtual hosts using the VirtualHost directive. IP-based virtual hosts have different IP addresses for each Web site. Name-based virtual hosts run multiple names on a single IP address.
You use the <VirtualHost> container to enclose a set of directives that apply only to a named virtual host. You may place any directive that can be used in a virtual host context in the virtual host container. When OHS receives a client request for a document that's on a virtual host, OHS will use the configuration directives for that virtual host's virtual host container. Using the <VirtualHost> container directive, you can specify the following alternative directives to the main HTTP server:
- ServerAdmin
- ServerName
- DocumentRoot
- ErrorLog
- CustomLog
Here's how you use the <VirtualHost> directive to specify additional hosts:
<VirtualHost www.myhost1.com> DocumentRoot /usr/virtual/htdocs/info ServerName www.myhost1.com ErrorLog /usr/virtual/h1/logs/error_log </VirtualHost>
<VirtualHost www.myhost2.com> DocumentRoot /usr/virtual/htdocs/finance ServerName www.myhost2.com
ErrorLog /usr/virtual/h2/logs/error_log </VirtualHost>
The foregoing example uses a name-based virtual hosting system. Here's an example showing a virtual host that's IP based:
<VirtualHost 172.14.12.14 205.123.33.199>
ServerName www.myhost.com
ServerAdmin Webmaster@myhost.com DocumentRoot /docs/myhost/www ErrorLog /docs/myhost/logs/error_log TransferLog /docs/myhost/logs/access_log </VirtualHost>
exam watch: Name-based virtual hosting means that you’ll have multiple Web sites for each IP address, and IP-based virtual hosting means that you’ll have an address for each Web site.
IP-Based Virtual Hosts
You must provide a different IP address for each IP-based virtual host, either by setting up your machine within multiple physical network connections, or by using virtual interfaces called "ip aliases." You can run multiple httpd daemons to support the different IP-based virtual hosts, or you can continue to use the default setup of a single httpd daemon. In our examples in this section, the single httpd daemon mode is assumed.
You can configure multiple hosts on a single server, using a separate VirtualHost directive for each virtual host. You can't use the following HTTP Server directives in a VirtualHost directive, because they can be used only in the server configuration context:
- ServerType
- StartServers
- MaxSpareServers
- MinSpareServers
- MaxRequestsPerChild
- BindAddress
- Listen
- PidFile
- TypesConfig
- ServerRoot
- NameVirtualHost
Here's an example showing how you use the <VirtualHost> container to set up different configuration values for the ServerAdmin, ServerName, DocumentRoot, ErrorLog, and TransferLog or CustomLog configuration directives for the two virtual hosts defined here:
<VirtualHost 10.0.0.1>
ServerName www.newco.com
ServerAdmin webmaster@mail.newco.com
DocumentRoot /groups/newco/www
ServerName www.newco.com
ErrorLog /groups/newco/logs/error_log
TransferLog /groups/newco/logs/access_log
</VirtualHost>
<VirtualHost 10.0.0.2>
ServerName www.citygroup.org
ServerAdmin webmaster@mail.citygroup.org
DocumentRoot /groups/citigroup/www
ServerName www.citigroup.org
ErrorLog
/groups/citigroup/logs/error_log
TransferLog
/groups/citigroup/logs/access_log
</VirtualHost>
Name-Based Virtual Hosts
In an IP-based virtual hosting system, each virtual host will need a separate IP address, because the virtual host uses the IP address to determine which host to serve. This forces you to have multiple IP addresses, one for each virtual host you wish to set up. When you use name-based virtual hosting, the HTTP Server expects the client to supply the hostname as part of the HTTP header information. This way, several hosts can share a single IP address.
It's very simple to configure name-based virtual hosting. All you need to do is to configure the DNS server to map host names to their correct IP addresses and then configure OHS so it can recognize the multiple host names. Name-based virtual hosting means you'll need fewer hard-to-acquire IP addresses. Unless you have strong reasons for doing so, you should use name-based virtual hosting. Following are some of those reasons:
- If you're supporting some obsolete clients, you may find that they aren't compatible with name-based virtual hosting.
- You may not be able to use name-based virtual hosting with some SSL secure servers.
- There are some operating system and network bandwidth management techniques that can't distinguish between hosts unless they are on distinct IP addresses.
You must use the NameVirtualHost directive to designate the IP address on the server that will accept requests for the name-based virtual hosts. If you want any or all IP addresses on the server to be used, you must provide * as the argument to the NameVirtualHost directive. Make sure that the IP address you specify is associated with a network interface on the server. You must provide a port argument (*:80, for example) if you intend to use multiple ports.
Once you do specify the NameVirtualHost directive, you must specify a <VirtualHost> block for each of the virtual hosts you wish to serve. You provide arguments to the <VirtualHost> directive that are similar to those you use for the NameVirtualHost directive. You need at least the following two directives inside each <VirtualHost> directive:
- The ServerName directive to designate the host to be served
- The DocumentRoot directive to indicate the directory where the host's contents are stored
In the following example, originally you have the domain www.mydomain.com. You now wish to add the virtual host www.myotherdomain.com, pointing to the same IP address. Here's how your httpd.conf file will look:
NameVirtualHost *:80
<VirtualHost *:80>
ServerName www.mydomain.com
ServerAlias mydomain.com *.mydomain.com
DocumentRoot /www/mydomain
</VirtualHost>
<VirtualHost *:80>
ServerName www.myotherdomain.com
ServerAlias mydomain.com *.mydomain.com
DocumentRoot /www/myotherdomain
</VirtualHost>
exam watch: You can also specify an IP address in place of the * in both the NameVirtualHost and <VirtualHost> directives. You may do this if you wish to run name-based virtual hosts on one IP
address and either IP-based or another set of name-based virtual hosts on another address.
The ServerAlias directive inside the first <VirtualHost> block, shown as follows, indicates that the name inside is an alternative name that clients can use to access the same Web site.
ServerAlias domain.com *.com.
Once you specify the <VirtualHost> directive in the manner shown in the preceding example, all requests for hosts in the domain.com domain will be served by the virtual host www.domain.com You must make sure that you configure your DNS server to map the names to an actual IP address on your server.
on the job: Any configuration directives set in the main server context (that is, outside the <VirtualHost> container) will be used only if they are not overridden by any
virtual host settings.
When a client connects to the Web address, the HTTP server will first check whether the client is the IP address specified by the NameVirtualHost directive. If so, the server will check for a matching IP address in one of the <VirtualHost> sections and look for a matching ServerName or ServerAlias for the requested host name. If it can't find any matching host names, it uses the first listed virtual host that matches the IP address. In order to provide a special configuration for client requests that don't match any of your virtual hosts, all you have to do is put that configuration in the first <VirtualHost> container in the httpd.conf file.
The first listed virtual host is the default virtual host. When an IP address matches the NameVirtualHost directive, the HTTP Server will not use the DocumentRoot for the main server.
Please check back next week for the conclusion of this article.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
|
This article is excerpted from chapter five of the book Oracle 10g Application Server Exam Guide, written by Sam Alapati (McGraw-Hill, 2006; ISBN: 0072262710). Check it out today at your favorite bookstore. Buy this book now.
|
|