Apache 1.3.23 was released on 24th January 2002 and is
now the latest version of the Apache server. The previous
release was 1.3.22, released on the 12th October 2001.
See
what was new in Apache 1.3.22.

This is a bug fix and minor upgrade release,
with a few new
features. Users should upgrade if they will be affected
by the
particular bugs mentioned below, or would like to use any of
the new features.

New features

The main new features in 1.3.23 (compared to 1.3.22) are:

HTTP/1.1 support has been added to mod_proxy after
being backported from the Apache 2.0 updates
started
last April. The updates include support for
Cache-Control, content negotiation using Vary,
persistent connection handling, and much more.

Prevent an Apache module from being loaded or added twice due
to duplicate LoadModule or
AddModule directives

Add run-time validation of the Group directive,
to catch invalid but syntactically correct values.

The following bugs relate to specific platforms:

Versions of FreeBSD from August 2000 include a feature
called "accept filters" which delay the return from
accept() until a condition has been met. Apache will now use the
"httpready" accept filter rather than "dataready" on
FreeBSD after 4.1.1-RELEASE where it works correctly.
More details of
accept filters are available.

Some fixes for Netware including link problems with
mod_vhost_alias, file locking updates
to get mod_auth_dbm to work, and a problem when
accessing an empty directory which
has option indexes specified producing an access
forbidden message

On HPUX 11, an ENOBUFS, No buffer space available
error occurs when an accept() cannot complete. This error is now
ignored so that child processes don't get incorrectly terminated

Unixware 7.0 and later did not have a default locking
mechanism defined. This bug was introduced in apache 1.3.4

A number of fixes for Cygwin including a better default
mutex as well as better proxy and DBM support

A bug on Win32 could cause Apache to stop responding to
requests for a period of time if the MaxRequestsPerChild
directive was set to anything other than 0.
MaxRequestsPerChild of 0 is the recommended setting

Win32 will now output an error message if the server hits the
ThreadsPerChild limit. This is useful for
administrators to detect when their server is running out of threads to
handle requests