From dev-return-58858-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org Tue Oct 02 21:08:05 2007 Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 19513 invoked from network); 2 Oct 2007 21:08:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Oct 2007 21:08:03 -0000 Received: (qmail 46103 invoked by uid 500); 2 Oct 2007 21:07:45 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 46030 invoked by uid 500); 2 Oct 2007 21:07:45 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 46019 invoked by uid 99); 2 Oct 2007 21:07:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Oct 2007 14:07:45 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jorge.schrauwen@gmail.com designates 64.233.182.188 as permitted sender) Received: from [64.233.182.188] (HELO nf-out-0910.google.com) (64.233.182.188) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Oct 2007 21:07:46 +0000 Received: by nf-out-0910.google.com with SMTP id c10so2729206nfd for ; Tue, 02 Oct 2007 14:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=BQf/oefn+0hWnVXz4PPNBoEVNbuz4q0Yf5b4azYjiXc=; b=GqTobgHYKEYWwudWPCSTRaiB1Irh0WNT90hi8B19XBj/t9TWFp6cOa6ZvQ5jnNkbF4nWc2YbYWLxrosjWeZY4GK1ean4/xHS5OXwWtmk4sPGh2EAO0HRSavdjdJ/lR1LswaaIRZ+Bd4EpUmuupfjYxl9GPCclAOdVin0XZzGVsg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=iGiOEjB0BsmMr3SlZli62HRffCMO34GAEB3bhNFDov0/MtNqoa51nwHV2RuAV0jzWAby6PU6Kwe1HEE6e7yGjrIsz4gkQoKAteEqdLIMrdg5/Pv57j2cFl9hV+03IcxlH/M91Cc8JdvmsOswswc+R8jFJUNx0DKFDP/HiRiOmfM= Received: by 10.78.185.15 with SMTP id i15mr323511huf.1191359244195; Tue, 02 Oct 2007 14:07:24 -0700 (PDT) Received: by 10.78.195.12 with HTTP; Tue, 2 Oct 2007 14:07:23 -0700 (PDT) Message-ID: <43e40e000710021407x7a2b5d8brbfe06ec628aff545@mail.gmail.com> Date: Tue, 2 Oct 2007 23:07:23 +0200 From: "Jorge Schrauwen" To: dev@httpd.apache.org Subject: Re: How to kill 1.3? In-Reply-To: <4702AAD0.30500@rowe-clan.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18504_29545432.1191359244191" References: <47017837.2020208@rowe-clan.net> <47017A2B.7040904@rowe-clan.net> <9F4A92E7-2734-4B40-A23E-9F05F00E8A9A@jaguNET.com> <7B632143-57F5-4DC3-91F8-76EA226FF5A8@jaguNET.com> <47029364.5010402@force-elite.com> <4702AAD0.30500@rowe-clan.net> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_18504_29545432.1191359244191 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 :-) > > svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/ > > ? > > Bill > -- ~Jorge ------=_Part_18504_29545432.1191359244191 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline very nice... do include the last paragraph :) 

On 10/2/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> 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 :-)

svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/

?

Bill



--
~Jorge ------=_Part_18504_29545432.1191359244191--