In this issue

Following hot on the heels of Apache 1.1 is a minor upgrade version, release 1.1.1. This fixes five bugs in the 1.1 release:

• Redirect in .htaccess files did not work
  The new ability to put Redirect directives in .htaccess files did not work.
• Negotiation and handler interaction
  If a handler was specified for a file obtained through negotiation, the handler was ignored and the file served as plain text.
• mSQL authorisation problem
  If the mSQL authorization module was compiled it (mod_auth_msql), it affected the use of other authorization methods in .htaccess files.
• Misspelt anonymous directive
  The directive Anonymous_Authorative was mispelt: it has been changed to Anonymous_Authoritative.
• Format error in cookie log
  A format error in the log created by mod_cookies has been fixed.

Actually, these are all 'bugs' in the documentation.

• mod_env cannot set PATH
  The comments in mod_env show an example of setting the PATH environment variable with SetEnv. But the two environment variables which cannot be set are PATH and TZ.
• ErrorDocument mis-documented
  The documentation for ErrorDocument says that a %s token can be used in a string error message to insert the text of the original error. This does not work.
• Other documentation errors
  Various other mistakes in the documentation have been noted. These are mainly typographical, but there is also the problem that some parts of the documentation apply to Apache 1.0 and have not been updated to 1.1.

The next stable release will be probably be called 1.2, which will incorporate many of the features we've reported on in "Under Development" over the past few weeks. A few big changes (such as making the server multi-threaded) might wait until version 2.0. If any serious bugs or security flaws come to light there might well be a 1.1.2 release, but there should be no new features in 1.1.* versions.

All of the features required by the HTTP/1.1 specification have been implemented in an experimental version of Apache, except for proxying. This makes Apache 'unconditionally compliant' with the 1.1 spec. Amongst the new features in HTTP/1.1 are:

• Byte Ranges
  Clients can request parts of documents, for example, to request continuation parts of interrupted transfers.
• Chunked Transfers
  Resources can be sent in parts (called chunks) to allow for dynamically-produced content.
• New Request Methods
  New request methods can be used: OPTIONS, to find out about the capabilities of the server, and TRACE, for testing.
• More Conditional Requests
  Currently clients can check whether the resource on a server has been updated since they last retrieved it. New headers now can be used to check whether a resource has not changed, or to match documents using special identifiers called entity-tags.
• Enhanced Content Negotiation
  Requested resources might exist in several different variations: different languages, different formats (gif and jpeg, for instance), and different character sets. In HTTP/1.0 the server could do content negotiation, but this is extended in 1.1 to allow the browser to select from a list (this is not fully defined, however).

Also under development this week is a module to handle PICS content rating. This system provides a means of labeling content on a site, which can be used to restrict access if desired.

The source for Apache is being cleaned up a bit. The overall aim is to make configuring Apache for different systems as easy as possible. This is being done by creating options for each of the facilities which some operating systems lack. These features can then be implemented within the Apache source, or some alternative can be found. Each feature will be controlled by a #define'd name of the format HAVE_feature. For example, systems with the mmap() function call will have the HAVE_MMAP name defined.

The use of this naming scheme means that in the future it might be possible to configure Apache with an autoconf tool, such as the one from the GNU project.

Authoring tools such as Netscape Navigator Gold and GNN Press can be used to put documents onto a server. For this to work, the server needs to be able to handle the submitted document. The way to do this is with a script called for each PUT request. The biggest issue when developing a script like this is security: great care has to be taken to ensure that the script cannot be used by one person to update documents owned by another, or worse.

A method for making PUT scripts (and cgi in general) more secure is under development as part of the threaded version of Apache.

A report indicates that Apache's performance with persistent connections (Keep-Alives) might be less than optimal. In fact, in tests, the performance with Keep-Alives turned on is 10 times slower than without. This is due to interactions between the way the server sends data and the underlying implementation of TCP transmission protocols, and is not a bug in Apache. However, the test environment was a local ethernet, which is not typical of Web requests across the Internet. Persistent connections are designed to reduce the transfer times of documents containing multiple images by eliminating the need to create a new connection for each image. This setup time is much greater across the Internet than across a local ethernet segment.

The report provides a couple of patches to improve performance of Keep-Alives. This first patch prevents the headers being sent in a separate TCP packet (or segment). However this behaviour was implemented to overcome a bug in some versions of Netscape, which would hang on a connection if it read the entire document (headers and the document) in a single read. A work-around would be to only send the headers in a separate segment if the whole document would be too small for Netscape.

The access.conf-dist distributed with version 1.1 and 1.1.1 is heavily modified from that in previous versions. One change which may have gone unnoticed is that the <Limit> and </Limit> directives are now omitted. The <Directory> section now looks like this (comments omitted):

<Directory /usr/local/etc/httpd/htdocs>
Options Indexes FollowSymLinks
AllowOverride None

order allow,deny
allow from all
</Directory>

Normally there would be a <Limit GET POST PUT DELETE> ... </Limit> section arround the order and allow directives.

The reason for this is future-proofing (as well as simplifying the file!). In the future, new methods will be add to HTTP to complement GET, POST and so on. In fact, HTTP/1.1 defines OPTIONS and TRACE, and lists some other possibilities. The original way of listing methods in the <Limit> would mean that each <Limit> would need updating with all the new methods every time a new method was added - and this would need doing in all .htaccess files as well.

To make this a lot easier, it is possible to put any of the commands normally found inside a <Limit> section outside a <Limit>. The directives such as order, deny, allow and require can be used like this. When placed outside a <Limit> section these commands apply to all the methods.

NetscapeWorld reports on the Netcraft server survey, which shows Apache is still gaining user share. Apache is now the only server running over 100,000 sites on the Internet, or 35% of all sites surveyed.