The HTTP service is the component of the Application Server that provides facilities for deploying web applications and for making deployed web applications accessible by HTTP clients. These facilities are provided by means of two kinds of related objects, virtual servers and HTTP listeners.
This chapter discusses the following topics:
A virtual server, sometimes called a virtual host, is an object that allows the same physical server to host multiple Internet domain names. All virtual servers hosted on the same physical server share the Internet Protocol (IP) address of that physical server. A virtual server associates a domain name for a server (such as www.aaa.com) with the particular server on which the Application Server is running.
Do not confuse an Internet domain with the administrative domain of the Application Server.
For instance, assume you want to host these domains on your physical server:
www.aaa.com www.bbb.com www.ccc.com
Assume also that www.aaa.com, www.bbb.com, and www.ccc.com have web modules web1, web2, and web3, respectively, associated with them.
This means that all of these URLs are handled by your physical server:
http://www.aaa.com:8080/web1 http://www.bbb.com:8080/web2 http://www.ccc.com:8080/web3
The first URL is mapped to virtual host www.aaa.com, the second URL is mapped to virtual host www.bbb.com, and the third is mapped to virtual host www.ccc.com.
On the other hand, the following URL results in a 404 return code, because web3 isn’t registered with www.bbb.com:
For this mapping to work, make sure that www.aaa.com, www.bbb.com, and www.ccc.com all resolve to your physical server’s IP address. They need to be registered with the DNS server for your network. In addition, on a UNIX system, add these domains to your /etc/hosts file (if the setting for hosts in your /etc/nsswitch.conf file includes files).
When the Application Server is started, it starts the following virtual servers automatically:
A virtual server named server, which hosts all user-defined web modules
A virtual server named __asadmin, which hosts all administration-related web modules (specifically, the Admin Console). This server is restricted; you cannot deploy web modules to this virtual server.
For development, testing, and deployment of web services in a non-production environment, server is often the only virtual server required. In a production environment, additional virtual servers provide hosting facilities for users and customers so that each appears to have its own web server, even though there is only one physical server.
Each virtual server provides connections between the server and clients through one or more HTTP listeners. Each HTTP listener is a listen socket that has an IP address, a port number, a server name, and a default virtual server.
HTTP listeners must have a unique combination of port number and IP address. For example, an HTTP listener can listen on all configured IP addresses on a given port for a machine by specifying the IP address 0.0.0.0. Alternatively, the HTTP listener can specify a unique IP address for each listener, but use the same port.
Since an HTTP listener is a combination of IP address and port number, you can have multiple HTTP listeners with the same IP address and different port numbers (for example, 188.8.131.52:8081 and 184.108.40.206:8082), or with different IP addresses and the same port number (for example, 220.127.116.11:8081 and 18.104.22.168:8081, if your machine was configured to respond to both these addresses).
However, if an HTTP listener uses the 0.0.0.0 IP address, which listens on all IP addresses on a port, you cannot create HTTP listeners for additional IP addresses that listen on the same port for a specific IP address. For example, if an HTTP listener uses 0.0.0.0:8080 (all IP addresses on port 8080), another HTTP listener cannot use 22.214.171.124:8080.
Because the system running the Application Server typically has access to only one IP address, HTTP listeners typically use the 0.0.0.0 IP address and different port numbers, with each port number serving a different purpose. If the system does have access to more than one IP address, each address can serve a different purpose.
By default, when the Application Server starts, it has the following HTTP listeners:
Two HTTP listeners named http-listener-1 and http-listener-2, associated with the virtual server named server. The listener named http-listener-1 does not have security enabled; http-listener-2 has security enabled.
An HTTP listener named admin-listener, associated with the virtual server named __asadmin. This listener hasdoes not have security enabled.
All these listeners use the IP address 0.0.0.0 and the port numbers specified as the HTTP server port numbers during installation of the Application Server. If the Application Server uses the default port number values, http-listener-1 uses port 8080, http-listener-2 uses port 8181, and admin-listener uses port 4848.
Each HTTP listener has a default virtual server. The default virtual server is the server to which the HTTP listener routes all request URLs whose host component does not match any of the virtual servers that are associated with the HTTP listener (a virtual server is associated with an HTTP listener by listing the HTTP listener in its http-listeners attribute).
In addition, specify the number of acceptor threads in the HTTP listener. Acceptor threads are threads that wait for connections. The threads accept connections and put them in a queue, called the connection queue, where they are then picked up by worker threads. Configure enough acceptor threads so that there is always one available when a new request comes in, but few enough so that they do not provide too much of a burden on the system. In the Application Server, there is no distinction between acceptor and request processing (worker) threads: each HTTP listener thread is responsible for accepting and processing requests. For this reason, the HTTP listeners in the Application Server’s default configuration use 50 acceptor threads. The connection queue includes both the new connections just accepted by acceptor threads and persistent connections managed by the Keep-Alive connection management subsystem.
A set of request processing threads retrieves incoming HTTP requests from the connection queue and processes the requests. These threads parse the HTTP headers, select the appropriate virtual server, and run through the request processing engine to service the request. When there are no more requests to process, but the connection can be kept persistent (either by using HTTP/1.1 or sending a Connection: keep-alive header), the request processing thread assumes the connection to be idle and passes the connection to the Keep-Alive connection management subsystem.
The Keep-Alive subsystem periodically polls such idle connections and queues those connections with activity into the connection queue for future processing. From there, a request processing thread again retrieves the connection and processes its request. The Keep-Alive subsystem is multi-threaded, as it manages potentially tens of thousands of connections. Efficient polling techniques are used, by dividing the number of connections into smaller subsets, to determine which connections are ready with requests and which of those connections have idled for sufficient time to deem them closed (beyond a maximum permissible Keep-Alive timeout).
The HTTP listener’s server name is the host name that appears in the URLs the server sends to the client as part of a redirect. This attribute affects URLs the server automatically generates; it does not affect the URLs for directories and files stored in the server. This name is normally the alias name if the server uses an alias. If a client sends a Host: header, that host name supersedes the HTTP listener’s server name value in redirects.
Specify a redirect port to use a different port number from that specified in the original request. A redirect occurs in one of these situations:
If a client tries to access a resource that no longer exists at the specified URL (that is, the resource has moved to another location), the server redirects the client to the new location (instead of returning a 404), by returning a designated response code and including the new location in the response’s Location header.
If a client tries to access a resource that is protected (for example, SSL) on the regular HTTP port, the server redirects the request to the SSL-enabled port. In this case, the server returns a new URL in the Location response header, in which the original insecure port has been replaced with the SSL-enabled port. The client then connects to this new URL.
Specify also whether security is enabled for an HTTP listener and what kind of security is used (for example, which SSL protocol and which ciphers).
To access a web application deployed on the Application Server, use the URL http://localhost:8080/ (or https://localhost:8181/ if it is a secure application), along with the context root specified for the web application. To access the Admin Console, use the URL https://localhost:4848/ or http://localhost:4848/asadmin/ (its default context root).
Because a virtual server must specify an existing HTTP listener, and because it cannot specify an HTTP listener that is already being used by another virtual server, create at least one HTTP listener before creating a new virtual server.