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
