WAS 4.0 HTTP Transport URI Rule Matching
 Technote (FAQ)
 
Problem
How does the HTTP Transport map URI's to WebSphere ServerGroups?
How does the HTTP Transport perform URI Matching?
How does the HTTP Transport perform VHost Matching?
How does the HTTP Transport match URIGroups to VhostGroups?
How does the HTTP Transport match VhostGroups to ServerGroups?
 
Solution

The following details how the WAS 4.0 HTTP Transport (the webserver plugin) determines that a URI should be handled by a WebSphere 4.0 Application Server.

Basic Definitions
URIGroups:
A logical group of URIs.

VirtualHostGroups:
A logical group of hostnames.

ServerGroup:
A logical group of Application Servers.

Route:
A route associates a ServerGroup with a URIGroup and/or a VirtualHostGroup. For a given URI and hostname combination, a group of application servers are defined that can service the requests

More detailed information of the above terms is given in the WAS 4.0 InfoCenter:
http://www.ibm.com/software/webservers/appserv/library.html

HTTP Transport Request Handling

Resolving WebSphere URI's using the plugin-cfg.xml is a two step process. For each URI submitted by a browser client, the webserver will invoke a method in the HTTP Transport (i.e. call the WebSphere plugin before trying serve a static page). On a very high level two steps are performed.


Step 1: Determine if the URI is intended for a WebSphere Application Server
  • Search for a match on the client's URI
  • Search for a match on the client's hostname
Step 2: Determine which Application Server should handle the request

Step 1: Determine if the URI is intended for a WebSphere Application Server

An HTTP request is received by the webserver. The webserver plugin uses the Route statements in the plugin-cfg.xml file and begins to search the URI/VirtualHost groups defined by the designated route. The plugin-cfg.xml file is traversed from the bottom up.

The following are the details taken to resolve the client's request:

  1. The next route statement in the plugin-cfg.xml is selected. For the first iteration, the last Route statement in the plugin-cfg.xml file is selected. If all Route statements have been searched, the request is rejected and programmatic control is passed to the webserver.
  2. The URIGroup defined in the Route statement is selected and searched. If a match for the client's URI is found in the selected URIGroup, the HTTP Transport proceeds to step 1.C. If a match is not found the HTTP Transport returns to step 1.A.
  3. The VirtualHostGroup defined in the Route Statement is selected and searched. If a match for the client's hostname is found then the request is accepted and the HTTP Transport proceeds to step 2. If a match is not found the HTTP Transport returns to step 1.A.

Step 2: Determine which Application Server should handle the request.

  1. Once the HTTP Transport has determined the client's request is intended for WebSphere application Server, internal structures and information about the request is created.
  2. The Route statement that resolved the client's URI and hostname is associated with a ServerGroup. The ServerGroup defines a set of application servers that can handle the request. The Application Server Clone that will ultimately serve the request is selected either in a Round Robin or Random if session affinity is not configured.
 
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Plug-in
Operating system(s): HP-UX
Software version: 4.0.1
Software edition:
Reference #: 1049622
IBM Group: Software Group
Modified date: Feb 25, 2002