In this issue

Release: 1.2 (Released 5th June 1997) (Download sites)
Beta: None

Patches to Apache 1.2 bugs will be made available in the 1.2 patches directory on the Apache site. This directory also includes some minor new features which did not make it into the 1.2 release. At present this directory contains several of these new features, and a bug fix for the content-negotiation bug reported last week. For details of all previously reported bugs, see the Apache bug database and Known Bugs page. Many common configuration questions are answered in the Apache FAQ.

Now that Apache 1.2 is released, new features can again be added. If any important bugs are found in 1.2 then there could be maintainence releases (starting with 1.2.1). Otherwise the next release will be version 1.3. This will be largely similar to 1.2 but with some minor new features. More importantly, this version will be the first release to work on Windows NT and Windows 95 systems.

In the meantime, initial work has started on the requirements for a redesign of the core Apache code. This will be part of the 2.0 release. The module API will almost certainly change as part of this redesign (although it may be possible to make existing modules work with the new module API if they are recompiled). There will be more "phases" in the new API, to allow modules to have better control over the lifetime of each request. A new "header parsing" phase has already been added to 1.2 (it was needed to support the BrowserMatch).

Other new features planned for Apache 2.0 include the ability to send the output of one module (for example, a CGI script) for parsing by another (such as for SSI commands), a graphical configuration interface to make the server easier to manage and multithreading for better performance and less use of memory.

Java is often considered a client-side language, which executes within the browser. However it is increasingly being used as a general purpose language, and it is now possible to write server-side programs in Java. This can be thought of a writing CGI programs in Java, although there are some differences. To use Java server programs in Apache you will need to install an additional Apache module. There are two modules available to do this.

The Java module allows Apache to call Java classes on the server. Provided that your operating system can execute Java (or you have installed a suitable Java environment), this module will let you call Java programs from the Apache server. The module author intends to update this module in the future to support the Servlet API, which will let Java server applications (servlets) run on any web server which supports this API.

JavaSoft has recently reasoned a specification for how servers can call server-side Java applications. Such applications are referred to as "servlets" (to distinguish them from applets, which run on the browser). Any Java program written to the servlet specification will work on any server compatible with servlets. This could make Java servlets very popular for server-side extensions.

The Java Servlet Development Kit (JSDK) from JavaSoft is freely downloadable, and includes an Apache module (mod_servlet) to implement the servlet protocol. Running server-side Java is quite simple:

• On Solaris, download the Java Runtime Environment, or if you want to compile new servlets, download the Java Developer's Kit. On other platforms, use one of the ports of the JDK to other systems.
• Download the JSDK from JavaSoft (download the Solaris version). Apache will need access to the java class files in this distribution, so extract it somewhere central (for example, /usr/local/JSDK).
• Copy the mod_servet.c file from the etc directory of the JSDK into your Apache src directory, and add the appropriate Module line to Configuration. Run ./Configure and make. This module compiles with Apache 1.1.1 but not 1.2. To make it work with 1.2, apply this patch.
• Add the configuration lines to httpd.conf and srm.conf as given in the README.apache file of the JSDK. Update the paths to the java runtime executable, java runtime directive, JSDK directory, servlet directory (within your JSDK directory) and servlet configuration file. Also change the line which currently says ServletConfig NCGI_CLASS sun.servlet.embedding.ncgi.NcgiServletGate to say ServletConfig NCGI_CLASS sun.servlet.apache.NcgiServletGate (or simply comment this line out and use the correct default provided in the patched mod_servet.c).

After doing the above you should be able to start your Apache server and request the sample servlets with URLs such as http://localhost/servlet/SnoopServlet.

Note that the patch to make mod_servlet.c work under Apache is still under development, and there should be a better version of this module in the future. At present, not of the java interface is implemented under Apache, and servlets must be located under the /servlet URL.

Information Week's Web servers -- Apache:Freely Successful article (2nd June 1997) gives a realistic review of the advantages and disadvantages of using Apache. As they state, "the main drawbacks: no vendor support and lack of a point-and-click user interface".

Some of the Apache developers made front-page news on the US PC Week magazine. The article Fort Apache (June 9th 1997) says "The birth and growth of Apache is a refreshing departure from the headline-grabbing, overhyped software industry and a throwback to the Internet's early days".

Recently PC Magazine, also published by Ziff-Davis, has critised Apache for both useability and performance. While this article is much more positive, and includes quotes from companies running Apache they say that "Anyone unfamiliar with hard-core Unix programming will not be able to get Apache running, said users". Obviously users do need to know some amount of Unix to work with Apache - to edit the configuration files, setup shell scripts to start and stop the server, and so on - there is no requirement that users are serious Unix programmers. They also include the same performance graph as used in PC Magazine, which shows Apache as much slower than IIS at high loads. This may indicate that they did not configure the server correctly for high loads.