Configuring directory listings - Quick guide to Apache contexts and request routing

Chapter 3. Quick guide to Apache contexts and request routing

3.5 Configuring directory listings

Let's examine some very powerful concepts of the HTTP Server (powered by Apache) configuration GUI. When you request the URL http://<system_name>:8099 (where

<system_name> is the name of your system), you configure the server to display the home page, usually a file named index.html in the directory defined as the DocumentRoot

/ITSO/ITSO99/ITSOco). We override this default behavior to display the contents of a subdirectory (that is, /ITSO/ITSO99/ITSOco/Downloads) instead of the Web page. Apache displays the contents as a list of files and attributes with file names automatically made "hot"

so that clicking on one downloads the corresponding file.

At the Configuration screen shown in Figure 3-1, in the menu on the left, you select the context you want to work with under the Configuration structure and then select the forms and wizards you need on the right-hand side. We don't have a context for the

/ITSO/ITSO99/ITSOco/Downloads subdirectory, so we must create one.

Figure 3-1 Configuring directory listings: Root and the DocumentRoot are the only contexts Follow these steps (note that the numbers correspond to those in Figure 3-1):

1. In the menu on the left, under Configuration structure, select your server name global settings. In this example, we select ITSO99 global settings.

2. In the menu on the right, under Web Site Definition, select Context Management. This brings up a new window as shown in Figure 3-1 on the right.

3. In the menu on the right, click Add. Enter a new Directory. For our example, we used /itso/itso99/itsoco/downloads.

4. Click OK.

You notice that the Configuration structure on the left side of the Configuration display is immediately updated with the new context <Directory /itso/itso99/itsoco/downloads>. It should look something like the example in Figure 3-2.

Figure 3-2 Configuring directory listings: Success at creating a new Directory context

Next, you enable directory listings in the subdirectory Downloads as shown in Figure 3-3. For security reasons, you don't want your server to display directory listings by default.

3 3

Chapter 3. Quick guide to Apache contexts and request routing 37 Figure 3-3 Configuring directory listings: Display directory listings for the Downloads subdirectory Follow these steps (note that the numbers correspond to those in Figure 3-3):

1. In the menu on the left, under Configuration structure, select Directory /itso/itso99/itsoco/downloads.

Notice that the groups of available configuration forms change immediately. If you didn't see the change, click your global settings and repeat the procedure. This is an important feature of the configuration GUI. That is when you select an Apache configuration context (that is, Directory, Files, VirtualHost and so on), the user interface shows you only the forms that you can apply to that context.

2. In the menu on the right, under Web Site Definition, select Welcome/Directory Listings.

This brings up a new window as shown in Figure 3-3 on the right.

3. Select Display directory listing for all directories.

4. Click OK.

You can review your changes by selecting Display Configuration File in the Configuration Files form group. While you're learning about configuring the HTTP Server (powered by Apache), it's a good idea to do this every time you make a change to your configuration.

You should now test the new configuration:

1. Restart the server.

2. Click Refresh to ensure that the server stays started (sometimes errors in the configuration can cause the server to stop).

3. Enter the following URL to test your directory listing:

http://as20:8099/Downloads/

You see a listing of files in the Downloads subdirectory much like the example in Figure 3-4.

For extra practice, you could make the directory listings "fancy" by using the Fancy/Customized Indexing form in the Web Site Definition form group.

Figure 3-4 Configuring directory listings:

The result is a listing of hot links to files in /Downloads

Part 2

How to...

As you prepare to use HTTP Server (powered by Apache), you may ask these questions:

򐂰 What is the best way to configure your Apache Web server to support multiple virtual hosts, and how do you do it?

򐂰 How do you implement security with HTTP Server (powered by Apache)?

򐂰 If you want to do more than just serve static Web pages, how do you serve up the dynamic data?

This part answers these questions and more. It instructs you on how to use virtual hosts, secure your server, and serve dynamic data with server-side includes (SSI), Net.Data, and CGI.

Part 2

Chapter 4.

Virtual hosts

The concept of virtual hosts in terms of Web serving refers to the practice of maintaining more than one domain in a single server. The way the domains are primarily differentiated is by their host name or IP address. Therefore, client requests are routed to the correct domain by IP address or by host name contained in the URL header. Traditionally virtual host implementation requires as many HTTP servers running simultaneously as domains the system is going to serve. Figure 4-1 illustrates the virtual host concept.

One of the most important features of the HTTP Server (powered by Apache) is the way this concept is

implemented. The HTTP Server (powered by Apache) allows us to use one HTTP server to host as many domains as the environment requires.

The virtual host concept is primarily used by Internet

Server Provider (ISPs), content providers, or companies that need to manage multiples domains, but they do not want to use a different server for each domain they want to serve.

For example, if two companies want to establish presence on the Internet without buying, building, and maintaining their own Web site, they can ask an ISP to host and publish their Web pages. The ISP then sets up the virtual host implementation so that each site looks like it is running on a different server. Each one of these servers is called a virtual host since they are really running on the same server.

Before implementing the virtual host concept using the HTTP Server (powered by Apache), let us review some of the concepts introduced by the HTTP Server (original) in this area and some information required to understand the HTTP Server (powered by Apache)

implementation.

4

Client with Web browser

iSeries

www.itso01.com www.itso02.com www.itso03.com

Figure 4-1 Virtual host concept

4.1 HTTP virtual host overview

If you need to use the iSeries server to host multiple domains, you need to think about:

򐂰 The way TCP/IP is configured

򐂰 The way the HTTP server will be configured

򐂰 The way the HTTP server will handle visitor requests

4.1.1 The way TCP/IP is configured

Your TCP/IP configuration depends on the number of physical network connections your server has, such as:

򐂰 One single IP address over one physical connection

򐂰 Multiple IP addresses over one physical connection

򐂰 Multiple IP addresses over multiple physical connections

Your iSeries server can be configured as a multi-homed server with multiple IP interfaces or virtual IP addresses. Any of those IP addresses can be used with the HTTP server to handle multiple domains in one iSeries server. For an alternative look at how to set up any of those TCP/IP approaches, refer to the redbook Application Service Provider Business Model:

Implementation on the iSeries Server, SG24-6053.

For your virtual host configuration, you need to identify the IP address, port, and domain name for each domain.

4.1.2 The way the HTTP server will be configured

The HTTP server can be configured to host:

򐂰 Multiple domains using one HTTP server

򐂰 Multiple domains using multiple HTTP servers, one for each domain

򐂰 A combination of both

Figure 4-2 shows some of the approaches you can use with your HTTP server to support multiple domains.

Figure 4-2 HTTP server instance approaches

HTTP server 1

HTTP server 2 HTTP server n

TCP/IP

Chapter 4. Virtual hosts 43 The HTTP configuration is different if the domains are served using one HTTP server or multiple HTTP servers, since each approach requires a different process and is based on different server directives, as explained in the Table 4-1.

Table 4-1 One and multiple server instances: Configuration comparison

The runtime environment of each approach also differs, as illustrated in Figure 4-2.

Table 4-2 One and multiple server instances: Running environment comparison

The information provided in Table 4-1 and Table 4-2 allows us to identify the differences between the two approaches. According to these tables, both HTTP server approaches process visitor requests correctly. Deciding between running under one or multiple HTTP servers usually depends more on the system resources, like memory and CPU. It also depends on security issues, like independency between domains. HTTP server directive limitations that could be used with any approach are not as important.

Unless, the multiple HTTP server approach allows you to achieve any specific requirement, we recommend that you use one HTTP server to host the domains, since you must only create and maintain one configuration file. The iSeries server has only one HTTP server to process the request, which saves memory and CPU resources for other system activities.

One HTTP server Multiple HTTP servers

One configuration file shared by all domains Multiple configuration files, one for each domain One or many access log and error log files Each configuration file includes its access and error

log files

One or many document root directories Many document root directories, one per configuration file

One or multiple IP addresses and ports within the server instance

One or multiple IP addresses and ports per configuration file

The HTTP server process uses the IP address or the domain to serve the request

The HTTP server process uses the IP address or the domain name to serve the request

Specific HTTP server directives to handle each domain

No specific server directives since each domain has its own configuration file

One HTTP server Multiple HTTP servers

All domains run under the same environment:

configuration file, process, and some service directives.

Each domain runs under its own environment:

configuration file, process, and server directives.

One process is started because there is only one HTTP server.

Many process are started since there are more than one HTTP server.

All the domains run under the same user profile, since there is only one server process. However, each one can be configured under a different security mechanism. Refer to Chapter 5,

“Defending the IFS” on page 75, for more information.

Each domain can run under its own user profile, since there are one process per domain. You can change the user profile on which the server instance runs, using the ServerUserID directive.

If you have problems with one domain, and the recovery procedure implies the HTTP server restart, all the domains served by the HTTP will be restarted.

If you have problems with one domain, the HTTP server associated with the domain can be restarted without affecting any other domain.

4.1.3 The way the HTTP server will handle visitor requests

The client submits a request. Based on information found in the header, the HTTP server will process the request. The HTTP server can use the domain name provided in the header or the translated IP address, depending on:

򐂰 The number of IP addresses your system has.

򐂰 The way your IP addresses are used by the system. The iSeries server can host intranet and Internet domains. If the iSeries server is used as a Web server in the Internet, you have to register every domain the system will use, which means more cost associated with the HTTP implementation.

򐂰 The version of the HTTP protocol supported in the environment considering HTTP Version 1.0 and HTTP Version 1.1. The HTTP Server (powered by Apache) and most of the Web client browsers support the HTTP 1.1 protocol. The differences between the protocols are:

– With the HTTP 1.0 protocol, the HTTP server relies on the DNS server to translate the domain name into the IP address. The HTTP server then uses the IP address to process the visitor request.

– With the HTTP 1.1 protocol, the domain name is included in the visitor request (as a header). Therefore, the HTTP server receives the domain name and can process the request according to the HTTP directives to include into the configuration file.

Because not all the client browsers support the HTTP Version 1.1 protocol, the HTTP server must be configured in a way that, regardless of the limitations the environment has, each client request will be handled correctly. To accomplish this, the HTTP Server (powered by Apache) supports three different virtual host implementations:

򐂰 IP based: The HTTP server uses the IP address to handle the visitors request. It can be used with HTTP 1.0. For more information about the IP-based implementation, refer to 4.3, “Virtual hosts: IP-based implementation” on page 47.

򐂰 Name based: The HTTP server uses the domain name to include into the URL header to handle visitor requests. This implementation requires HTTP 1.1. For more information about Name-based implementation, refer to 4.4, “Virtual hosts: Name-based

implementation” on page 60.

򐂰 Mass dynamic based: The HTTP server retrieves the domain name provided in the URL header to process the data requested by the client. The difference here is that this is done dynamically, which means, the domain does not have to be registered using any

<VirtualHost> context in the HTTP configuration. For more information about mass dynamic-based implementation, refer to 4.5, “Virtual hosts: Mass dynamic

implementation” on page 65.

Based on the TCP/IP configuration and the Web client browser capabilities, the configuration options listed in Table 4-3 are available to create the virtual host implementation.

Table 4-3 Instance creation options

IP address/port Protocol HTTP server configuration approach

One IP address, one port HTTP 1.0 򐂰 One HTTP server, no virtual host configuration can be created.

One IP address, one port HTTP 1.1 򐂰 One HTTP server, without virtual host configuration.

򐂰 One HTTP server, name based.

򐂰 One HTTP server, mass dynamic.

Chapter 4. Virtual hosts 45 With this information about TCP/IP configuration options, you can design your own virtual host implementation to serve your domains. The “ideal” virtual host implementation using the HTTP Server (powered by Apache) includes:

򐂰 One HTTP server, using specific virtual host directives in the configuration file

򐂰 Using either the IP address or the domain name to serve visitor requests

򐂰 Using any of the TCP/IP configuration approaches

Table 4-4 summarizes the HTTP virtual host implementation options. The HTTP Server (original) column is included only as an aid.

Table 4-4 Virtual host implementation

Although the iSeries server supports the HTTP Server (original) and HTTP Server (powered by Apache), the HTTP Server (original) configuration is beyond the scope of this book. If you want to learn more about the HTTP Server (original), concepts and configuration process, refer to the HTTP Server iSeries Information Center at:

http://publib.boulder.ibm.com/pubs/html/iseries_http/v5r1/index.htm

Now, let’s focus on the HTTP Server (powered by Apache) implementation and how it works.

For any other IP address

IP interfaces One or multiple IP interfaces One or multiple IP interfaces Server implementation 1 or multiple instances 1 or multiple HTTP server

Server directives Pass Listen

Note: The <VirtualHost> implementation is supported since Apache Version 1.1, but it was rewritten by Apache Version 1.3. The HTTP Server (powered by Apache) supports Apache Version 2.0

Note: Whether you use one server instance or multiple server instances, if any of the domains require the SSL/TLS encryption, you have to use specific virtual host directives within the configuration files. That’s because as the SSL configuration needs to listen on a different port, usually 443, for encrypted information. For additional information of how to create the SSL/TLS virtual host directive, refer to 5.3, “Encrypting your server’s data with SSL and TLS” on page 90.

IP address/port Protocol HTTP server configuration approach

4.2 HTTP Server (powered by Apache) virtual host overview

The virtual host implementation with the HTTP Server (powered by Apache) allows one HTTP server to process the request for one or more domains. Configuring your HTTP server for a virtual host is a two-stage process:

1. The IP address and port to listen on need to be assigned.

2. The virtual host configuration needs to be defined and configured.

The virtual host configuration is done using the <VirtualHost> context directive. <VirtualHost>

and </VirtualHost> are used to enclose directives that apply only to a particular virtual host.

Almost any configuration directive can be used within the VirtualHost context, with exception of directives that control process creation. A typical virtual host configuration looks similar to the following example:

Here 10.5.92.28 is the IP address, 8002 is the port number the virtual host listens on, and www.itso01.com is the domain name.

In terms of the HTTP Server (powered by Apache) configuration, there are two different approaches to set up the virtual host:

򐂰 Main server with <VirtualHost>: One or more domains being handled by the main server configuration and the <VirtualHost> context for any specific domain requirements, for example security.

򐂰 Only <VirtualHost>: Use the <VirtualHost> context for domain and leave the main server with no requests to handle.

With the first approach, unless overridden by <VirtualHost> context, the main server behavior will be inherited by all the virtual hosts. For example, the ServerAdmin and ErrorLog directives are used by all virtual hosts.

Tip: The <VirtualHost> context defines a specific IP address and port through which clients access files on your iSeries server. Through the design of your TCP/IP network (complete with routers, firewalls, physically separated public and private networks, and so on) you can force certain clients to arrive on a specific IP address or port. An example of this would be intranet traffic on 10.1.1.1 and Internet traffic on 100.1.1.1. In this way, you can treat these clients differently by adding specific directives within the <VirtualHost>

context.

Chapter 4. Virtual hosts 47

DocumentRoot /itso/itso02/itsoco ServerName www.itso02.com

</VirtualHost>

With the second approach, each virtual host has its own server directive. Therefore, there is no main server configuration that applies to all virtual hosts.

Listen 10.5.92.28:8002

Now when a request arrives, the HTTP server uses the IP address and port, or the domain name it arrived on, to find a matching virtual host configuration. If no virtual host matches the address and port (or the domain name), the request is handled by the main server

configuration. If it does match a virtual host directive, the HTTP server uses the configuration of that <VirtualHost> to handle the request.

4.2.1 Additional resources

Here are some additional references that can help guide your study of virtual hosts as implemented by the Apache HTTP server:

򐂰 Apache Week Web site: http://www.apacheweek.com/features/vhost

򐂰 Apache virtual host documentation: http://httpd.apache.org/docs/vhosts/index.html

4.3 Virtual hosts: IP-based implementation

As the term IP-based indicates, the IP virtual host implementation is based on the way the HTTP server uses the IP address to serve the domain. If you want to serve multiple domains