In this issue

Release: 1.2.1 (Released 6th July 1997) (local download sites)
Beta: None
Alpha: 1.3a1 (Released 23rd July 1997) (local download sites)

Bugs fixed in 1.3:

• Better compile options on Aviion DG-UX
• Fix potential core dump in mod_mime_magic when decompressing compressed files
• Make mod_mime_magic compile in BSDI
• Solaris and OSF/1 compilation warnings

Patches to Apache 1.2 bugs will be made available in the apply to 1.2.1 directory on the Apache site. Some new features and other unofficial patches are available in the 1.2 patches directory. For details of all previously reported bugs, see the Apache bug database and Known Bugs page. Many common configuration questions are answered in the Apache FAQ.

Unless otherwise noted, all the new features discussed here are planned for Apache 1.3 and not Apache 1.2.1.

Apache is configured for compilation using Configure which has information on many types of operating systems. However there are often variations between different installations of the same system, such as different libraries installed. In the past this has meant that some people have to edit Configuration to set additional options (for example, to set the dbm library if it is not called dbm). Now Apache can automatically check for existence of libraries and other installation specific information. For example, on Linux it checks to see if the dbm library is called dbm or ndbm.

A new version of dbmmanage is under development. This is the perl program which can be used to manage dbm format htpasswd files. These are the files used to store usernames and passwords for user authentication. DBM format files are much more efficient than the normal plain text files when there are a large number of users.

The new dbmmanage program is a complete rewrite and requires perl 5. New features include:

• Support for db, ndbm and gdbm format file, automatically chosen.
• A new check command to check a users' password
• A new import command to convert existing plain text htpasswd files into a db or dbm.

At present Apache is distributed with two similar but slightly different programs, dbmmanage and dbmmanage.new

If a Unix process causes a segmentation violation or certain other serious errors, the operating system dumps the current status of the program memory into a "core" file. This is put into the current working directory of the program. For Apache child processes this directory is the server root directory, which should not be writable by the user that the child processes run as. So no core file can be dumped. A possible future enhancement would be a new directive to specify a directory to be used for core dumps. If this is implemented care should be taken to ensure that the resulting core file cannot be accessed by other users on the system since the core dump may contain details such as passwords.

An experimental module is under development which should serve static files from the disk faster. Normally Apache serves these files from the core code, by reading the file into memory a block at a time and sending it out over the network. This new module uses the Unix "mmap" functionality to map the contents of the file directly into memory. Most versions of Unix support mmap functions.

The error_log file logs various errors, some of which are more important than others. As we covered in Apache Week 71 a future release of Apache will offer the ability to log only more important errors by using "log levels". As part of this change the format of the error_log may change. At the moment the format is largely based on that written by the NCSA httpd server. Changes may be made to make automatic processing of the error_log file easier, and to give the different errors and warnings a consistent format.

The JSDK/Apache project is intended to extend Apache to serve Java "Servlets". This is Java code which runs on the server, and interfaces to the server using the methods defined by JavaSoft in the "JSDK". The homepage for this project is at java.apache.org.

A number of changes are being made to the way that the hostnames or ip numbers on allow and deny directives are handled. These include

• Allowing IPs to be given by arbitrary subnets using either CIDR syntax or full network/netmask. For example, in CIDR you could apply a restriction to all the machines with IPs from 172.16.0.0 through 172.31.0.0 using 172.16.0.0/12. Using a netmark, this could also be given as 172.16.0.0/255.255.224.0.
• Adding better hostname security by performing a "double reverse" lookup when checking hostnames. This attempts to prevent DNS spoofing by checking that a hostname associated with a IP does infact map to that IP address. The result of this double reverse lookup is only used to check against the hostname given on the allow or deny lines, not passed to CGIs or SSI.
• Adding a HostnameLookups double option to turn on the above double reverse lookups for all uses of the hostname, including the name passed to SSI and CGI scripts in REMOTE_HOSTNAME, for example.
• Speeding up processing of allow and deny lines by pre-computing as much as possible while reading the configuration files.

The use of double reverse lookups for hostnames and the new HostnameLookups will provide what the compilation option MAXIMUM_DNS does

The browser module can be used to set environment variables based on the browser's user-agent string. This will be replaced in the next release with a more general module, mod_setenvif, which sets environment variables based on any received header or various other information about the connection (e.g. the remote ip address). For backward compatibility the existing BrowserMatch and BrowserMatchNoCase commands are implemented by this new module.

The directive SetEnvIf is used set to an environment variable. For example, to set the variable LOCAL if the client is from within your local network, you could use

  SetEnvIf remote_addr 192.168.10. LOCAL
  SetEnvIf remote_addr 127.0.0.1   LOCAL

where 192.168.10 is your local network and 127.0.0.1 also sets LOCAL if you use the localhost address on your server itself. The second argument can also be an regular expression, so this could be re-written

  SetEnvIf remote_addr ^(127\.0\.0\.1|192\.168\.10\.) LOCAL

You can then tell people who write SSI or CGI programs to check for the LOCAL environment variable to see if a connection comes from a local machine. Because this is configured centrally, if the definition of the local network changes you just change the configuration, and do not have to update the SSI or CGI programs.