In this issue

The Christmas "vacation" saw more work on Apache, with two new betas being released. Beta version 3 was released on Christmas day, and beta 4 on New Year's Eve. Both betas contained a number of bug fixes (the combined list is given below).

The latest version of the HTTP protocol is now an official proposed standard with the publication of RFC2068. This now puts HTTP/1.1 on track to become an standard protocol on the Internet. The previous version, HTTP/1.0, was only documented in the "informational" RFC1945. HTTP is the protocol which forms the basis for every web transaction: it says how browsers and servers communicate. See also our feature on what HTTP/1.1 is and how it will improve the web.

Another RFC was published along with RFC2068. This is RFC2069 which documents the "Digest Authentication" method for more securely exchanging username and password information. This standard should really be considered part of the HTTP/1.1 specification, and products which implement HTTP/1.1 from RFC2068 should also implement RFC2069.

Other standards in progress include Transparent Content Negotiation and State Management (cookies).

Release: 1.1.1
Beta: 1.2b4 (Released 31 December 1996)

Bugs fixed in 1.2b4:

• Access restrictions deny, allow and order were not allowed inside <Files> sections
• Suexec problems with home directories that are symbolic links, using + to separate arguments on URL and users in multiple groups.
• OS specific updates for AIX, SunOS, Solaris, OS/2 and Machten 4.0.3
• Various proxy module enhancements and bug fixes
• Possible minor security hole due to race condition creating lock files
• Large static buffers in mod_rewrite removed
• Occasional core dumps in SSI files

• Possible byte loss in transmitted response during keepalive
• phf log script (phf_abuse_log.cgi) does not log the referrer properly
• Tar icon in directory listing is larger than other icons
• Log file occasionally reports duration times as if the request arrived on the Unix epoch (Jan 1970)
• A ServerPath which matched the start of a filename would hide that file
• CGI variable REMOTE_PORT has wrong value of systems with different byte order from the network order
• suexec can occasionally crash on some systems
• Config log logs an empty string ("") for %u when returning a 401 status, which will confuse programs which parse the fields in the logfile.
• Potential security problems with suexec, log files and buffer overflows (some might just require documentation)

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 at the end of January or early February.

Apache uses three configuration files containing server configuration (httpd.conf), resource mappings (srm.conf) and access control (access.conf). In NCSA's httpd directives could only appear in specific files, but Apache treats all these files identically. So it is possible to use just one file (usually httpd.conf) for all the configuration directives. However for NCSA compatibility Apache used to complain if any of the files were missing, so the other files could not be deleted (just left as empty files). Alternatively, the ResourceConfig and AccessConfig directives could be used to point to an existing (but empty) file, such as /dev/null. In the next release, Apache will not complain if the standard resource and access configuration files are missing.

A new phase has been added to the module API. This is a "parse headers" phase that can be used to set configuration information based on the headers in the incoming request. This phase has been added to allow the browser module to set environment variables based on the client's 'User-Agent' (browser name) earlier in the processing of the request. The variables are then available during later phases such as access restrictions or when constructing the response headers. This could be used, for example, to implement a way of forcing a "HTTP/1.0" response to work-around clients which have problems with responses marked as HTTP/1.1.

When module authors define a directive which takes single string argument, they can use a generic function to store the value from the directive. A similar function has now been added to the API for directives which take a single flag value ("on" or "off").

No major new features are being added to Apache at the moment. However some new features have been developed or contributed, and are available as source code patches from the patches directory. New since the last issue is a patch to the proxy module which makes it automatically expand short incomplete names, such as "ibm", into proper host names (e.g. "www.ibm.com"). Netscape Navigator and Internet Explorer browsers do this, and using one of these browsers with the current Apache proxy means users lose this "feature". This patch makes it work again in this situation. However this patch is unlikely to make it into Apache itself because it does hostname expansion that may not be appropriate in all cases.

Before Christmas, AOL updated their proxy software so that it would block access to Apache 1.2 sites. This created a large reaction from content providers and ISP's whose sites became inaccessible to AOL users, and from AOL users who could no longer access some sites. Given that Apache 1.2 is likely to become very widely used this policy would have disconnected a large number of users from many sites of the Internet.

Fortunately AOL changed it's policy on Christmas Eve and unblocked Apache 1.2 sites. More information about the temporary AOL block and why it was a major issue are available in this document at the Apache site (this was written before the block was reversed).

Apache is the first major server to implement HTTP/1.1. This is the first time that web client products have been used against a real 1.1 server, and some products do not work properly. This is due to software bugs (as opposed to the AOL problem, which was a policy decision with no technical justification). Whenever Apache 1.2 replies to a browser or client, it includes the text "HTTP/1.1" to indicate that it is a HTTP/1.1 server. Properly written clients should treat this the same as seeing "HTTP/1.0" and work normally, but others will not expect the 1.1 version number and fail. Problems have been reported with Sun's Java Development Kit (JDK) version 1.0.2 and Symantec's Cafe 1.5 environment. The JDK problem may will affect other products built on this library.

Because of these (and possibly other) software problems with clients, Apache 1.2 will probably include a special configuration directive to get it to pretend to send a "HTTP/1.0" response (it will 'pretend' because it will actually still send a HTTP/1.1 response, it will just mark it as being HTTP/1.0). Since most browsers and clients work fine with HTTP/1.1, this should only be enabled for clients with known problems handing HTTP/1.1. This can be done by looking at the client's 'User-Agent'.

There is increasing interest in a version of Apache for Windows NT. At the moment, Apache will work on almost all Unix operating systems, usually with only minor modifications to OS-specific capabilities. However NT has some major differences from Unix so at the moment Apache does not work on NT without significant work. It is planned to do a major update to the Apache code after 1.2 is released, including support for multithreading and extra layers of abstraction to make handling different underlying operating systems easier. A page describing the current status of any NT version is now available on the Apache site.