Apache Week
   
   Issue 21, 28th June 1996:  

Copyright 1996-2005
Red Hat, Inc.

In this issue


Version

1.0.5 is the current stable public release. The next release will be 1.1, which is currently in beta test at version 4 (1.1b4).


1.1 Release Schedule

The next version of Apache will be 1.1. It has been in public beta development since April, with four development releases (1.1b1 through 1.1b4). The number of bug reports has significantly decreased recently, so this beta test phase is coming to a close. The full release version of 1.1 is now expected next week (week ending 5th July) baring any major problems in the meantime.

Once 1.1 is released, development work will start on the next release. As well as numerous minor updates, there are four major changes under consideration:

  • Implement the HTTP/1.1 specification, which should be finalised in the near future.
  • Update the source code to use some sort of auto-configuration to support different platforms.
  • Add authoring support using the PUT method.
  • Implement optional multi-threading, where each child process can handle multiple transactions concurrently.

As yet nothing is decided, not even the version number of the next release!


Bugs in 1.1b4

  • Running CGI under inetd has been a problem for Apache. This should now be handled better.
  • Long-standing 'bug' which meant that directory indexes only displayed document titles if <TITLE> was given in uppercase has been fixed.
  • Leading colons were being stripped from .htpasswd password fields.


Under Development

Graceful Restarts
When apache receives a HUP or TERM signal, it cancels whatever transactions are currently in progress before restarting or terminating. It would be far nicer if it could let transfers in progress run to completion, especially on busy sites where there is no idle time to do restarts. This is important since many sites will routinely send the server a HUP signal when they rotate the logs, and when they want changes to the global configuration files to take effect.

The next version of Apache, after 1.1, should have facilities to allow a more graceful restart. This will let transactions in progress run to completion. The Apache child processes could be told to die when there transaction is finished, and the parent waits until all are dead before loading the new configuration and starting the children again. Unfortunately this might leave a period when the server is not responding to any new requests (because the 'idle' child processes have killed themselves). So a better implementation would be for the parent to restart children with the new configuration as they die. A scheme for doing this is currently under development. It will probably use a new signal (possibly INT) to initiate a graceful restart (a new signal is used since users of HUP might be expecting a swift restart).

Extending Options
The core server and several of the default modules make use of the 'Options' directive to turn themselves on and off. This works with the 'AllowOverrides' directive to let site administrators stop their users using potentially dangerous options. As the number of modules grows, it would be nice to let third-party modules use the Options/AllowOverrides functionality. At present, the list of possible Options/AllowOverrides arguments is fixed in the Apache core. A possible future development would be an extension to the module API to let modules request new Options arguments for their own use.

More Socket Lingering problems
As reported in Issue 16, some SVR4 systems have a bug in their socket implementations which meanns they could lose data in a transmission. This was 'fixed' by adding the SO_LINGER flag to the socket options on these systems (configurable in the Configuration file). Unfortunately, this seems to have created other problems on these systems. An alternative work-around for the original problem is under development, which effectively implements SO_LINGER functionality inside Apache.

Source Code Style
Anyone who has browsed the Apache source will have noticed that various parts are coded in differing styles. This is due to the collaborative nature of the development on the software, but the different styles can make the source confusing. The use of a programming style guide is currently under heavy discussion.

Comments or criticisms? Please email us at editors@apacheweek.com