httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jorge Schrauwen" <>
Subject Re: How to kill 1.3?
Date Tue, 02 Oct 2007 21:07:23 GMT
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.xserver.
> 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.0represented
> 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.3releases
> 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 :-)
> ?
> Bill


View raw message