How does the WebSphere v4.0 plug-in process HTTP requests?

Http://www-900.cn.ibm.com/cn/support/nav/200202/p24.shtml

In WebSphere Application Server v4.0x, the web server and WebSphere Application Server use HTTP 1.1 transmission (transport) for communication. Before WebSphere Application Server v4.0x, ose (Open Servlet Engine) is used) protocol. So how does WebSphere v4.0x plug-in (plug-in) handle HTTP requests?

Knowing how the plug-in processes HTTP requests will help you deploy static and dynamic pages of your application. At the same time, when you encounter JSP and small service programs (servlets) that cannot be accessed) and cannot access specific JSP and small service programs.

This article describes the processing mode of the plug-in.

When the Web server receives an HTTP request, the plug-in needs to confirm whether the request belongs to a web application running in WebSphere. If the request should not be processed by websphere, the plug-in returns a code to the Web server to tell the Web server to process the request. If this request should be processed by websphere, the plug-in needs to determine the node on which the corresponding application runs. When cloning, you also need to determine which clone should process the request.

The rules used by the plug-in are configured in the file plugin-cfg.xml, and the default location is <was_home>/config. The following is a simple example of plugin-cfg.xml.

========================================================== ======================================
<? XML version = "1.0"?>
<Config>
<Log loglevel = "error" name = "C:/WebSphere/appserver40/logs/native. log"/>
<Virtualhostgroup name = "default_host">
<Virtualhost name = "*: 80"/>
<Virtualhost name = "*: 9080"/>
</Virtualhostgroup>
<Servergroup name = "WebSphere/Default Server">
<Server cloneid = "to0oee2t" name = "Default Server">
<Transport hostname = "WebSphere" Port = "9080" protocol = "HTTP"/>
</Server>
</Servergroup>
<Urigroup name = "websphere_sampleapp/default_app_uris">
<URI name = "/servlet/snoop/*"/>
<URI name = "/servlet/snoop2/*"/>
<URI name = "/servlet/Hello"/>
<URI name = "/errorreporter"/>
<URI name = "*. jsp"/>
<URI name = "*. jsv"/>
<URI name = "*. JSW"/>
<URI name = "/j_security_check"/>
<URI name = "/servlet/*"/>
</Urigroup>
<Urigroup name = "websphere_sampleapp/examples_uris">
<URI name = "/webapp/examples/*"/>
</Urigroup>
<Route servergroup = "WebSphere/Default Server"
Urigroup = "websphere_sampleapp/default_app_uris" virtualhostgroup = "default_host"/>
<Route servergroup = "WebSphere/Default Server"
Urigroup = "websphere_sampleapp/examples_uris" virtualhostgroup = "default_host"/>
</Config>
========================================================== ======================================

When an HTTP request arrives at the web server, the plug-in searches for the route in the XML configuration file. A route is determined by two Information, virtualhostgroup and urigroup. Let's take the request http: // localhost/servlet/Hello as an example.

If the virtualhostgroup definition exists in the configuration file, the plug-in tries to match the domain name and port of the request with the virtualhost defined in virtualhostgroup. If the virtualhostgroup definition does not exist in the configuration file, the plug-in assumes that the route matches all virtual hosts. In this example, because the default port of the HTTP request is 80, the domain name and port of the request are localhost: 80, match with <virtualhost name = "*: 80"/> defined in <virtualhostgroup name = "default_host">.

If the urigroup definition exists in the configuration file, the plug-in tries to match the URI of the request with the URI defined in urigroup. If the urigroup definition does not exist in the configuration file, the plug-in assumes that the route matches all Uris. In this example, the request URI is/servlet/Hello, match with <URI name = "/servlet/Hello"/> defined in <urigroup name = "websphere_sampleapp/default_app_uris">.

If the request matches the virtualhostgroup and urigroup, And the virtualhostgroup and urigroup belong to the same routing definition, the request will be sent to the servergroup defined in the route for execution. In this example, the matched route is defined:

<Route servergroup = "WebSphere/Default Server"

Urigroup = "websphere_sampleapp/default_app_uris" virtualhostgroup = "default_host"/>

Therefore, the request will be sent to <servergroup name = "WebSphere/Default Server"> for execution.

Depending on whether the application server has been cloned, The servergroup may define one or more servers. The next step is to determine which server the request should be sent.

First, the plug-in checks the session affinity of the request ). If the request has a session affinity cookie, it indicates that the session has been allocated to a specific application server in the previous request. Comply with Servlet 2.2 specifications: "within an application that is marked as distributable, all requests that are part of a session can only be handled on a single VM at any one time ", when a session has been assigned a server, the request must be sent to the same server. The plug-in looks for a cookie named JSESSIONID in the header or URL. If JSESSIONID exists and contains cloneid, The cloneid matches the cloneid of a server defined in servergroup, the request will be sent to the server.

If session affinity is not established, a server is allocated to the request and session according to the Server Load balancer rules. The default rule is round robin ). The starting point of the round robin is random. That is to say, the first server is randomly selected and then the cycle starts. Therefore, for multi-process Web servers, different processes randomly extract their starting points, and do not send the first request to the same application server, ensuring balanced use of the application server; on the other hand, since sessions are not all processed by the same process, from the perspective of the Web server as a whole, Round Robin is not absolute. Another rule of Server Load balancer is random (random). Under this rule, sessions are randomly allocated to available application servers.

In this example, only one server is defined in <servergroup name = "WebSphere/Default Server">. <server cloneid = "to0oee2t" name = "Default Server">, therefore, the request will be sent to the server.

After the application server is confirmed, the plug-in must determine what transport is used ). Each server can define one or more transmissions, but if multiple transmissions of the same type are defined, for example, multiple HTTP transmissions are defined, the first transfer in the configuration file will be used. The following table lists how the plug-in maps HTTP and HTTPS requests to the available transfer of the Application Server:

Received Protocol Request	Application Server Only HTTP Transfer	Application Server Only HTTPS Transmission	Application Server supports both HTTP Transmission HTTPS transmission is available.
HTTP	HTTP	HTTPS	HTTP
HTTPS	HTTP	HTTPS	HTTPS

Once the transfer is confirmed, the plug-in can get the host, port and transfer protocol from the transfer definition to send requests.
In this example, only one transfer is defined in <server cloneid = "to0oee2t" name = "Default Server">, <transport hostname = "WebSphere" Port = "9080" protocol = "HTTP"/>, so the plug-in will use this transport, send requests to port 9080 of the host "WebSphere" over HTTP.