Chapter 15: Shared Tomcat Hosting address ( http://192.168.1.2), Apache is not able to resolve which Web site to serve and will serve you content from the default virtual host, which is the first one listed in the httpd.conffile in this case, europa.dom. Avoiding Common Issues Some common issues to avoid in name-based virtual hosting include the following: . If a Web request has been made to an IP address listed in the NameVirtualHostand the applicable virtual host could not be determined, Apache sends the request to the first virtual host block in the Apache configuration for that IP address. The request is not sent to the default document root of the whole server. Therefore, the first section for every NameVirtualHost IP address should be a domain where unresolved Web requests could also be handled. . It is not possible to have SSL/HTTPS support using name-based virtual hosts because of the nature of the SSL protocol itself. For establishing the connection between the client and server, the SSL protocol parameters first need to be negotiated. For this to happen, the client has to know which server to connect to, which can t happen as the Host:header hasn t yet been exchanged to determine which virtual host to send the request to. This chicken-and-egg issue is the reason why each SSL-enabled Web site must be configured on a unique IP address. The only option here is to use IP-based virtual hosting. . Older Web clients and many Web access software libraries still use the old HTTP 1.0 protocol. Because they don t send the Host: header to the Web server, name-based virtual hosting would not work properly with them. However, these incompatible clients are incredibly rare. It is unlikely that excluding them from a list of supported clients would cause a significant problem. All major browsers, such as Firefox, Netscape (version 2.0+), Internet Explorer (version 3.0+), and Lynx (1995+), support the Host:header. Virtual Hosting in Tomcat The preceding section explained how to configure Apache to support virtual hosts. This section contains the main focus of this chapter: virtual host support in Tomcat. Before reading further, it is important to consider what would be expected from Tomcat in a shared hosting environment. Tomcat could work either in a standalone mode (in which it includes support for both an HTTP server and the JSP/Servlet container) or in a cooperative manner (with a Web server such as Apache). Chapter 11 provides details on various ways to set up Tomcat with the Apache Web server. Expecting Tomcat to provide virtual hosting support would mean the following: Given that two or more Web hosts are served from the same machine, when a request comes for a particular resource on one of these hosts, Tomcat should be able to successfully identify the host for which the request had been received, and fetch the required resource from the host document base. For Tomcat working in a standalone mode, the request in question can target static pages, as well as JSP and servlets. When working along with another Web server such as Apache, the Web server itself handles the virtual hosts and the processing of subsequent static pages. Therefore, the only thing that
For high quality java hosting services please check tomcat web hosting website.
This entry was posted
on Wednesday, September 23rd, 2009 at 5:06 am and is filed under tomcat.
You can follow any responses to this entry through the RSS 2.0 feed.
Responses are currently closed, but you can trackback from your own site.