In this issue
Bugs in 1.1.1:
Negotiation module negotiates on proxy requests
Host: header can override IP addresses in VirtualHosts
deny and allow cannot handle hostnames starting with
numbers (e.g. 123.domain.com)
ProxyPass can give back a redirected URL rather than
munging it into a reference via the proxy
Digital Unix 4.0 requires -lm library
A multi-threaded version of Apache is under development. It
is not yet clear whether this will form part of release 1.2,
or wait until 2.0.
Multi-threading is a software term that means that the
program does several things at once. In a traditional
program, execution continues from one statement to the next
in a linear and predictable fashion. In a multi-threaded
program, one, two, or more parts of the same program can be
executing at the same time. In Apache this means that a
single copy of the server can handle multiple requests
The current version of Apache does something like this
already: it can handle multiple requests by running several
copies of the server. However this is not multi-threading
because the running programs are different copies, each of
which is a different process. In a multi-threaded
sever, a single process could be handling a number of
requests at the same time. The advantage this gives is
two-fold. Firstly, the operating system does not need to keep
swapping between different processes, which is slow.
Secondly, any static information shared between all the
requests (such as the server configuration) can be shared
between all the threads running at the same time, instead of
being repeated in each process.
Larger sites with high hit rates, or sites using
configurations which take up a lot of memory are likely to
benefit most from multi-threading.
The following new features will be in the next release:
Status module improvements
The status module now records the length of time taken to
process each request, and displays it for the most recent.
It also handles very large totals better.
When the server is sent a HUP signal to re-read it's
configuration files, it currently cancels all transfers in
progress. The next release introduces an new signal, INT,
which does the same as HUP but does not kill currently
Fixes for some systems
Compilation warnings on IRIX and a problem with closing
connections on A/UX are fixed, and a configuration option
for HPUX 10 is now available.
Perl Module in Beta Test
module, which runs perl scripts as part of the
server, has moved into beta test phase.
Why Use Secure Transactions?
Most of the information passed across the Internet is not
particularly sensitive. In fact, most if it is specifically
designed to be as widely read as possible. But some
information is sensitive. For example, when ordering from a
site via credit card, the credit card number is transmitted
across the Internet from the browser to the server. In
theory, a third party could intercept this information at
some point on the network between the browser and the server.
To prevent this, some form of encryption can be used
so that even if someone intercepts the data they cannot
decode it back to the original credit card number (or what
ever else it was that was encrypted). Obviously both the
browser and the server need to use the same encryption
method. The most widely implemented encryption method at
present is SSL.
SSL stands for Secure
Socket Layer, a protocol developed by Netscape for secure
transactions across the Web. It uses a form of public
key encryption, where the information can be encoded by
the browser using a publicly available public key, but
can only be decoded by someone who knows the corresponding
Any product can incorporate SSL technology without paying any
royalties. Extending Apache to handle SSL is a programming
job, made relatively easy by the availability of a free SSL
implementation, called SSLeay.
However, the US government effectively prevents Apache from
US Arms Export Restrictions
The US Government imposes export restrictions on arms, in a
set of rules called ITAR (International Traffic in
Arms Regulations). Amongst the restricted arms is "strong"
encryption software. (See the EFF
archive on ITAR). Software that implements SSL in the US
cannot be exported because of these rules (actually, it can
be exported to Canada, but no further).
Apache is developed by an international team of individuals,
using a server in the
US. The ITAR rules mean that if the Apache server included
SSL it could not be exported outside the US. This would
prevent the non-US developers from continuing to work on it,
and would stop anyone outside the US from using Apache. A
solution to this problem adopted by some free software
developers is to run a parallel development effort outside
the US. The US development would not contain any SSL or
encryption technology, while the non-US version would. The
main problem with this arrangement is ensuring the parallel
development of the two versions, and it would also require a
non-US site to host the development.
The problems with the export restrictions of ITAR are not
limited to Apache or other free software. Many US
corporations are concerned that their competitors in other
countries are able to make and sell encryption-enhanced
products which they are forbidden to export. (See
In the meantime, while Apache remains an international
software development based on a server in the US, it cannot
incorporate SSL. A free implementation of Apache with SSL
(using SSLeay) is available as Apache-SSL
from AL Group in the UK. This is legally useable anywhere in
the world except the US for free. The problem with using this
version in the US is not the export regulations (which only
apply to export, not import), but rather because of the
sometimes confusing issues of encryption patents and
Encryption Patents and RSA
The version of SSL used in Netscape uses an encryption method
developed and patented by RSA
Data Security in the US. Use of this technology normally
requires a license fee inside the US. If Apache-SSL is
imported into the US, then any user would have to arrange to
pay the appropriate license for the patented encryption
methods which are part of SSLeay (although non-commercial
users can use a license-free implementation of RSA, called
RSAref). The alternative to paying the RSA license
individually is to buy a commercial version of Apache with
SSL for which RSA has already been licensed by the developer.
The two main products available are StrongHold and Sioux. Note
that since Stronghold is developed in the US and incorporates
encryption the ITAR rules prevent it being used outside the
US and Canada.
Outside the US, no license fee is required for the use of the
RSA methods because they are only patented inside the US.
This means that outside the US Apache-SSL can be used for
Having got a server, the final thing required before it can
be used for secure transactions is a certificate.
A server certificate is a piece of digitally-encrypted
information that lets the browser know what organisation it
is accessing. To prevent people just making up certificates
and pretending to be official organisations, certificates can
be obtained from a certificate authority, who use
their position as a third-party to verify that the
organisation using the certificate is who they say they are.
Probably the best know authority is Verisign in the US. In
fact, early versions of Netscape Navigator (version 1) would
only accept certificates from Verisign. However now the
browser will accept other certificating authorities, but only
after presenting a series of dialogue boxes to the user. If
the server operator wants their certificates to be accepted
transparently by Netscape they will have to get certificates
signed by Verisign. Also Microsoft's Internet Explorer
version 2 cannot accept any other certificate authorities
(this is fixed in IE version 3).
To get a certificate from Verisign the server in use must be
approved. Most commercial secure servers will have been
submitted for approval by their developer, and certificates
are available for both StrongHold and Sioux. Verisign only
approve servers available in binary form, because they
require servers to have been audited to ensure that they meet
their security requirements. Both Sioux and Stronghold have
been approved, and provide the source code for information
only. Apache-SSL and any other source-only developments of
Apache are not approved, so cannot be issued a Verisign
Users of Apache-SSL can either get a certificate from another
authority, or become a certificating authority themselves
(the tools to be this are part of SSLeay).
To get a secure server based on Apache, first decide whether
you need a certificate signed by Verisign or not (this is
determined by whether you mind your users going through the
Netscape security wizard when they first connect to your
server, or possible using browsers that cannot connect to
your site). This may not be a problem in an Intranet
environment where you can distribute a browser with your
certificate authority already configured. Then:
Inside the US and Canada
Buy a Verisign-accredited, RSA licensed server (e.g.
Stronghold or Sioux) and buy a certificate from
Download Apache and Apache-SSL patches, compile, pay
RSA license for RSA-patented technology, and sign own
Outside the US and Canada
Buy a Verisign-accredited server from a non-US vendor
(e.g. Soiux) and buy a certificate from Verisign,
Download Apache and Apache-SSL patches, compile, and
sign own certificate
Mac expert chooses Apache
"The Well Connected Mac: Your Online Guide To Everything
Macintosh" site uses Apache rather than a Mac server. The
site owner explains why.