Apache Week
   Issue 57, 21st March 1997:  

Copyright 1996-2005
Red Hat, Inc.

In this issue

Apache Status

Release: 1.1.3 (Released 14th January 1997)
Beta: 1.2b7 (Released 22nd February 1997)

Bugs reported in 1.2b7:
  • In mod_rewrites rules, the REMOTE_IDENT variable was not set if used inside a virtual host where rfc1413 checking is off in the main host but turned on in the virtual host.
  • CGI scripts can take three extra seconds to complete if accessed via an SSI directive.

Bugs fixed in next release:

  • Persistent connections are used whenever it is safe to.
  • Use chunked encoding for responses where possible, not just if using persistent connections
  • There were no write timeouts on certain parts of sending responses (headers, error responses, last part of chunked response) which could lead to processes stuck in write.
  • The log_printf module API function cannot be using during the create_server_config callback if virtual hosts are defined.
  • Status module counts of bytes and connections served may be counted wrongly.
  • The mod_auth_anon module can check email addresses, but allowed addresses with either a dot or an @ - better address checking is to check for both a dot and @.

Apache is currently in a 'beta release' cycle. This is where it is made available prior to full release for testing by anyone interested. Normally during the beta cycle no new major features will be added. The full release of Apache 1.2 is expected in April.

Putting Modules in Separate Directories

The generation of the Makefile in the modules directory has been improved so that it is easier for third-party modules to be located in separate directories under the modules directory.

From the next release, additional modules can be placed in a subdirectory under the src/modules directory. When the relevant Module line is added to the Configuration file, Apache will make all the required modules. The module author should supply a Makefile with their module which by default builds the module (either as an object file or a library).

Virtual Hosts Explained

The use of virtual hosts in Apache is closely connected with the DNS. If the Apache cannot resolve the name of the virtual host into a number during startup (or after a HUP signal), Apache will die. While this provides a safe default - if Apache starts, you know it managed to configure all the virtual hosts - it has caused problems on some sites where DNS resolving sometimes fails. The best solution in this case is to fix the DNS resolver so that it works all the time. Alternatively, Apache can be configured in such a way that it does not need to do the name to number translation, by always giving the IP address inside of the virtual host name. A document explaining how Apache can be setup like this is available on the Apache site, in DNS caveats.

This document also covers the security problem where one user of an Apache virtual host on a site could configure their DNS in such a way that they intercept traffic destined for other virtual hosts on the same server. Alternatively, a malicious customer can setup their DNS so that Apache fails to start at all, which would deny access to all other customers' web sites on the same physical server.

This second security problem is caused because Apache fails to start at all if it cannot configure a virtual host. The next beta release will continue to start the server, but disable any virtual hosts that could not be configured during startup. Messages about the failed virtual hosts will be displayed on the screen to provide a warning.

The way that Apache interacts with its virtual hosts is explained in detail in a new Apache site document, vhosts in depth. This document also explains the order in which virtual hosts are chosen, and the new special virtual host name of _default_ (which used to be called in previous 1.2 betas).

Apache for the Amiga

Apache has been ported to the Amiga. Apache 1.0.5 is already available, with a late beta of 1.2 in progress. A set of pages about Apache on the Amiga are currently under construction. Note that this work is not being done by the core Apache developers.

Standards: HTTP/1.1 Clarified and Extensions Proposed

Several new draft standard are now available. These are all proposals to extend the HTTP functionality with new features or clarify the existing HTTP/1.1 specification, RFC2068.

Use and interpretation of HTTP version numbers and Problem with HTTP/1.1 Warning header, and proposed fix clarify RFC2068. The former explains what HTTP version number servers should respond with, and the latter solves some problems with the definition of the Warning header in HTTP/1.1.

The User Agent Hint Response Header draft defines a new HTTP header, Ua-Hint, which can be used to mark resources as safe to re-POST and control client history lists, amongst other things.

HTTP State Management Mechanism defines how to store state at the client end, commonly referred to as 'cookies'. It is intended to replace the existing definition in RFC2109.

Note that all these documents are "Internet Drafts" which mean that they are still under revision and may not necessarily become standards. Many other standards related to Apache and web servers in general are available on the Apache Week Apache Links page.

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