Release: 1.2.1 (Released 6th July 1997) (local download
Bugs in 1.2.1:
All Solaris versions before 2.6 can fail to rebind to the
network socket after a HUP due to a bug in Solaris. This
patch works around the problem on Apache 1.2.1.
Alpha: 1.3a1 (Released 23rd July 1997) (local download
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
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
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
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
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
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.