Apache HTTP Server 1.3: What's New, Release History & Support Lifecycle

What Did Apache 1.3 Add for DSO and the Module System?

Apache 1.3 introduced full Dynamic Shared Object (DSO) support, allowing modules to be loaded into the server process at runtime rather than compiled in statically at build time. In practice this means you can add or remove capabilities -- say, enabling mod_rewrite or mod_ssl -- without rebuilding the entire httpd binary. Overall memory use decreases because only the modules actually needed are loaded into the process space.

DSO support landed on FreeBSD, OpenBSD, NetBSD, Linux, Solaris, SunOS, Digital UNIX, IRIX, HP/UX, AIX, UnixWare, and generic SVR4 platforms. The configuration directive to enable a module became the familiar pattern most Apache administrators still use today:

LoadModule rewrite_module modules/mod_rewrite.so
AddModule mod_rewrite.c

Alongside DSO came the apxs (APache eXtenSion) tool, which handles off-source building, installation, and activation of DSO-based modules without touching the Apache source tree. This mattered enormously for third-party modules -- vendors could now ship a compiled .so and a one-liner install command rather than asking admins to patch and recompile the server. Most teams running Apache 1.3 eventually built their PHP, mod_perl, or other language modules this way.

The APACI (Apache Autoconf-style Interface) build system also debuted in 1.3, replacing the older src/Configure batch process with a standard top-level configure script and GNU-conforming directory layout. This aligned Apache's build experience with what Unix administrators expected from most other open-source packages of the era.

How Did Apache 1.3 Improve Virtual Host Handling?

Apache 1.3 made name-based virtual hosting a first-class feature by introducing the NameVirtualHost directive and greatly improving the virtual host matching engine. This allowed multiple websites to share a single IP address, which was critical at a time when IPv4 address exhaustion was already a real concern.

A minimal name-based vhost configuration in 1.3 looks like this:

NameVirtualHost 111.22.33.44

<VirtualHost 111.22.33.44>
    ServerName www.example1.com
    DocumentRoot /var/www/example1
</VirtualHost>

<VirtualHost 111.22.33.44>
    ServerName www.example2.com
    DocumentRoot /var/www/example2
</VirtualHost>

The new mod_vhost_alias module went a step further: it enabled dynamically configured mass virtual hosting, mapping hostnames to document roots using interpolation patterns rather than an explicit VirtualHost block per site. This matters if you are hosting hundreds or thousands of domains -- managing individual blocks in httpd.conf simply does not scale. mod_vhost_alias lets a single configuration line handle the entire fleet.

The -S command-line switch was also added so administrators could dump a parsed description of the virtual host configuration to verify matching order and IP/name bindings before reloading. Watch out for Host: header validation, which was hardened across the 1.3 series (particularly around CAN-2000-1206) to prevent security issues in mass name-based hosting setups using mod_rewrite or mod_vhost_alias.

What Security and Authentication Changes Came with Apache 1.3?

Apache 1.3 introduced mod_auth_digest, providing MD5 Digest Authentication as a more secure alternative to HTTP Basic Authentication. This module superseded the older mod_digest, which remains present but deprecated throughout the 1.3 series.

suEXEC support was significantly hardened across the 1.3 lifecycle. The environment is now cleaned immediately after startup rather than at execution time, closing a window where carefully crafted environment variables could influence a setuid helper. Suexec-umask handling was also fixed to always be parsed as an octal value (by prepending "0" in configure), preventing a class of misconfiguration bugs where decimal values were silently accepted and produced wrong permissions.

Several security vulnerabilities were addressed incrementally across point releases. Key fixes include:

• A buffer overflow in mod_alias and mod_rewrite when using regular expressions with more than 9 capture groups (requires attacker-controlled .htaccess or httpd.conf)
• A cross-site scripting (XSS) vulnerability in the default error page when UseCanonicalName was set to Off and wildcard DNS was present (fixed in 1.3.27)
• A permissions flaw in the shared memory scoreboard that could allow a process running under the Apache UID to signal arbitrary processes as root
• An integer overflow in mod_proxy chunk-size handling on platforms where sizeof(int) < sizeof(long) (CVE-2010-0010, fixed in the final 1.3.42 release)
• A one-byte buffer overflow in the Win32 CGI interpreter when the #! line lacked a line-feed character in the first 1023 bytes

In practice, most of these vulnerabilities required either local access, attacker-controlled configuration files, or specific platform conditions. Nevertheless, staying current through 1.3.42 was essential for any production deployment.

How Did mod_rewrite and mod_proxy Evolve Across the 1.3 Series?

mod_rewrite received continuous attention throughout the Apache 1.3 lifecycle. The most operationally significant addition was protection against endless internal redirect loops: a backport from the 2.x series introduced a configurable limit (defaulting to 10) on internal redirects, controlled by RewriteOptions. Without this, a misconfigured RewriteRule could hang a request indefinitely.

RewriteEngine On
RewriteOptions MaxRedirects=10

# Prevent redirect loops when rewriting under a directory
RewriteRule ^/old-path/(.*)$ /new-path/$1 [R=301,L]

Several behavioral fixes accumulated across point releases: RewriteEngine Off was made to work correctly even without Options FollowSymlinks or SymlinksIfOwnerMatch set; URL path handling was corrected on non-Unix platforms; and the rnd map type behavior broken in 1.3.23 was restored in 1.3.24. The URL Rewriting Guide documentation was also added to the bundled manual during this series, which was a significant help for administrators learning the module.

mod_proxy saw the new ProxyIOBufferSize directive, decoupling the proxy read buffer from ProxyReceiveBufferSize. ProxyPassReverse was introduced to rewrite Location headers on HTTP redirect responses -- without it, a proxied backend's redirect would expose the internal server address to the client, which is almost never the intended behavior. mod_proxy caching also received fixes for incorrect Content-Length updates from 304 validation responses and for duplicate headers being added to responses.

What Platform and Portability Changes Did Apache 1.3 Deliver?

Apache 1.3 was the first release to officially support Windows NT and Windows 2000 as production platforms, marking a major expansion beyond Unix-only deployments. All Win32 releases before 1.3.15 should be considered beta quality; stability improved substantially through the later 1.3 point releases. Windows 95, 98, and ME were never recommended for production use.

NetWare 5.x and Cygwin support were also added during the 1.3 series. The NetWare port received specific operational fixes including a -e command-line flag for forcing fatal configuration errors to the logger screen rather than the Apache GUI panel, and file locking support in mod_rewrite for the CLib platform.

Most teams running Apache 1.3 on Windows encountered the AcceptMutex directive, which the Win32 port correctly ignores since Win32 uses a different concurrency model than Unix. A -F flag was added on Unix to keep the supervisor process attached to the tty -- useful for process supervisors and automated restart scripts that need to track the parent process.

Apache 1.3.42 is the final release of the 1.3 branch. The project strongly recommends migration to Apache 2.x for all deployments, as 1.3 is end-of-life with no further patches, bug fixes, or security updates. The Unix-oriented architecture of 1.3 also means that non-Unix ports (Win32, NetWare, OS/2) carry additional caveats not present in the 2.x series.