In this issue
1.0.5 is the current stable public release (it is 1.0.3 plus
a security 'fix'). The beta test version, 1.1b, is now at
A number of bugs in 1.1b are being fixed, but there have also
been a few that affect the previous full releases (including
1.1b: Apache waits for background CGI processes
If a CGI process closes STDOUT, Apache should continue with
other things. This lets a CGI program put itself into the
background. This does not work in 1.1b1 or 1.1b2. This is
All: imap module returns redirects to relative URLs
If the map file used by the imap module contains relative
URLs (eg "rect file.html x,y x,y"), Apache might return a
Location: header containing a relative URL. The cause of
this problem is under investigation.
All: Bad permissions on .htaccess files can leave
If Apache cannot read a .htaccess file, it behaves as if it
does not exist, since obviously it cannot process any of
the commands from the file. However if the .htaccess is
designed to secure an area, it might be made unreadable by
error, and the current operation would default to more
openness than might be desired. It might be more
appropriate to default to not allow access if a .htaccess
file exists but is not readable. This is not a bug, but the
way Apache behaves in this case will probably be changed in
a later version to avoid this trap.
1.0.x: Auth Basic passwords cannot start with :
If a password stored in the basic auth password file starts
with a colon, the leading colon (or colons) will be
ignored. This will be fixed in 1.1.
1.1: Using HostNameLookups Off prevents .htaccess allow
or deny by name
If hostname lookups are turned off by HostNameLookups Off,
then use of hostnames in allow and deny lines in .htaccess
files does not work. This is logical, but might not be
expected. More importantly, it should be possible to use
HostNameLooksup On in the .htacess file to turn them back
on, but this does not appear to work.
1.1: Keepalives default to off in virtual hosts
The keepalive option is set to off for virtual hosts, even
if Apache is compiled to turn it on by default. This is
will be fixed in the next 1.1b release.
There are proposals to extension the HTTP protocol to allow
URL requests to incorporate "byte ranges". This would allow
clients to request parts of documents - perhaps if only
part of a document was downloaded because of an error, or
to obtain (say) a single page of a large document. Byte
range requests were originally implemented in Netscape
products, using a different protocol. There is now an
Internet Draft on byte ranges, and they might be
implemented in HTTP/1.1.
Once the protocol has been finalised, it will
probably be incorporated into a future version of Apache.
Byte ranges are important for Adobe's PDF document
Status Module improvements
The output from the status module (part of 1.1beta) has
been through an overhaul. It now displays the status of
each child process in a table, along with some additional
information. There is a non-tables version as well.
The module which builds the Perl 5 interpreter into Apache
has been updated to work with the 1.1b module API. When
released, this will allow Apache to interpret perl scripts
internally, saving the need to start up perl for each perl
CGI script. This will provide a speed enhancement (at the
expense of much large Apache processes).
Finding out about your modules
A new module is under development that lists the other
modules compiled into a running Apache process. Like the
status module, it is queried by a request for a special
URL, and it returns a complete list of compiled in modules.
This might be incorporated into a later 1.2 release.
CGI programs are very popular on Web because they allow
dynamic pages and enhanced interactivity, and can be written
in fairly easy-to-use languages such as shell script and
perl. However on heavily loaded sites CGI performance can be
a problem because of the need to start and stop a program
each time a CGI script is called. That is where the Apache
API can help, since it allows programs to be compiled into
the server. But this has some disadvantages: it has to be in
C, it uses a fairly complex programming interface (the Apache
module API), and bugs in the module can interfere with the
server itself. Last but not least, modules only work with
Apache, and there are two other module APIs that module
developers might want to work with (NSAPI and ISAPI).
These issues are now addressed in an new specification: FastCGI (developed by
OpenMarket). This is designed to be a fast, open and secure
interface between Web server's and other applications, which
can be local or on a remote system. OpenMarket have made
available an Apache
module to implement FastCGI.
And the nominees are...: Apache has been entered in
the Global Information
Infrastructure Awards. The problem is, if Apache wins,
who goes to the ceremony, and more importantly, who gets the
medal and certificate?
Comments or criticisms? Please email us at firstname.lastname@example.org