very nice... do include the last paragraph :) 

On 10/2/07, William A. Rowe, Jr. <> wrote:
Paul Querna wrote:
> Starting in January 2008, only critical security issues will be fixed in
> Apache HTTP Server versions 1.3.x or 2.0.x.

Actually that statement is too narrow;  What if we publish a manifesto such
as this?

"Apache httpd 1.3 to be retired at it's 10th anniversary"

The Apache HTTP Project has served the Internet community and Administrators
since it's first release on ____, derived in large part from the work of the
NCSA server, building upon that software for flexibility in Administration
and solving key HTTP/1.0 protocol issues.  The project is proud of that
tradition, and shares with you, our community, what the near and far futures
hold for you.

On April 5 2002 the Apache HTTP Project released httpd 2.0.35, the first
production/stable release of the flagship http: server.  The entire server
was refactored into a more pluggable and flexible architecture which offered
a much less fragile configuration schema.  It incorporated SSL/TLS request
handling at last, owing to a relaxation of export restrictions from the US.
And it opened up new opportunities for content filtering and transformation
in a cooperative, stackable mechanism between multiple modules.

On January 2 2003 the project released httpd 2.0.44, the first version to
enjoy new versioning policies which ensure that third party add in modules
are binary-compatible from version to version within 2.0 (and these same
policies apply to all releases made in the future under even-numbered stable
production releases, such as 2.2, 2.4 or 3.0).  To help our third party
development community, odd-numbered development branches were introduced
where they could explore the next-big-features, without worrying that the
day to day development effort would break their module to millions of users
who adopt the next subversioned release.

On December 1 2005 the project released httpd 2.2.0, with significant changes
to the authentication and authorization stack, adding flexibility for module
authors and consistency for server administrators.  Release 2.2 also heralded
significant work to provide the newest generation, stable, production ready
HTTP/1.1 proxy and multiple production ready caching back-ends.

Since May 1 2006, there have been no new features introduced into the legacy,
tried and true httpd 1.3, and the Apache HTTP Project has intended that no
new features would be introduced into that branch.  Security-related updates
have been published for httpd 1.3, most recently September 7 2007.

The Apache HTTP Project understands it's special relationship to the third
party module communities; including open source efforts, commercial vendors
and packagers of all sorts.  January 2008 represents a five year cusp in this
relationship, as every module or package distributor could anticipate a stable
and rich API for development and deployment.

Just beyond the cusp of this 5 year milestone, and on it's 10th birthday,
the Apache HTTP Project will entirely retire the legacy Apache 1.3.x server.
There will be no  subsequent releases of Apache 1.3, including security-fix
releases, after June 1, 2008.  To reiterate, there are flaws today addressed
by Apache 2 today that cannot be addressed in the framework or context of
Apache 1.3 across every supported platform.

There are some who may suggest that the development of httpd 2.0 represented
a departure from regular, stable releases of httpd server.  This is easily
disproven on two levels; first off, httpd 2.0 was not released for general
availability until its 35th iteration, providing our third party development
communities the chance to comment and correct interfaces that would benefit
their efforts.  Secondly, a cursory review of the pace of httpd 1.3 releases
between 1.3.0 and 1.3.12 demonstrate an early development pattern of frequent
releases, with frequent API changes.  Implications that Apache 2.0 is more
difficult to track with third party add in modules are patently false.

In closing, httpd 1.3 represented the culmination of years of effort to most
efficiently and effectively serve static content that the growing Internet
required, and will have served that role for over 10 years as of June 1, 2008.
The Apache HTTP Project is keenly aware that the nature of the dynamic web
applications of the 21st century are no longer best served by this model, but
with a wider vision of users choosing exactly the features they need, from
a rich set of content filtering of multiple database and external back-end
content providers to simple, static local file content.

The immediate future heralds new progress at asynchronous request handling,
servicing more requests with fewer workers, further improvements to the
administrator's configuration of authentication and authorization contexts,
and richer database services.  The long term roadmap for Apache 3.0 a.k.a.
Amsterdam is under development.  It already looks forward at a protocol
stack beyond today's HTTP/1.1 protocol, which claims as its fruit the
Internet today as perceived by hundreds of millions of users.  Such changes
can only be made in the context of the further protocol-agnostic framework
that is planned for Apache 3.0.

Summer of 2008 will bear out a new effigy at the burning man festival, where
the HTTP Project will prepare a code-man constructed entirely of piles of
printouts of the httpd 1.3 source code sitting on the desks of many of the
project contributors, including Brian Behlendorf, festival and httpd project
founder.  RFC2616 co-author and current Apache HTTP Project Chairman Roy
Fielding  will put the torch to the pyre symbolic of errors derived from
misplaced commas and unstated assumptions of HTTP/1.1.

[ok, maybe we can skip the last paragraph :-]

> I honestly believe we will be somewhat responsible for fixing any major
> security issues in 1.3 and 2.0 for the next 5-10 years, unless Waka
> suddenly explodes and replaces http :-)