In this issue

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). This might be the last beta release.

A new beta of 1.1 was released, version 1.1b4. It has a number of changes over 1.1b3:

• API access to the request structure r->bytes_sent restored
• Previously broken multi-method <Limit> parsing fixed.
• Some more possibly unsecure programs removed from the support directory.
• More mod_auth_msql authentication improvements.
• VirtualHosts based on Host: headers no longer conflict with the Listen directive.
• OS/2 compatibility enhancements.
• POST now allowed to directory index CGI scripts.
• Actions now work with files of the default type.
• Bugs which were fixed: more mod_proxy bugs, early termination of inetd requests, compile warnings on several systems, problems when scripts stop reading output early

Several new bugs have been noticed and fixed in preparation for a 1.1 release.

Limit wierdness

Attempts to limit access for PUTs, but to allow unrestricted GETs would use a .htaccess (or <Directory>) restriction like this:

   AuthType Basic
   ...

   <Limit PUT>
   require ...
   </Limit>

However, this also affects GET requests. This is fixed in the latest beta version.

On a similar aspect, there is a long-standing Apache bug (or at least difference from NCSA), when a .htaccess file like this is used:

  AuthUserFile /dev/null
  AuthGroupFile /dev/null
  AuthName EnterPassword
  AuthType Basic

  <Limit GET>
  order deny,allow
  deny from all
  allow from .my.domain
  </Limit>

This .htaccess is designed to restrict access based on browser address, and not require any user authentication. It is used in the NCSA tutorial on access restriction. The problem is that Apache will ask for user authentication, which fails because none has been setup. Apache does this because of the Auth* directives, which are unneccessary. The fix is to remove the Auth* lines.

Possible Keepalive Problem

There has been some reports of Netscape appearing to 'hang' on connections to Apache. This seems to be due to keepalives, where the client closes the connection and the server does not notice. This seems to affect both Micrsoft Internet Explorer and Netscape on Windows 95, and might be a windows 95 problem.

Location in .htaccess

The 1.1 beta releases include a new directive, <Location>, which behaves like <Directory> but which can apply to URLs other than directories, such as URLs which do not map onto files, or to individual files. In fact, it is a good way of applying restrictions to individual files. However, the <Location> directive is only valid in the central configuration file (normally access.conf), but it would be useful if files could be restricted from .htaccess files as well. This might be incorporated into a future version.

Handling Configuration Errors

When Apache encounters a syntax error in one of its configuration files (access.conf, httpd.conf or srm.conf), it prints an error message and stops. This is the safest behaviour, since it prevents accidently insecurities in the configuration. However it might be nice if some configuration errors could be treated as warnings. This would be useful in several situations:

• When a module is not compiled in, all it's configuration directives have to be removed or commented out. It would be more convenient if they could be left in.
• When the server is restarted (with a HUP signal, for instance) an error in a configuration command will cause the server to stop completely. This is can be inconvenient when the server is being restarted in the middle of the night (eg during log file rotation).

So, it might be preferably to treat some errors as warnings, and let the server continue. The difficulty is that some configuration errors could leave the server in a less secure state. For example, if "AllowOverride None" was mistyped as "AllowOveride None", it would not prevent options being overriden in .htaccess files. Other configuration problems could confuse the server: for example, if the start of a virtual host section was misspelt (e.g. "<VirtuallHost>"), the directives intended for that virtual host would be applied to the whole server. Any system which treats errors in configuration files as warnings will need to handle these and similar cases with great care.

New version of the Perl module

A new version of the Apache perl module is available. This is still an alpha test release.

Whenever Apache handles a request, it processes .htaccess files which determine access authorisation, and can set other options (e.g. AddType). It checks and processes .htaccess files in the same directory as the file it is serving, and also in all the parent directories. For instance, if you request the URL /docs/about.html and your document root is /usr/local/etc/httpd/htdocs, Apache tries to process .htaccess files in all these directories:

/
/usr
/usr/local
/usr/local/etc
/usr/local/etc/httpd
/usr/local/etc/httpd/htdocs
/usr/local/etc/httpd/htdocs/docs

Normally, there will be no .htaccess files above the document root, but Apache still needs to check the filesystem to make sure. This can be eliminated by using the trick that if the AllowOverride option is set to None, Apache doesn't bother checking for .htaccess files. So set AllowOverride to None for directory /, and turn AllowOverride back on for whatever settings are really needed for the directory /usr/local/etc/httpd/htdocs. For example, the following code in access.conf would speed up Apache:

<Directory />
  AllowOverride None
</Directory>

<Directory /usr/local/etc/httpd/htdocs>
  AllowOverride All
</Directory>

The second directory section turns on AllowOverrides, so that .htaccess files are processed again. The 'All' can be replaced with whatever level of configurability is wanted.