V4R3 HTTP Server - Best of the Best

By:  Bob Cancilla
Title:  AS/400 Internet Practioner
Date:  12/06/1998 - 06:01 PM (UCT)
URL:  HTTP://www.as400.ibm.com/http

Well, the battle of the web serverÈs heats up with IBMÈs V4R3 HTTP server. What IBM RochesterÈs developers lack in creativity in naming the server (HTTP Server) can certainly be forgiven in terms of the features and functionality of the new server which replaces both ICS and ICSS from V4R2 and the old HTTP server from V3Rx.

Prior to V4R3, if you chose to use one of IBMÈs servers (i.e. the old HTTP or ICS or ICSS) you got what you paid for, namely a FREE server which was worth exactly what you paid for it. For well over two years, I personally have chosen I/Net, Inc.Ès Commerce Server/400 for serious e-Business Applications.

The new HTTP server changes the landscape radically. Lets take a look at the server and see what the folks at IBM did.

Net.Data Web Based Configuration

Those of you running ICS or ICSS are familiar with the GUI web based configuration for the ADMIN server provided with the product. It was a user friendly way of configuring your server. Those of you familiar with ICS or ICSS were also painfully aware that you were very limited as to how much configuration you could do from the ADMIN server.

Well, our friends in Rochester did it right this time! They utilized the rapid development capabilities of Net.Data to build the single most comprehensive web based administration server available. Very likely the ADMIN server is superior to web based configuration for ANY server on ANY platform. We have not yet found a need to edit the configuration files by hand. The green screen interface to edit the configuration file still exists if you feel the urge to use it, but why youÈd want to would be a mystery.

HTTP 1.1

The new server implements HTTP 1.1, which is the basis for many of the following enhancements. There are many new features in HTTP 1.1 you can read about HTTP 1.1 at http://www.w3.org (the WWW Consortium Ì the definitive resource for HTTP and HTML).

Virtual Hosting

This is a brand new concept that the HTTP server brings to the AS/400. Apache and Netscape have had this concept in place in the UNIX and Windows/NT world for a couple of years, but now we have it also.

Many of you may be running multiple web servers on your AS/400Ès. This was done via ICS or ICSS by setting BindSpecific ON and running an ICS or ICSS server DAEMON and child process set of jobs for each domain name/IP address combination you wanted to support.

This meant that if you wanted to support multiple domains, you had to run one unique server for each domain. Generally, each server had its own configuration file, IP address, domain, root document directory, and WELCOME page.

New in HTTP 1.1 and in the HTTP server is a concept called virtual hosting.

Virtual hosting allows one server DAEMON job to process requests for multiple IP addresses or domain names. This means that one set of server jobs handle the work without the overhead multiple jobs. Each virtual host can have its own domain name, may have its own root document directory, its own WELCOME page, and may have its own IP address.

There are three variations of virtual hosting:

  • Virtual Host Names

    This method is perhaps one of the most attractive forms of virtual hosting due to the increasingly sparse availability of IP addresses. Virtual name based hosting allows multiple domain names to be mapped to a single IP address. You define multiple "cname" entries (canonical names) to your DNS for the same IP address.

    The server configuration then contains directives that allow you to specify the document directory, protection, MAP and PASS directives for that domain name.

    A word of caution. Virtual name based hosts are very strictly a feature of HTTP 1.1 and require that the userÈs browser support HTTP 1.1. A new HTTP header parameter called HOST sends the name of the virtual host that the browser wants to talk to. This is how the server knows how to direct the request. Browsers that do NOT support HTTP 1.1 will not work with Virtual Name based hosts. There are some tricks that can played on old browsers so that they can be made to work with virtual name based servers. Generally, it is done via sub-directories. They will always access the primary server and be redirected to the root directory of the virtual host.

  • Virtual IP Address Based Hosts

    This is much simpler and straight forward variation of the virtual hosting theme. Here you define domain name/IP address combinations to your DNS in the traditional fashion. www.acme.com, www.baker.com, and www.charlie.com all have their own IP addresses.

    Here you can specify a WELCOME, page, document root, and other server specific directives to a single server instance (i.e. DAEMON and Child Processes) so they all run in a single job structure. You can do this by IP address or by Name.

  • Virtual Mixed Mode

    In this mode you can create a complex mixture of virtual web sites based on IP addresses or domain names mapped to the same IP address (cname). You may share a single configuration file or give some or each virtual server its own configuration file.

    While all is possible here, the complexity may become unmanageable. Use this option with extreme caution.

This article is not going to get down into the nitty gritty technical details, but one word of advice. Be sure you locate the BindSpecific server directive and change it from * to the IP address or addresses, domain name or domain names you want to support. This enables multi-homing on your machine and allows you to run multiple servers on the same port. You may want a separate physical server for intranet or development separate from your production virtual servers all running on port 80. This is the key.

Persistent CGI and Persistent Net.Data

Introduced by HTTP 1.1. and supported by the V4R3 HTTP server is persistent CGI. As most of you know previous HTTP implementations used a stateless concept where every access to a CGI program running on your server was considered by the server to be the first. This meant that you had to use Cookies, user status database files, hidden fields in your HTML forms and other techniques to keep track of what the user had done on your site and where you were. This was particularly annoying for e-Commerce and on-line stores where you had to take rather extreme measures to keep track of purchases and support the concept of a shopping cart.

Persistent CGI keeps the program your user accessed and its associated resources (memory, files, etc.) intact between accesses to the server. It is done by creating a "handle" which is attached by the server to the URL QUERY_STRING and returned to the server on each request from the browser. V4R3 was required to support this new facility as it makes use of "THREADS" (little jobs running inside your job). Each persistent state thread has a timer set by default and overridable by you to 10 minutes. If a user responds within the time limit, then they get the same resources and program instance that they got when the first accessed the function.

Suppose you produced a list that was many pages long (lets say 1000 rows). Instead of displaying the entire list you devised a technique for displaying 20 records at a time. Before persistent state CGI, you would have to run the query that retrieved the entire 1000 rows each time the user accessed the server. You would have to figure out that the user had seen the first 20 rows and then send the next 20 rows. The key point here is that the query would have to be run on each and every access to the server by the user.

With persistent state CGI you can retain the 1000 rows in memory and send 20 rows at a time without having to re-run the query. Persistent state CGI is very much like traditional 5250 based interactive programming.

DonÈt over use or abuse persistent state CGI, it can consume a tremendous amount of resource on a busy server and the cost may out weigh the benefit. But use it judiciously and you will be extremely pleased at the performance improvements you can deliver to your users.

Net.Data has been enhanced to include a new DTW_STATIC function that enables it to take advantage of Persistent State CGI and is referred to in its documentation as Persistent Net.Data.

Meta File Support

This is new feature supported by the V4R3 HTTP server. It allows you store HTML meta tags in a file that is associated with a document directory or subdirectory. Quite frankly I donÈt understand itÈs purpose or benefit, but it is a concept introduced in HTTP 1.1 and is supported by the server. If anyone knows of a good use for this facility, please post an article to the INFOCENTER or at least a note the forum or mailing list.

Digital Certificate Authentication

We have had SSL support for a couple of years now in all of the AS/400 web servers. As you all know SSL provides two important features, encryption and server authentication. Authentication sends your digital certificate to the userÈs browser. The user may double click on the "lock" icon on their browser and see a display that tells them that they can trust that the information they see on the screen or are about to send to your server is from or will go to your companyÈs server. This prevents hackers from "spoofing" or pretending to be you in order to obtain your clientÈs credit card or other personal information.

Now in V4R3 with the HTTP server, the server can validate personal certificates and a client can use a certificate to identify themselves to you. You can associate personal certificates with users defined via AS/400 User profiles, or via the Access Control Lists mechanism.

With V4R3, IBM provides a Certificate Manger that can generate client certificates. In theory you can issue certificates to your users or you can validate personal certificates issued by Verisign, Inc. This is a positive step in the right direction for those of us with the need for personal digital certificates. I work for an Insurance Company. Insurance Companies must have their applications for insurance "signed by the applicant or their agent". We cannot eliminate the paper application until we can replace it with a digitally "signed" electronic version. Digital Certificates are the answer (coupled with some legislation in many of our states Ì today only Utah has a fully implemented law. California has one on the books but it has not been implemented by the regulators).

There are some downsides to IBMÈs current implementation. Some versions of Microsoft Internet Explorer will not process a certificate generated by the IBM Certificate Manager. The problem is that they check to see that the certificate was issued by a Microsoft approved Certification Authority (CA) and you and your AS/400 are simply NOT on their list. Some people have said that they can bypass this edit, others cannot.

IBM states that the certificate manager function is good for intrAnet usage and will be enhanced in the future possibly by a new product (read product that we must pay for). At present, something is better than nothing, but your ability to control your clientÈs browsers will be the key to using this facility. Never the less, a very positive move in the right direction. There is NO OTHER SERVER that provides this facility for AS/400 users.

Proxy Server

The HTTP server now allows itself to be configured as a proxy server. You can figure it to be a public proxy that caches pages for Internet users or use it on multiple AS/400Ès in your organization to improve response and limit access to specific users throughout your organization. You can run the proxy on the same or different machine from the machine running your primary web server(s). I plan to make extensive use for large companies that I work with that have AS/400Ès in their branch offices. One requirement that the proxy server will facilitate is a company policy limiting access to Internet sites for most employees. You can devise a business strategy that allows you to link to some web sites and limit access to all others or any number of variations of limits and authorities.


I save the best for last. WebSphere is perhaps one of IBMÈs most misunderstood facilities and most powerful. If JAVA is to be a reality in the Internet it is via Sun MicrosystemÈs Java Servlet API. I was discussing the use of Java Applets with an IBM sales person just this week. He told me that IBM recommends keeping Applets and Applications under 500k in size so that communications times are reasonable. Well 500k on a 28.8kbs line is UNREASONABLE in my book thus limiting JavaÈs viability.

Now incomes WebSphere. WebSphere maybe many things to IBM and we shall see. But what it is NOW is support for SunÈs JAVA Servlet API. What this means is that the HTTP server can run Java Servlets. Servlets are server side Java applications that run on the AS/400. They can produce dynamic HTML producing both HTML input forms and dynamic output.

WebSphere opens the AS/400 up to many off the shelf applications that were originally developed for the Java Servlet API on UNIX systems. An example of this is the search engine that we are running here on IGNITe/400 at HTTP://search.ignite400.org If you havenÈt tried it out, please do so. This products developed by a company in Hong Kong called Cybotics http://www.cybotics.com is a very powerful search engine. We installed WebSphere downloaded Cybotics search engine and installed it. It runs! ThatÈs it! True cross platform support. If anyone tells you that the JAVA JVM on the AS/400 is slow, they are a LIAR or donÈt know what they are talking about. Try the search engine and see for yourself. AS/400 based server-side JAVA flies! IÈm sure it is true that C, C++, or even RPG may be a little faster than JAVA, but the differences are so minor that they are not measurable to an end-user!

There are dozens of Servlet based applications becoming available for little or no money and more being developed every day. If you feel so inclined, IBM offers an excellent tool set in the WebSphere Suite (available from the cross platform WebSphere site) and Visual Age for JAVA R2.0 which will enable you to build your own Servlet based applications.

IBM has plans for CORBA based objects and other extensions that quite frankly I know nothing about. Servlet support is quite impressive and enough for me right now. Especially since I can acquire products like Cybotics search engine without having to build it myself.

The Downside

The really unfortunate downside to the HTTP server is not the server, but rather its documentation or lack of documentation. The WebmasterÈs Guide is supposed to be the definitive resource for configuring and administering the server. It is virtually useless. One of the worst IBM manuals ever written. You are better off working the ADMIN server and its Net.Data macro base forms and just poking around reading the on-line help text which is better than the manual, but still has gaping holes in it.

We will post detailed configuration guides and share our experiences here on IGNITe/400 as we explore this tremendous new server.

One other criticism is that IBMÈs HTTP server website http://www.as400.ibm.com/http has not been updated since September, 1998. Also, the developers are hiding out and not coming out to the various newsgroups and public resources to discuss their product. IÈm sure they are quite busy and have limited time, but it would be nice if someone came out of the lab and would speak to the folks trying to use the server.

IBMÈs server is still based on the CERN model which is extremely cumbersome to deal with compared to the NCSA model, but with the Net.Data macro based ADMIN server, you donÈt have to deal with the configuration file directly anymore and IBM did a super job of hiding the CERN based directives from you. They also did a superb job of working around the limitations of the CERN based model.

Summary and Conclusions

At the moment, IBMÈs V4R3 HTTP Server is the BEST OF THE BEST! It has more features and functionality than any other server running on the AS/400. There are more features than I have pointed out, but those are the major ones. I laughed at the older releases of IBMÈs webserver and would say you get what you pay for. No one is laughing at this server, least of all yours truly. Congratulations to the folks that built this server, it is truly best of breed for the moment.

The great thing about the AS/400 is that the APACHE webserver and I/NetÈs port of the Netscape sever are currently in beta. Advanced Business Link is offering a server that is now AS/400 based, so the competition heats up. This will keep all of the players on their toes and give us the best possible product.

Congratulations IBM, great work!

Bob C.

Return to the Home Page

© Copyright 1998, 1999 by IGNITe/400sm
This page last updated on: Sun Jun 27 20:55:29 1999