In this issue

Release: 1.1.3 (Released 14th January 1997)
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. http://server/dir/#target.
• 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 bug database. Many common configuration questions are answered in the Apache FAQ.

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 are.

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.

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.

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 dates

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 www.apache.org.

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 code file.

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).