In this issue

Release: 1.1.1
Beta: None
Bugs reported in 1.1.1:

• IP address matching in <Limit> wrong: giving 1.2.3.4 can match 1.2.3.45.

• Directory listing truncates sizes (e.g. 1.8Mb is shown as 1Mb)

The following items are under development for the next release of Apache.

It will now be possible to list more than one IP (or host) address in the <VirtualHost> section.

A new command line option, -h, will return a list of the directives the server can handle.

The next release of Apache will be version 1.2. The big new feature in 1.2 will be support for HTTP/1.1, the new version of the Hypertext Transfer Protocol. Apache 1.2 will fully support this protocol as a Web server (except for the proxy module). HTTP/1.1 is now going through the final stages of approval as an Internet standard, and Apache 1.2 cannot be fully released until it is approved, since there might be changes.

However, HTTP/1.1 is not the only change in Apache 1.2. There will be quite a few other new features, new optional and core modules, and many bug fixes. In this feature, we list all the major changes coming in 1.2. Each change is accompanied by a link to the Apache Week issue where it is reported in more depth.

• Better Content Type Negotiation (Apache Week 16 August 1996)
  To overcome problems with some browsers, Apache's content negotiation algorithm has been updated to better guess what content type the browser wants.
• Conditional configuration directives (Apache Week 26 July 1996)
  Configuration directives can be ignored if the module they are defined in is not compiled in.
• Customising for Browsers (Apache Week 09 August 1996)
  It will be possible to set environment variables based on the browser's user-agent text. This will give CGI and SSI scripts a simple way of customising their output based on features available in the browser.
• Easier CGI script debugging (Apache Week 09 August 1996)
  It will be easier to debug CGI scripts, because Apache can now log the full input and output of the scripts.
• Faster persistent connections (Apache Week 02 August 1996)
  Various changes have been made to increase the speed of persistent connections.
• File, Directory and Limit can take regular expressions (Apache Week 02 August 1996)
  The files and URLs affected by each of these sections can be defined by regular expressions.
• Graceful Restarts (Apache Week 28 June 1996)
  Apache can re-read the config files and re-open log files without terminating transactions in progress.
• HTTP/1.1 support (Apache Week 16 August 1996)
  Apache will be 'unconditionally compliant' with the HTTP/1.1 specification (except for mod_proxy).
• Limit access on per-file basis (Apache Week 02 August 1996)
  A new section, <File>, can be used to restrict access on a file-by-file basis. It will now be possible to (for example) password protect a single file.
• More SSI Commands (Apache Week 09 August 1996)
  The 'extended SSI' module (XSSI) will replace the current server-side-includes module. This will give a number of powerful new features, such as the ability to set variables and use conditional statements.
• Multiple configurable log files (Apache Week 16 August 1996)
  More than one log file can use used, with the log format fully customisable. This reduces the need for addition log modules (mod_log_referer or mod_log_agent), and make it much easier to add customised log files and formats.
• PICs module (Apache Week 12 July 1996)
  An optional module will be included which can provide PICS labels.
• Resource limits for CGI scripts (eg max CPU time) (Apache Week 02 August 1996)
  To prevent runaway processes, the resources used by CGI scripts can be limited.
• Rewrite module (Apache Week 09 August 1996)
  The 'rewrite' module will be included with Apache for the first time. This module can be used to map incoming URLs onto other URLs, using regular expressions.
• Setuid CGI execution (Apache Week 09 August 1996)
  Apache will support the execution of CGI scripts as users other than the server user. A number of security checks will be built in to try and make this as safe as possible.
• Simplified configuration file format (Apache Week 09 August 1996)
  The process of configuring Apache for compilation has been simplified.
• User Tracking (cookie module) Updates (Apache Week 02 August 1996)
  It will be possible to disable the generation of cookies, even when the cookie module is compiled in. Also, an expiry time can be set of the cookies.

A number of bugs from 1.1 have been fixed. Some of the major ones are:

• KeepAlive connection problems on some browsers
• If ErrorDocument redirect fails, displays filename
• Negotiation module negotiates on proxy requests (eg proxy:") then fails
• Scoreboard out of date (shows PID of children that have died)
• Problem with ScriptAlias including path info data
• <Location> matches directory sections
• support HTTP continuation headers
• mod_dir truncates file size
• Updates for QNX, OS/2, A/UX, IRIX, AIX compile warnings or system-specific behaviour

Recently (see Apache Week issue 27) we looked at how server-side includes can make creating dynamic content easy. This week we examine how CGI and Apache modules can make dynamic content faster and more powerful, at the expense of extra complexity. This is not a tutorial on CGI or modules, instead we look at the advantages and disadvantages of each.

If you want to create HTML pages on the fly, access databases, or handle the input from a form, you have several choices. If the processing you want do to is fairly simple, you can use embedded commands in HTML pages, using server-side-includes (SSI) (See Apache Week feature on SSI). Slightly more complex is the PHP scripting language, which is also embedded within HTML pages, and which has a lot of advanced features such as links to mSQL and Postgres databases.

However, for things which the scripting languages cannot do you will need to use a full programming language. Servers can run programs to create content or handle forms using CGI. This is a standard which specifies how the server is to run the program, and how it is to pass the data into it. Programs are specially written to know how to interact using the CGI mechanisms. This allows an CGI program to work with any CGI-compliant server.

CGI programs themselves can be written in any language which works on the server. Simple (and not so simple) programs are often written in interpreted languages such as perl or even shell script. For better performance, compiled programs can be used, such as those written in C.

But even when written in a compiled language, performance may be a problem. Each time a request comes in that needs to be handled by a CGI program, the server has to start that program running. This process, called a fork in Unix, is relatively time-consuming. Whether this is a problem depends on how often the server needs to do it: if the CGI is activated in response to a form that is submitted occasionally, it will not be a problem. But if the CGI creates the entire content for the site, the additional work caused by executing the CGI program for every request will have an effect on the server load.

There are several ways to make CGIs more efficient. If they are written in perl, the Apache perl module provides a much better way to run them. This module effectively builds perl into Apache, so the request does not need to execute a new copy of perl for each script. In addition, the module can pre-load scripts so that they are already available to run with no additional overhead. However, using the perl module makes the Apache executable much bigger which will use more memory.

Alternatively, the FastCGI specification is a replacement for CGI. Like CGI, it is server and language independent, but it provides for much faster launching of CGI programs. For example, it can start a CGI program running when the server starts and send requests to this program, eliminating the need to run the program for each request. It can also access programs on remote servers. An Apache module interfaces to FastCGI.

While writing efficient CGI, using the perl module, or FastCGI can significantly speed up CGI programs, the way to get the fastest possible performance is to build your code into the server. Apache, like the other main servers, has a special programmers interface to do this. This is the Apache Module API. If you write code using the module API it will be compiled right into the server itself. When it is executed, there is no need to call an external program.

But using the Module API does have some disadvantages:

• The code must be written in C (but in theory other languages could be using, and linked in)
• The module will make the server process bigger, and since Apache runs as several processes this can drain your memory
• The module will only work with Apache (none of the main server APIs - for example Apache, ISAPI, NSAPI - are compatible)
• The module has access to the internal data structures of Apache, so bugs can cause more serious problems than bugs in CGI programs
• Because each server process handles multiple requests, memory leaks in your module or libraries it links with can eat up memory
• The module API is much more complex than the CGI interface

If you do decide you want to write an Apache module, you will need to learn the Module API. This is best documented in the API.html file which comes in the src directory of the Apache source. However this documentation is not complete and you will probably need to spend some time looking at how other modules interact with Apache. In fact, the best way to write a module is to take an existing module and customise it. WebSmith magazine recently ran an article on Writing Apache Modules which takes this approach.

Apache 1.1.1 is now available with SSL secure encryption. Outside the US, a set of patches is available to integrate SSLeay with Apache to create Apache-SSL. Certificates are not available from Verisign for Apache-SSL. See the Apache Week feature on SSL for more information.

Inside the US and Canada, a commercial version of Apache-SSL called Stronghold is available. Verisign will sign certificates for Stronghold.