Chapter 1. Applications Development with Apache
1.1. A Brief History of the Apache Web Server
1.1.1. Apache 1
The Apache Web Server was originally created in 1995. It was based on and derived from the earlier NCSA server, written by the National Center for Supercomputing Applications (which also developed the Mosaic browser, predecessor to most of today’s browsers, with a direct line to Netscape and Mozilla, and considerable influence over others, including MSIE). The first production server under the Apache name was version 1.0.0, released in December 1995.
As a webserver, Apache was an immediate success. By April 1996, it had overtaken the NCSA server as the most widely used webserver on the Internet, a position it has occupied ever since. But it wasn’t a general-purpose applications platform: The native API was fairly limiting, and the return on development effort for programmers was unattractive compared to some of the alternatives available as higher-level programming layers. Nevertheless, some useful application modules—most notably, the extraordinary mod_rewrite—were developed.
The first applications development framework to make a major splash was Perl, under both CGI and mod_perl. The main programming book and most application developers concentrated on Perl, because mod_perl presented the first really useful and easy-to-use API. The Java Servlet API and numerous other scripting languages, including the current market leader PHP, soon followed.
The last major new release of the original Apache server was version 1.3, which was introduced in June 1998. Apache 1.3 has continued in maintenance mode and remains popular today, although new development work has long since moved to Apache 2.
1.1.2. Apache 2
Recognizing the limitations of Apache’s original, hackish architecture, the Apache developers began a major new codebase in 2000, leading to the first production release of Apache 2.0 in April 2002. Salient features of Apache 2 include the following:
- The native API is much improved and the APR library is a separate entity. This helps programmers overcome most of the drawbacks of C programming—in particular, the problems of cross-platform programming and resource management. Working with Apache 2, C programmers can expect levels of productivity more commonly associated with higher-level and scripting languages.
- A new extension architecture enables development of a whole new class of applications, as well as far cleaner implementations of existing modules and applications. This book will discuss in detail how to take advantage of this extension architecture.
- A new core architecture makes Apache 2 a truly cross-platform server. The operating system layer has itself become a module (the MPM), enabling it to be separately tuned for each operating system. Whereas Apache 1 was a UNIX application that was ported with many limitations to other platforms, Apache 2 is truly cross-platform and is not tied to UNIX features, some of which perform poorly on, for example, Windows or Netware. The introduction of threaded MPMs also improves scalability on UNIX in many applications.
The downside of Apache 2 is that the API is not backward compatible with Apache 1, so many third-party modules and applications have been slow to upgrade to version 2.
Apache 2.2 was released as a stable version in December 2005 and features further major enhancements. It preserves (and extends) the Apache 2.0 API, so that modules and applications written for Apache 2.0 will work with Apache 2.2. Notable improvements in version 2.2 include scalability and applications architecture. Where Apache 2.0 offered the foundations of a powerful applications platform, Apache 2.2 has added walls and a roof.
1.2. The Apache Software Foundation
The Apache Software Foundation (ASF) provides organizational, legal, and financial support for a broad range of open-source software projects. The ASF provides an established framework for intellectual property and financial contributions that simultaneously limits contributors’ potential legal exposure. Through a collaborative and meritocratic development process, Apache projects deliver enterprise-grade, freely available software products that attract large communities of users. The pragmatic Apache License makes it easy for all users—whether commercial enterprises or individuals—to deploy Apache products.
Formerly known as the Apache Group, the ASF has been incorporated as a membership-based, not-for-profit corporation to ensure that the Apache projects continue to exist beyond the participation of individual volunteers. Individuals who have demonstrated a commitment to collaborative open-source software development, through sustained participation and contributions within the ASF’s projects, are eligible for membership in the ASF. An individual is awarded membership after nomination and approval by a majority of the existing ASF members. Thus the ASF is governed by the community it most directly serves—the people collaborating within its projects.
The ASF members periodically elect a Board of Directors to manage the Foundation’s organizational affairs, as accorded by the ASF bylaws. The Board, in turn, appoints officers who oversee the day-to-day operations of the ASF. A number of public records of the ASF’s operations are made available to the community.
1.2.1. Meritocracy
Unlike many other software development efforts conducted under an open-source license, the Apache Web Server was not initiated by a single developer (for example, like the Linux Kernel or the Perl/Python languages), but rather started as a diverse group of people who shared common interests and got to know one another by exchanging information, fixes, and suggestions.
As the group started to develop its own version of the software, moving away from the NCSA version, more people were attracted to the effort. They started to help out, first by sending little patches, or suggestions, or replying to e-mail on the mail list, and later by making more important contributions.
When the group felt that a person had “earned” the right to be part of the development community, its members granted the individual direct access to the code repository. This approach both expanded the group and increased its ability to develop the Apache program and maintain it more effectively.
We call this basic principle meritocracy—literally, “government of merit.” The meritocracy process scaled very well without creating friction. Unlike in other situations where power is a scarce and conservative resource, in the Apache group newcomers were seen as volunteers who wanted to help, rather than as people who wanted to steal a position.
At the same time, because there is no pressure to recruit more members, Apache is not scrabbling for scarce talent in a competitive environment. Instead, it can afford to restrict itself to people with a proven track record of contributions and a positive attitude. And because it is a virtual community, it is worldwide and not constrained by geography.
1.2.2. Roles
The meritocracy supports a variety of roles.
User
A user is someone who uses the software. Users contribute to the Apache projects by providing feedback to developers in the form of bug reports and feature suggestions. Users may also participate in the Apache community by helping other users on mailing lists and user support forums.
Developer
A developer is a user who contributes to a project by submitting code or documentation. Developers take extra steps to participate in a project, are active on the developer mailing list, participate in discussions, and provide patches, documentation, suggestions, and criticism. Developers are also known as contributors.
Committer
A committer is a developer who was given write access to the code repository and has a signed Contributor License Agreement (CLA) on file. All committers have an apache.org mail address. Not needing to depend on other people for the patches, these individuals actually make short-term decisions for the project, subject to oversight from the Project Management Committee (PMC).
PMC Member
A PMC member is a developer or a committer who was elected to the PMC on a merit basis, in recognition of his or her role in the evolution of the project and demonstration of commitment. PMC members have write access to the code repository, an apache.org mail address, the right to vote on community-related decisions, and the right to propose an active user for committer status. The PMC as a whole is the entity that controls the project.
ASF Member
An ASF member is a person who was nominated by current ASF members and elected due to merit based on his or her role in the evolution and progress of the ASF. Members care for the ASF itself. This concern is usually demonstrated through the roots of project-related and cross-project activities. Legally, a member is a “shareholder” of the Foundation, one of the owners. ASF members have the right to elect the Board of Directors, to stand as a candidate for the Board election, to propose a committer for membership, and to participate in a wide range of other roles within the ASF.
1.2.3. Philosophy
While there is not an official list, certain principles have been cited as the core beliefs of philosophy behind the ASF. These principles are sometimes referred to as “The Apache Way”:
- Collaborative software development
- Commercial-friendly standard license
- Consistently high-quality software
- Respectful, honest, technical-based interaction
- Faithful implementation of standards
- Security as a mandatory feature
1.3. The Apache Development Process
Apache development is both a top-down and a bottom-up process. From the top come Big Ideas: major new features or capabilities that involve significant reworking or new components, and may take many months or even years to pass from inception to maturity. From the bottom come small patches, to deal with bugs or add features that are simple to support within the current software.
Somewhere between these extremes is the typical module: a self-contained plug-in implementing new features of interest to its author and often others. A module may implement core webserver functionality, a general-purpose service, a small but vital function, or a single-purpose application. A module that is of sufficiently general interest may, if offered, be incorporated into the core Apache distribution. However, that inclusion will not happen if the module adds external dependencies such as third-party libraries, or if any concerns arise regarding the module’s licensing or intellectual property issues. Such modules may be distributed independently by their developers or by third parties, such as a company supporting Apache or the packagers of a Linux distribution.
1.3.1. The Apache Codebase
Like any other software project, Apache maintains a codebase. This codebase is divided into projects; those relevant to the webserver are httpd (which includes code, documentation, and build files) and apr.
1.3.1.1. Subversion
All Apache code is kept in a repository at http://svn.apache.org/. The code is managed by Subversion (SVN),[1] a modern revision-control system suitable for large-scale multi-developer projects. This is a relatively recent (2004) change from an older but broadly similar system, CVS.
Read access to the entire repository is public, but write access is limited to committers. Read access includes the ability to view any point in the development history of Apache, including reviewing any single or cumulative change, brief explanations of reasons for changes (e.g., bugs fixed, new capabilities, internal improvements), the date of the change, and the person responsible for making the change.
1.3.1.2. Branches: Trunk, Development, and Stable
The code repository contains a trunk and several different branches. The default version of any file is the trunk of the repository. In Apache, this version represents work in progress. It is, by definition, untested, and it generally includes experimental code in at least some areas.
The current stable branch is Apache httpd 2.2, which is found in /branches/2.2.x/. Also maintained (albeit minimally) are the older 2.0 and 1.3 branches, although neither is the subject of much developer effort.
New branches may also be created on an ad hoc basis for experimental code. For example, a substantial reworking of parts of the core code took place while Apache 2.2 was in beta testing, to support asynchronous I/O. This code was initially too experimental to develop in the trunk, so the developers involved in this work created a new development branch. The new codebase has subsequently stabilized and been merged into the trunk, and should eventually be included in the next stable release (version 2.4).
1.3.1.3. Review and Consensus
The Apache developers operate under different development policies for stable and development code:
- Stable code is always Review-Then-Commit (RTC). That means any code going into a branch marked as stable—even the most trivial patch—must have been through a proper review process.
- Development code is Commit-Then-Review (CTR). That means code can be added, changed, or removed by a committer acting unilaterally, and reviewed in place by other developers (of course, SVN makes it easy to reverse a change where necessary). Nevertheless, major changes should be reviewed before committing, or worked on in a separate development branch.
1.3.1.4. Backports
New code is first added to the trunk. If a developer wants this code to become part of a stable branch (typically a minor enhancement or bug fix), it is proposed for backporting. The mechanism for this is a file called STATUS, which contains a list of current issues including votes for backport.
To qualify for backporting, any change must collect at least three positive votes from committers. A positive vote means that the voter has reviewed the change and is satisfied with it, so three such votes is a fairly good indicator that the change is sound. Even simple bug fixes are subject to this rule, which means that noncritical bugs can sometimes take a frustratingly long time to fix while awaiting attention from enough committers. Having collected three positive votes and no veto, a change may be added to a stable branch.
A committer who reviews a change and is not happy with it may note his or her reservations about it, or even veto the change. The rules require that a veto must be accompanied by an explanation and/or an alternative proposal for accomplishing the objectives of the change. A vetoed change may be either dropped or revised to deal with the objections and submitted for a new vote. A veto or a non-veto reservation will typically be resolved by discussion of the relevant issues in the developer forums.
1.3.1.5. Releases
From time to time, a new release of Apache is made available. Releases of the current stable codebase (versions 2.2.x at the time of this book’s writing) give users the advantages of the most recent improvements and bug fixes. Such releases will be marked as the best available version and recommended to users. A release is usually prompted by developers thinking that enough minor changes have accumulated to warrant a new version, but may also be hurried if a security problem comes to the developers’ attention. A developer will volunteer to be release manager to deal with the administrative issues and create the release, while others will concentrate on applying any approved and pending updates in the STATUS file for the stable codebase.
Current policy is that even-numbered branches are stable, while odd-numbered branches are intended for development. (This policy represents a change from earlier versions: Apache 1.3 is stable, but early 2.0 releases were not.) Thus 2.0.x (since April 2002) and 2.2.x releases are stable, while 2.1.x releases were intended for alpha testing and later beta testing for Apache 2.2. Version 2.1 was approximately 10 months in alpha testing and 3 months in beta testing before its final release as stable version 2.2.
A released version should build, install, and run cleanly on any supported platform. For stable releases, meeting these criteria is a must; for development releases, it is also the intention, though it is less critical. To ensure that the release satisfies these conditions, the release manager first creates a build for the release from the appropriate SVN branch, and then announces it to the Apache developers and testers. This allows enough time for many developers and testers to install and run the build version on a wide range of different hardware, operating systems, and applications before it is announced to the general public. If a serious problem arises in this testing, the build is not released.
All releases are PGP-signed by the release manager responsible. Public keys for many Apache developers, including all release managers, are available at http://www.apache.org/dist/httpd/KEYS.
1.3.2. Development Forums
The primary development forum for the Apache Web Server is the mailing list [email protected]. All technical matters of Apache development are discussed there. A similar development list, [email protected], serves APR development. These forums are 100% open and public, and all discussions are archived in several places (referenced at the end of this chapter).
Another popular development forum is Internet Relay Chat (IRC). The Apache developer channels are #httpd-dev and #apr on irc.freenode.net. These venues are also fully public and open.
The Apache Bugzilla at http://issues.apache.org/ is a searchable database of bug reports, enhancement requests, and patches, both current and historical. This database is also fully open and public. Note that because it is fully open, it contains a significant proportion of bogus reports (some of which cannot be closed and are shown as “reopened”) and nebulous reports that cannot be verified. It also contains a number of reports marked PatchAvailable that are deliberately left open, where it is felt that a patch might be useful for some users but is not appropriate for inclusion in the standard Apache distribution.
The full and accurate archive of all code additions and changes is the Subversion repository at http://svn.apache.org/. This repository is updated in real time as code is changed. Read access is fully open and public, but write access is limited to authorized committers. Noteworthy files in Subversion include STATUS, which contains current discussions and votes, and CHANGES, which provides the executive summary of changes to a stable/release branch.
1.3.3. Developers
It is important to Apache that the diversity of its users be reflected in its development community. There is no question of an Apache project becoming dominated by any one company or group of companies. Some developers (including this author) work either as freelance consultants or for very small companies. Other developers come from the larger vendors such as IBM, Red Hat, and Novell; from the big users such as Google, Yahoo!, and Ask Jeeves; and from universities and other noncommercial organizations. Whereas the majority of developers are employed by companies, the independents outnumber any single corporate contingent.
Perhaps more importantly, the developers reflect the wide range of roles that Apache fulfills. Those who are running it on ultra-busy sites such as CNN or HEAnet need to sustain loads of tens of thousands of concurrent users on a 24/7 basis, so they care about performance, scalability, and stability. Application sites, such as this author’s Site Valet, are concerned with extending Apache beyond its original webserver role and using it as an application server. E-commerce sites are concerned with both security and reliability issues. Hosting companies need to support widely differing users and delegate control while maintaining security and stability. Having active developers from such a wide range of backgrounds ensures that Apache works well in all of these environments.
Finally, we are by no means an exclusive “hacker” community. Although software development and maintenance is the biggest single activity carried out by Apache developers, some members have risen to the top of the Apache hierarchy without writing a single line of C code! Support, documentation, and organizational roles are as highly valued as programming.
1.3.4. Participation
Participation in any of the Apache forums is open to anyone with a contribution to make. There are many ways to contribute, and all are highly valued:
- Coding. Patches for issues brought up in Bugzilla are very welcome. Contributions to current subjects of debate found on the developer lists, or highlighted in
STATUS, are always welcome. The programmer looking for something to do is also invited to search the codebase in SVN forTODOorFIXMEnotes. Patches are most welcome when they can be applied cleanly (diff -uorsvn-diffformat) and are clearly motivated and explained. Patches can be posted to the developer list or to Bugzilla. - Documentation. The documentation is held in SVN. All original documents are in an XML format that is a subset of DocBook. New documentation or improvements (patches) to existing documentation are always welcome.
- Translation. The documentation is provided in a number of languages, but not all pages are available in all languages. Neither are the translations always up to date with the originals. If you have the language skills, look for missing or outdated pages in your language, and fix them!
- Testing. Build and test code on your platform, particularly if you use an unusual platform. Build it with unusual environments and toolkits: Does it build and install cleanly? Stress-test it in all your most unusual tasks. If it fails, or if you find unexpected changes from an earlier version, try and diagnose what’s going on. Report any bugs you find to the developer mailing list or Bugzilla. Try to ensure that whatever you describe is clear and reproducible behavior.
- Build. Maintaining the Apache build and installation setup is an important task, but one for which (at the time of this book’s writing) we are not well equipped. Even the most widely used GNU autoconf-based installation for UNIX/Linux family platforms would benefit from an overhaul.
1.4. Apache and Intellectual Property
All Apache projects are copyrighted by the ASF and licensed under the Apache License. At the same time, the ASF and PMC take strong measures to ensure that no third-party intellectual property is used in Apache code without legally binding, written permission to distribute it under the Apache License. Note that while Apache holds the copyright for the entirety of a project, parts of a project may remain copyrighted by individual contributors and be licensed under ASF terms.
1.4.1. The Apache License
The Apache License (found in Appendix A) is a free software license, in the tradition of the older BSD and MIT software licenses, but with an important additional clause appropriate to our times. It satisfies all accepted definitions of free and open-source software.
Given that the language of free software may be confusing to some readers, let’s pause to clarify some important points. Please note that this is just basic background information, and is certainly not legal advice for users in any particular country.
Free Speech, Not Free Beer
Free beer is nice. Free speech is important!
When we talk of software freedom, we are using the word in the sense of free speech. The key freedom in software is the freedom for every user to do whatever it takes to meet his or her own needs (or, of course, to hire someone to do that). Making the source code available is a necessary part of freedom.
Cost is not relevant to software freedom. Apache is available at a wide range of costs, from a no-cost download, to a package bundled in, for example, a commercial Linux distribution, to a fully paid product backed by a commercial support organization.
Not Public Domain
Like most other free software, Apache is not in the public domain. It is copyrighted by the ASF and subject to a license. The difference between this status and “traditional” commercial software licenses is that the Apache License is a great deal more friendly and less restrictive.
Not Shareware, Nagware, or Adware
Shareware and its modern variants are concepts alien to free software. They are commonly (though not always) associated with low-quality, amateur products, and today they are more likely to be driven by marketing than by engineering.
Not GPL
The oldest and best-known (but also much-misrepresented) free software license is the GNU General Public License (GPL), written and owned by the Free Software Foundation (FSF). The GPL introduced a concept known as copyleft. The basic principle can be summarized as follows: “We are granting you these freedoms, and you can’t take them away from anyone else.” This policy is sometimes seen as business unfriendly, because copyleft software cannot be incorporated willy-nilly into nonfree products.[2] The Apache License is explicitly business friendly; it is not copyleft.
In fact, the Apache License is not even compatible with the GPL.[3] That is, each license includes provisions that are incompatible with the other license: GPL software cannot be distributed on ASF terms because copyleft is a restriction incompatible with ASF policy. ASF-licensed software cannot be distributed on GPL terms. Here’s what the FSF has to say on the subject:
This is a free software license but it is incompatible with the GPL. The Apache Software License is incompatible with the GPL because it has a specific requirement that is not in the GPL: it has certain patent termination cases that the GPL does not require. (We don’t think those patent termination cases are inherently a bad idea, but nonetheless they are incompatible with the GNU GPL.[4])
Note that none of these issues is a problem for end users or for third parties such as module developers or distributors. Linux (GPL) vendors routinely include Apache in their products, and many Apache modules are GPL licensed. It’s no problem for the Linux distributors to comply with both licenses, or for the module developers to apply their own choice of license to their work. Even the famously purist and legally meticulous Debian distribution[5] distributes GPL modules with Apache.
Where the incompatibility in licenses may pose a problem is in the interface with GPL software. Consider its implications for MySQL,[6] an SQL database package licensed under the GPL. To comply with the GPL requirements of MySQL, the Apache/APR driver[7] for MySQL is also GPL licensed and, therefore, cannot be distributed within Apache by the ASF. Instead, it is available as a separate download from the author’s site or as a separate package from a third party. This is relevant to users who compile Apache themselves, but those users who install Apache from packages need never concern themselves with the details.
Patents and the Anti-Piracy Clause
The greatest danger to technology developers today comes from patents. This is particularly true in the United States, where the patent system was seen for many years as an instrument of economic imperialism: Let’s grant thousands of patents to “our” companies, then enforce those patents worldwide through the World Trade Organization (WTO) treaties to gain a global competitive advantage. Consequently, the U.S. Patent Office has issued huge numbers of patents while making no attempt at effective scrutiny or quality control. Many of these patents are in the hands of people who have no interest in technology, but rather seek to extort money from legitimate businesses.
This is, in a very real sense, today’s piracy. In the past, rulers of a country, province, or city would assert a claim over “their” seas, charge a substantial levy on foreign shipping to pass through their territory, and license privateers to enforce their property rights and seize any unlicensed ship passing through. Similarly, today’s patent holders seek to charge levies to legitimate business, and use lawyers to enforce their property. In fact, the situation today is arguably worse than in the olden days, in that there are hugely more patents than there ever were nautical pirates, and there are no longer any safe shipping lanes.
One unusual restriction in the Apache License deals with this issue as far as possible. Acceptance of the Apache License requires the licensee not to assert any patent rights it may claim against the ASF or Apache users.
To the best of my knowledge, Apache has remained clear of intellectual property lawsuits. This contrasts with the situation faced by Linux in the SCO lawsuits (although it appears likely that Linux will be vindicated[8]), and more strongly with the situation involving Microsoft, whose end users have paid substantial damages to third parties over patent infringements in Microsoft software.[9],[10]
1.4.2. Third-Party Intellectual Property
Apache’s intellectual property is protected by copyright and the license. Of course, it is also critically important that Apache doesn’t violate anyone else’s intellectual property. That means that all significant contributions to Apache must be properly donated:
- Before a developer can become a committer, he or she must sign a Contributor License Agreement (CLA) that gives the ASF all necessary rights to use that developer’s contributions and to license them to third parties on ASF terms. The CLA also binds a contributor to ensure that contributions which are not their own original work are signed over to the ASF before including them in Apache. The full CLA appears in Appendix B.
- When a developer is not his or her own master (e.g., an employee whose employer may have rights over his or her work), a Corporate CLA signed by an authorized officer of the employer (e.g., CTO or IT Director) is also required. The full CCLA also appears in Appendix B.
- All relevant CLAs and CCLAs must be on file with the ASF before an individual can be granted commit access. These agreements serve to ensure that committers and their employers cannot prevent the ASF or Apache users making use of their contributed work.
Responsibility
In the first instance, it is the responsibility of each committer to ensure that his or her contributions don’t violate third-party intellectual property.
The overall responsibility lies with the PMC, which will query any contribution that raises doubts—in particular, major new contributions.
Audit
If despite all due care, problems with third-party intellectual property should arise, Apache has a full audit trail managed by Subversion. Thus, in the worst case, any problematic code can be identified and removed.
1.5. Further Reading
1.5.1. Interactive Online Forums
Public Mailing Lists
The Apache Module Developers list [email protected] is an appropriate place for discussion of any module development issues. This list moved from [email protected] in September 2006, so check the archives of both lists.
The official developers list for the Apache Web Server is [email protected]. You are welcome to participate, but please stay on topic.
The official developers list for the Apache Portable Runtime is [email protected]. You are welcome to participate, but please stay on topic.
The Apache users list [email protected] is an appropriate forum for general discussion and user support questions.
Usenet
The comp.infosystems.www.servers.[unix|windows|mac|misc] newsgroups are appropriate for general discussion and questions about Apache on the respective platforms.
Online Chat
There are several channels relevant to Apache on irc://irc.freenode.net:
#apache— general support/unofficial helpdesk channel. Ask meaningful questions and wait for an answer. But do your homework first. In particular, look in the error log! Pay attention to fajita, the #apache ‘bot; many of the regulars work by prompting her to answer your questions and/or post URLs to the relevant documentation pages.
#apache-modules— the channel for module development. It is likely to be appropriate for readers of this book.
#apr— the semi-official APR channel, including automated live notification of all changes to the APR repository.
#httpd-dev— the semi-official channel for webserver development, including automated live notification of all changes to the repository, including documentation and the website.
#asfinfra— the Apache infrastructure channel.
1.5.2. Conferences
The ASF organizes ApacheCon conferences devoted to ASF projects. These conferences bring together many of the developers (who know each other well from the online forums but may never otherwise meet face-to-face). Users may come just to learn, but some also bring new insights to the developers. A busy program of tutorials and talks by both developers and users is complemented by both organized and informal social events.
1.5.3. Websites
Official and Semi-official Apache Sites
http://www.apache.org/— Apache Software Foundation
http://httpd.apache.org/— Apache Web Server
http://apr.apache.org/— APR home site
http://svn.apache.org/— Apache code repository and complete history
http://issues.apache.org/— Bugs and issues database
http://modules.apache.org/— Apache modules register
http://asylum.zones.apache.org/modules/— Updated modules register (work in progress)
http://mail-archives.apache.org/— Mailing list archives
http://people.apache.org/— Pages of individual Apache committers
http://apachecon.com/— ApacheCon conference
http://perl.apache.org/— mod_perl (Apache API in Perl)
http://www.modpython.org/— mod_python (Apache API in Python)
http://tcl.apache.org/— TCL language in Apache
http://httpd.apache.org/cli/— mod_aspdotnet (Microsoft’s asp dot net)
Third-Party Extensions
http://apache.webthing.com/— More than 20 modules by the author of this book
http://www.outoforder.cc/— 12 featured modules and other relevant work
http://www.php.net/— PHP language
http://www.rubyonrails.org/— Ruby on Rails
Developer Documentation
http://docx.webperf.org/— API reference
http://www.apachetutor.org/dev/— Developer tutorial site created and maintained by the author of this book
http://dev.ariel-networks.com/apr/apr-tutorial/html/apr-tutorial.html— A useful tutorial for APR, decoupling it from its role in the webserver
http://www.apache-modules.com/— Companion site to an Apache modules book that was never completed
Other Tutorials, News, and Articles
http://www.onlamp.com/pub/q/all_apache_articles— A wide range of articles
http://www.apachelounge.com/— News site together with Windows binary downloads (often available before the “official” ones)
http://marc.theaimsgroup.com/— Mailing list archives
1.6. Summary
This chapter examined the social, historical, and legal background of Apache and its culture. Specifically, Chapter 1 considered the following topics:
- The historical context of Apache
httpd - The Apache Software Foundation and its culture
- The Apache developers, processes, and resources for development and support, including how to participate
- Apache’s approach to intellectual property, including the Apache License and the safeguards against misuse of third-party intellectual property
Chapter 1 was decidedly nontechnical. In contrast, the remainder of the book is all about programming with Apache, starting with a comprehensive overview, and moving to hands-on treatment of module and application development.