In this issue
Release: 1.1.3 (Released 14th January 1997)
Bugs reported in 1.2b10:
Beta: 1.2b10 (Released 30th April 1997)
If multiple virtual hosts were defined with the same server
name and address, but different ports, Apache will only use
the first one defined.
Using mod_imap imagemap module, attempting to direct to a
internal link with, say, rect #target 0,0 50,50
causes Apache to redirect to a URL with the
filename part missing (i.e.
When using keepalives and name-based virtual hosts,
requests on a keptalive connection can get a response from
the wrong virtual host.
Bugs fixed in next release:
Change makefile to allow extra libraries (on
EXTRA_LIBS) to make use of regex calls.
Patches to Apache 1.2b10 bugs may be available in the 1.2b10
patches directory on the Apache site. At time of writing
there are no patches and this directory does not exist.
For details of all previously reported bugs, see the Apache
Many common configuration questions are answered in the Apache
Apache is currently in a 'beta release' cycle. This is where
it is made available prior to full release for testing by
anyone interested. Normally during the beta cycle no new
major features will be added. The full release of Apache 1.2
is now expected in May.
The year 2000 is predicted to bring chaos to software which
is unable to handle dates beyond 1999. The question is what
effect the change of century will have on the Internet, Web
and Apache in particular. This feature shows what the risks
The Year 2000 Problem
The theory of the year 2000 problem is that many older
programs use only two digits for the date, such as "97" or
"06". This might be part of the internal storage, input
fields, output display, or network communcation protocol. If
a program does use a two digit date, it might either not
accept year 2000 dates such as "02", or it might make
incorrect comparisons (thinking that 02 is earlier than 97,
because it assumes that 02 is 1902). There are some areas
where two digit years are widely used - for example, on
credit card expiry dates - and the software which handles
these dates will have to be capable of knowing that smaller
values for the date are really in the 21st century.
Years in Apache
There are three things which can affect how Apache treats
year 2000 issues:
Apache code itself
The HTTP and other protocols that Apache implements
The underlying operating system
The Apache code internally never stores years as two digits -
it processes dates and times as standard Unix time epochs (the
number of seconds since 1st January 1970). When it outputs the
year (e.g. to the log file) it writes years as four digits.
The HTTP protocol may be more troublesome. It allow for three
different date formats in requests and responses, one of
which uses a two-digit year. Dates are used on every
response, in fields such as "Date", "Last-Modified" and
"Expires", and requests can contain dates in the
"If-Modified-Since" and similar fields. The date formats
listed in HTTP/1.1 and HTTP/1.0 are:
Sun, 06 Nov 1994 08:49:37 GMT (defined in RFC
822 as updated by RFC 1123)
Sunday, 06-Nov-94 08:49:37 GMT (defined in RFC
850 and RFC 1036)
Sun Nov 6 08:49:37 1994 (as defined in ANSI
C's asctime() format)
The first format is the only one that HTTP/1.1 servers are
allowed to generate, and Apache uses it. This format includes a
four-digit date. However to be compatible with older browsers
and servers, Apache recognizes the other formats. The main
problem will be older applications which generate RFC850 format
dates - these only have a two digit date field. RFC850 format
was used in early web servers and browsers, and the replacement
with RFC1132 format in in early 1990's was not fully documented
until HTTP/1.0 was published in 1990. However If Apache sees
this format and the year is before 1970, it assume that the
century is "20" rather than "19".
The final area which affects Apache's ability to handle dates
is the underlying operating system. If the OS has problems
with dates past year 2000, Apache will as well. Most Unix
systems store dates internally as 32 bit integers which
contain the number of seconds since 1st January 1970. This
allows dates up to the year 2038 to be stored. For dates past
2038, the OS will have to be updated to store dates in larger
fields (for example, as a 64 bit value).
There may also be problems before 2038 with OS calls which
accept or return year numbers. For example, many date
functions use a structure called tm which
contains a field tm_year. This field holds the
number of years since 1900, so for example the year 2002 will
be stored as 102. This should not be a problem, provided that
the OS and applications do not assume that the
tm_year value is always a two-digit year between
1900 and 1999. All modern operating systems should be ok.
Other Parts of Your Site
In summary, there is no need to worry about Apache until the
year 2038. If there are some old web applications which send
two-digit years, Apache will correctly assume that low years
are in the 21st century (of course the external application
may not understand year 2000 dates).
While Apache and HTTP should be problem free, there might
still be problems with:
old servers or browsers using RFC850 format dates
proxies or accelerators which use RFC850 dates, or make
incorrect assumptions about two-digit dates
CGI programs (or embedded scripts) which use two-digit
So, to make your site safe for the year 2000: if you are using
a proxy or accelerator, check that it is giving out correct
four-digit dates. Also check all your CGI programs and embedded
scripts. Then sit back and wait for 2038.
You can easily check other servers by making a 'telnet'
connection to the server and requesting a page, and looking
at the returned "Date" field. It should be in RFC1123 format,
as given above. A quick test of a few other servers shows
that some are still issuing RFC850 dates with two-digit
years. An informal sample of requests going through a proxy
recently showed that about 20% of servers were giving out
two-digit years. Some examples of sites and servers giving
two-digit years are:
info.cern.ch - the original home of the web is
using the CERN 3.0 server, which gives out two-digit years
www.homepages.demon.co.uk or any other of the
18,000 personal virtual servers at Demon Internet - served
by thttpd which sends out RFC850 format dates.
PC Magazine reviews ten web servers in
Beyond Unix. As the title implies, they are mainly
looking at servers based on Windows NT and the Unix based
servers mostly got low marks. Apache in particular is
critised in the
Apache Review. While some of the points are valid -
Apache does not provide content management features, remote
browser-based administration or in-built database links -
they make several comments which are not true.
Firstly, they state "you must bring the server down to
reconfigure it". This is not true - most Apache web servers
will run continuously, perhaps being given HUP signals every
so often to rotate log files or re-read the configuration
files (and in Apache 1.2, the new USR1 signal will not cause
transactions in progress to be stopped). Many Unix hosts
remain up for very long periods of time, and compared to NT
many common operations (such as installing new software) do
not require reboots.
Secondly, they state that "there is no help available beyond
the READ.ME files and the comments within the configuration
files and source code". They ignore completely the Apache
manual, which comes with 1.2 and is always available at
Thirdly they claim that "setting up users and groups in
Apache requires a modification of the source code". This is
obviously totally wrong - users and groups can be managed via
the various utility programs (htpasswd or dbmmanage) or via
the Web using a program such as
change_passwd without affecting the server or any
transfers in progress.
Fourth, they once again describe Apache as "public domain".
There seems to be a common misconception that anything that
is free is somehow copyright and owner free. This is not the
case, and they get it right when the product comes from a
commercial organisation (such as Microsoft's Internet
Explorer which is free, but never described as "public
domain"). To set the record straight, Apache is not "public
domain". It is copyrighted and any use of the code must be
allowed by the Apache license which appears in every source
Finally, servers are given higher marks for being able to use
the OS's existing username and passwords in web
authentication. This is actually a security risk - since HTTP
authentication sends passwords in almost clear text over the
network and any interceptor then has access to a real user
account on the server. Apache can be configured to use
real-user passwords, but it is not at all recommended.
They also found performance to be average, but many of the
comments about a similar test by PC Magazine (in the UK)
would probably apply in this case (see Apache
Week issue 55).