Apache模块开发指南.doc

1.1 Apache Web服务器简史1.1.1 Apache 1Apache Web服务器诞生于1995年。它起源于早期的由NCSA编写的NCSA服务器，并在其基础上进行构建。第一个以Apache命名的服务器产品发布于1999年12月，版本为1.0.0。作为Web服务器，Apache随即取得成功。到1996年4月，Apache已经取代NCSA服务器，成为Internet上使用最广泛的Web服务器，至今依然如此。Apache并不是通常意义上的应用平台：原生API非常有限，同其他产品具有的高级别编程层次相比，Apache需要开发人员付出更多的努力来达到同样的效果。然而，在一些非常有用的功能模块中最值得一提的是已经开发出来的十分优秀的mod_rewrite模块。Apache引起第一次比较大的反响的应用开发框架是Perl语言，由CGI和mod_perl支持。由于mod_perl第一次采用了真正有用而且容易使用的API，大量的编程书籍和开发人员都集中在Perl上。很快，Java Servlet及大量的脚本语言，包括如今的市场领头羊PHP等，都发布了各自的API。Apache 1服务器的最后一个主要版本为1.3，发布于1998年6月。尽管新的开发工作移植到Apache 2已经很长时间，但Apache 1.3 仍然处于维护模式，至今依然流行。1.1.2 Apache 2Apache的开发人员认识到Apache 最初的架构具有局限性，比较粗糙，于是在2000年开始建立新的代码仓库（codebase）主分支，并在此代码仓库的基础上于2002年4月创建了Apache2.0的第一个发布版本。Apache 2包括以下优良特性：原生API得到很大幅度改进，使APR库成为单独的实体。这在很大程度上帮助开发人员克服了C语言编程的缺陷，特别是交叉编译平台和资源管理方面的缺陷。通过使用Apache 2，C程序员可以达到通常被认为是高层次语言和脚本语言才能达到的高效率。新的拓展架构带来了全新层次的应用程序开发，同时也为以前的模块和应用程序提供了更为简洁的实现方法。本书将会详细介绍如何利用这个新的拓展架构。新的内核架构让Apache 2成为真正的跨平台服务器。操作系统层自身成为一个模块（MPM），使得该模块可以被各种操作系统装载。Apache 1是一个UNIX应用程序，移植到其他平台上会受到很多的限制，一些UNIX特性使得Apache 1在其他平台（如Windows和Netware）上性能较差，而Apache 2摆脱了这些特性的限制，使其成为一个真正的跨平台服务器。基于线程的MPM模块的引入也增强了UNIX上很多应用程序的可扩展性。Apache 2的缺点在于它的API不能向前兼容Apache 1，因此一些第三方的模块和应用程序需要缓慢地升级到Apache 2。作为一个稳定版本，Apache 2.2于2005年12月发布，相比之前版本具有一些较大的改进。Apache 2.2保留并拓展了Apache 2.0的API，因此，为Apache 2.0所编写的模块和应用程序同样适用于Apache 2.2。Apache 2.2版本对可扩展性和应用程序架构等方面进行了显著改进。如果说Apache 2.0提供了功能强大的应用平台基础，那么Apache 2.2则在此基础上进行了添砖加瓦。1.2 Apache软件基金会Apache软件基金会（ASF）为一系列应用范围广泛的开源软件项目提供组织上、法律上和财政上的支持。Apache软件基金会建立了一整套框架来管理知识产权和财政捐献，同时，限制捐献者潜在的、合法的资源泄漏。通过精诚合作的项目开发流程，Apache项目交付了企业级的、免费获取的软件产品，吸引大量的社区用户使用。注重实效的Apache许可证（Apache License）使得无论是商业用户还是个人用户都易于部署Apache的产品。Apache软件基金会的前身是Apache组织（Apache Group）。Apache软件基金会是一个非盈利的组织，基于成员制，以保证Apache项目在个人志愿者参与之外能够继续存在。如果个人承诺与开源软件开发项目合作，并不断地参与和贡献Apache软件基金会的项目，那么他（她）就有资格成为Apache软件基金会的成员。通过Apache基金会现有大部分成员的赞同和任命，个人才能成为软件基金会的成员。因此，Apache软件基金会为它所直接服务的社区所掌控，成员都为社区内的项目进行协作。Apache软件基金会的成员按照基金会的规章制度，每隔一段时间选举一个董事会，管理基金会的组织事务，由董事会任命成员监管基金会的日常事务。社区可以公开获取Apache基金会运作的记录。1.2.1 功绩组织模式（Meritocracy）很多软件产品都是在一个开放源代码的许可证之下进行开发的，Apache Web服务器则与此不同。Apache不是由某个开发者发起的（而Linux内核、Perl语言和Python语言都是由某个人发起的），而是一个由各种各样的人所组成的团队发起的，这些人具有相同的兴趣爱好，通过交换信息、补丁和各种建议认识彼此。当Apache开发团队不再延续NCSA版本，而是转向开发Apache自己的版本时，越来越多的人被这个项目所吸引，加入这个团队进行开发。最初，他们可能是发布一些小的补丁，给出一些开发建议，或者在邮件列表上回复一些问题，逐步贡献更多的力量，在开发中发挥着越来越重要的作用。当Apache开发团队觉得某个人已经获得足够的权限成为开发社区的一部分时，开发团队将授予这个人直接访问代码仓库的权限。这个方法不仅能够扩充团队力量，增强开发Apache的能力，而且能够使开发团队运作的效率更高。我们把这个方法称为功绩组织模式。这种模式使得开发团队不断壮大，而且没有内部矛盾和纷争。在其他模式下，权利可能是稀缺和保留的资源，而在Apache开发团队中，开发团队的新成员被看作是希望帮助团队进行开发的志愿者，而不是想占据权位的投机者。同时，由于Apache团队从不缺乏希望加入的新成员，因此，它不会因为在一个充满竞争的环境中缺乏优秀人才而盲目地扩充团队，从而导致开发团队成员良莠不齐。相反地，它严格对待团队的每个成员，要求每个成员都具备有据可寻的贡献和积极向上的态度。Apache团队是一个虚拟社区，因此它是一个全球范围的社区，不受地域限制。1.2.2 角色Apache开发团队具有以下的一些角色。用户用户是指使用Apache软件的人。用户以缺陷报告和功能建议的形式向Apache项目的开发人员提供反馈，从而对开发团队做出贡献。用户也可以参与Apache社区，通过邮件列表和用户支持论坛帮助其他用户。开发者开发者通过提交代码和文档的方式为项目做贡献。开发者比用户的工作要多，他们活跃在开发邮件列表上，积极参与讨论，提供补丁、文档、建议和批评。开发人员也被当作是贡献者。提交者提交人员是开发者，他被赋予了代码仓库的写权限，并且签署了贡献者许可证协议（Contributor License Agreement，CLA）。所有的提交者都有的邮件地址。提交者在处理补丁时不需要依靠其他人，可以独自做出短期的决定，并服从项目管理委员会（Project Management Committee，PMC）的监管。项目管理委员会成员项目管理委员会成员是由开发者或者提交者通过功绩选举产生的，作为其为项目进展所承担任务的酬劳。项目管理委员会成员具有代码仓库的写权限、的邮件地址、社区相关决定的投票权，以及建议把某个活跃用户提升为提交者的权利。项目管理委员会是总体上实施项目控制的实体。Apache软件基金会成员Apache软件基金会成员是根据其在基金会中的角色进展和演变，以及每个角色所取得的功绩，由Apache软件基金会的现有成员选择并任命的。Apache软件基金会成员负责管理基金会，如项目相关的核心事务、交叉项目活动等。从法律上来说，Apache软件基金会成员是基金会的股东之一。基金会成员拥有选举董事会的权利、成为董事会候选人的权利、建议提升某个提交者成为基金会成员的权利，以及广泛参与基金会内部其他角色的权利。1.2.3 哲学理念尽管这不是官方的列表，但其中的信念已经被认为是Apache基金会的核心哲学理念。这些理念有时候被引用为“Apache方法”：协作化的软件开发商业友好的标准许可证永远保证高质量的软件成员之间的交往要互相尊重，诚实，以技术为主依据标准的忠实实现强制的安全特性1.3 Apache开发流程Apache的开发流程既可以是自上而下的，也可以是自下而上的。采用自上而下的设计方法时，可以增加一些很棒的想法，如需要代码重写或者新的组件所带来的关键新特性、新功能，这些想法可能需要几个月甚至几年才能从概念变为成熟产品。而采用自下而上的设计方法时，可以增加一些小的补丁，用来修改一些软件Bug或者增加一些新的特性，这些小的补丁很容易融合到目前的软件版本中。模块式开发方法通常介于软件开发的宏观方法和微观方法之间。模块是一个自包含的插件，通常是开发者（大多数情况下是其他人）基于某种兴趣而实现的新特性。一个模块可能实现了Web服务器的核心功能，也可能实现了一个通用的服务，还可能实现了一个较小但是较为重要的功能，甚至只是一个单一目的的应用。如果某个模块实现了大家都比较感兴趣的功能，而且作者愿意公布，就可以集成到Apache的核心发布版本中。但是，如果该模块需要额外的支持（如第三方的库），或者可能会涉及该模块的许可甚至是知识产权的因素，那么，该模块可能就不会被集成到Apache的核心发布版本中，而是通过它的开发者或者第三方独立地发布，就像支持Apache的公司或者Linux版本的发行商那么做。1.3.1 Apache代码仓库和其他的软件项目一样，Apache也维护着一个代码仓库。这个代码仓库以项目为单位，和Web服务器相关的是httpd项目（包括代码、文档和编译文件）和apr项目。 Subversion所有的Apache代码都保存在代码仓库中，可以通过/进行访问。代码使用SVN进行管理，它是最近（2004年）开始使用的，之前我们使用的是和其功能类似、历史悠久的CVS系统。代码仓库的读取权限是公开的，但是写权限只有提交者才拥有。读权限允许任何人查看Apache开发过程中所走过的足迹，包括回顾任何单一或者累计的修改，针对这些修改所作的简要的解释（例如修改Bug、新的功能、内部改进等），以及修改的日期和参与修改的人员。 分支：主线、开发版本和稳定版本代码仓库中包含一个主线和几个分支，其中的任何文件的默认版本都是主线。在Apache项目中，主线代表正在进行中的工作。从定义上可以看出，它是未经过测试的版本，一般都包括一些实验性的代码。Apache当前的稳定分支是Apache httpd 2.2，可以在/branches/2.2.x/目录下找到。比较老的版本（如2.0和1.3）尽管已经不再是主要的开发方向，但是它们的分支还在维护中（尽管是精简地维护）。有时候也会为一些实验代码特别地创建一些分支，作为测试的基础。例如，当Apache2.2处于beta版测试时，为了支持异步I/O，需要对内核代码进行一些实质性的重写。这些修改后的代码对于主线来说过于实验化，因此，开发者决定创建一个新的开发分支来处理它们。这个新的分支随后逐渐地稳定下来并融入到主线中，并最终被包含在下一个稳定版本（2.4版）中。 审查和通过Apache的开发人员针对稳定版本和开发版本的代码采用不同的开发策略进行处理。稳定版本的代码总是遵从审阅并提交的方式（Review-Then-Commit，RTC），这就意味着任何将要加入到标记为稳定版本分支的代码，即使是最微不足道的补丁，也必须通过一个严格的审阅过程。开发版本的代码遵从提交并审阅的方式（Commit-Then-Review，CTR），这就意味着代码可能被某个提交者单方面地进行了增加、修改和删除，然后在恰当的时期由其他开发者进行审阅（当然，SVN使得对某个改变进行逆向操作变得非常容易）。不过，一些主要的变动需要在提交之前就进行审阅，或者使用单独的开发分支进行处理。 增加新的功能（backport）新的代码首先加入主线。如果某个开发人员想让这个代码成为稳定分支的一部分（通常是修改了Bug或是做了一点改进），那么这个代码就将进入backporting阶段。该阶段使用一个叫做STATUS的状态文件，包含了backporting的当前情况列表，如为backport进行的投票情况等。为了保证backporting的质量，代码的任何变动必须从提交者那里得到至少三张支持票。一张支持票意味着投票人已经审阅了这个变动，并对此表示认可，因此，三张支持票就明确意味着这个变动确实不错。即使是最简单的Bug修改也要遵守这个规则，这就是说为了得到足够多提交者的同意，有时候一个不是很重要的Bug修改也得需要很长时间。如果收到了三张支持票并且没有反对票，这个变动就可以加入到下一个稳定分支中了。可能审阅了这个变动的提交者对此并不满意，他将对此保留意见，甚至投反对票。投反对票的规则是必须附带一个说明，以及（或者）一个能够实现该变动目标的可选方案。被投了反对票的变动要么被放弃了，要么把其中的错误修正之后再次提交进行重新投票。反对票和保留意见通常会在开发者论坛中进行相关的讨论之后被进行处理。 发布Apache有时会发布新的版本。当前稳定代码版本（在本书正在写作时为2.2.x版）的发布使得用户可以感受到Apache的最新进展，也修改了一些Bug。这些发布版本将会打上最佳版本的标签并推荐给用户。通常由于开发者觉得已经有足够多的小变动积聚起来了，达到了新版本发布的要求，这样一个新的版本就发布了。不过有时候一个新的版本可能是因为某个安全问题引起开发者的注意而匆忙发布的。发布负责人通常由开发者志愿担任，负责管理发布流程并创建发布版本，其他的开发者将会全神贯注于开发在STATUS文件中已经核准的、但还没有解决的更新，并将其融入到稳定版本中。目前的策略是偶数版本的分支是稳定的，而奇数版本的分支打算供开发使用。因此2.0.x版本（2002年4月发布）和2.2.x版本都是稳定的，而2.1.x发布版供Apache2.2版本的alpha测试和beta测试使用。Apache2.1版本经过接近10个月的alpha测试和3个月的beta测试之后才成为最终的2.2稳定版本。一个发布版需要在每一个支持的平台上经过编译、安装、运行的测试。这些步骤对于稳定的发布版本来说是必需的。对于开发版本，尽管不是那么严格，也是应当如此。为了保证发布版本满足这些要求，发布负责人首先通过一个合适的SVN分支为这个版本创建一个Build版本，然后把这个版本告知Apache的开发者和测试者。这就在其发布之前提供足够的时间，让更多的开发者和测试者对其在不同的硬件环境、操作系统和应用环境上进行安装和测试。如果在测试中发现了一个严重问题，那么这个Build版将不被发布。所有的发布版本都由发布管理人进行可靠的PGP签名。很多Apache开发者的公钥，包括所有发布管理人的，都可以在/dist/httpd/KEYS获得。1.3.2 开发者论坛Apache Web服务器最主要的开发者论坛就是邮件列表。所有和Apache开发相关的技术细节都在这里讨论。一个与此类似的开发者邮件列表是针对APR开发的。这些论坛都是100%对外开放的，所有的讨论都被归档在一些地方（本章结尾部分的参考地址）。另外一个比较流行的开发者论坛是互联网中继聊天（Internet Relay Chat，IRC）。关于Apache的开发者频道是上的#httpd-dev和#apr。这些讨论地点都是完全对外开放的。在/ 的Apache Bugzilla是一个可以搜索的数据库，包括Bug报告、提升要求和补丁，也包括目前的和历史的数据。这个数据库也是完全对外开放的。不过要注意的是，既然是一个完全开放的数据库，它会含有很多的虚假报告（有些由于不能被结束而显示为“再次开放”）和不能被验证真伪的报告。考虑到某些补丁可能对用户有用，但是这些补丁却没有被标准的Apache发布版包括进来，因此这个数据库也包含了一些故意保留下来的、标记为“补丁可获取”（PatchAvailable）的报告。包含所有代码和变动的最完整、最精确的归档是位于/的Subversion代码仓库。这个代码仓库随着代码的变化而实时地被更新。读权限是开放和公开的，而写权限只授予认证过的提交者。在Subversion中值得注意的是STATUS文件和CHANGES文件，前者包括了目前的讨论和投票情况，而后者则提供了针对某个稳定/发布版本的变动的执行总结。1.3.3 开发人员Apache很重要的一个特点就是用户群体的多样性和开发群体的多样性。Apache项目不存在由某个公司或者某些公司主导的问题。有些开发者（包括作者在内）既是一个自由职业的顾问，也是一个小公司的员工。其他的开发者有些来自像IBM、Red Hat和Novell这样的大公司，有些来自像Google、Yahoo!和Ask Jeeves这样的大型客户，也有些来自科研院校和其他的非商业组织。虽然大部分开发者都是企业的员工，但是自由职业者的数量超过了任何一个公司的人数。更为重要的是，开发者的多样性反映了Apache广泛的应用范围。那些超级繁忙的站点（如CNN和HEAnet）需要用247的时间承担成千上万的并发用户负载，主要关注性能、扩展性和稳定性；而某些应用站点，例如作者的网站Valet，主要关注如何把Apache从它最初的Web服务器的角色拓展为应用服务器；电子商务网站主要关注安全性和可靠性；主机托管公司需要在维护安全和稳定的同时支持需求差异巨大的用户和代理控制。拥有数量众多来自各行各业的、活跃的开发者，使得Apache在所有这些应用环境下都能工作得很好。最后，Apache开发者社区决不是一个排外的黑客社区。尽管软件开发和维护是Apache开发者所有活动中最重要的，但仍然有人在没有写过一行C语言代码的情况下被提拔到Apache组织的高层，因为技术支持、文档编写和行政等工作与开发工作一样重要。1.3.4 参与Apache工作所有的社区论坛都是对公众开放的，这里欢迎任何一个想为Apache贡献力量的人。有很多种方式可以加入Apache，而每一种工作都很有意义。动手编码。欢迎为Bugzilla提出的Bug提供补丁。开发者可在列表上正在争论的主题或者在STATUS文件中突出强调的主题做出贡献。如果某位开发者想加入工作，可以到位于SVN的代码仓库中搜索TODO记录和FIXME记录。如果一个补丁能够干净地集成（通过diff u或者svn diff方式），并且有比较清晰的动机和功能描述，那么这个补丁是受欢迎的。补丁便可以通过开发者列表或Bugzilla发布。撰写文档。文档存放在SVN中。所有的原始文档都是XML格式的，该格式是DocBook的一个子集。欢迎撰写新的文档，或者对原有的文档进行修订（添加补丁）。文档翻译。文档一般都具有多个语言的版本。但不是文档中每一页都具有不同语言的版本，而且文档的翻译版本也不一定都是最新的。因此如果你具有语言天赋，那么就去找到缺失的或者过时的文档并修正它们吧。测试软件。在你的平台上构建并测试代码，特别是当你具有一个与众不同的平台时。使用不寻常的环境和工具构建Apache，它能够干净地构建和安装吗？可以使用你所有不寻常的任务对它进行压力测试。如果它失败了，或者你发现它相对于之前的版本有一个意想不到的变化，试着去诊断究竟发生了什么。把你找到的任何Bug都通过开发者列表和Bugzilla报告出来。努力保证你所描述的情况是清晰明了并且可重现的。构建软件。维护Apache的构建和安装是一个很重要的任务，但是直到本书写作为止我们都没有很好地处理它。即使是在UNIX/Linux家族平台上最广泛使用的GNU基于自动配置的安装，检查一下都是有好处的。1.4 Apache和知识产权所有的Apache项目的版权都归Apache软件基金会所有，并使用Apache许可证进行许可。同时，Apache软件基金会和项目管理委员会采用各种方法来保证当没有合法绑定时，Apache的代码中不包含第三方的有知识产权的代码，并且用来发布的写权限处于Apache许可证的保护之下。不过，值得注意的是，虽然Apache掌握一个项目的整体版权，但是项目中某个部分的版权可能归个人贡献者所有，并基于Apache软件基金会的条款进行许可。1.4.1 Apache许可证Apache许可证（可以在附录A中找到）是一个自由的软件许可证，基于传统的BSD和MIT软件许可证，增加了适合我们时代要求的一些重要条款。它满足自由软件和开源软件所有已经被接受的定义。可能自由软件的术语让一些读者感到迷惑，我们暂且对其中的某些重要部分进行澄清。值得注意的是，这只是一些基本的背景信息，可能对任何一个特定国家的读者来说不是法律忠告。自由的言论，不是免费啤酒免费的啤酒是美妙的，但是自由的言论更加重要。当我们谈到软件自由时，一般都会有自由言论的感觉。软件自由主要体现在任何人都有想做什么就做什么的自由（当然，可以自己去做，也可以雇人去做）。源代码开放也是软件自由的一个必要组成部分。价格和软件自由不相关。Apache可以通过各种价格获得，从免费的下载，到捆绑在一个商业Linux版本的软件包，甚至是由商业组织开发的全额软件产品。非公开领域和其他很多自由软件类似，Apache不是一个公开领域。Apache的版权为Apache软件基金会所拥有，并具有许可证。和那些商业软件的许可证相比，Apache的许可证显得更加友好，并且没有那么多的限制。不是共享软件和广告软件共享软件（包括Nagware、广告软件等）概念上和自由软件类似。它们通常（尽管不是全部）都被认为是质量较差的、比较业余的产品，如今通常都是受商业驱使开发，而不是受技术驱使。不是GPL由自由软件基金会（Free Software Foundation）编写并拥有的GNU通用公众许可证GPL（General Public License），是最老的也是最广为人知的（同时也是最误传的）自由软件许可证。GPL引入的一个概念称为copyleft（和copyright对应），它的基本理念可以总结如下：“我们授予你这些自由，而你不能把这些自由从其他人手里拿走。”这个策略有时候被认为是商业不友好的，因为copyleft软件不管愿意不愿意，是不能被融入到非自由软件中的。Apache许可证明显是商业友好的，它不是copyleft。事实上，Apache许可证甚至和GPL是互不兼容的。这是因为每一个许可证都有一些规定，这些规定和其他的许可证是互不兼容的：GPL软件使用Apache软件基金会条款进行发布，因为copyleft的限制导致和Apache软件基金会策略不兼容。Apache软件基金会许可的软件也不能使用GPL条款进行发布。关于这个问题我们可以看看自由软件基金会是如何说明的：Apache许可证是一个自由软件许可证，但是它和GPL不兼容。Apache许可证之所以和GPL不兼容是因为它具有一个特别的要求，而GPL没有：它具有一些专利终止的情况，而GPL不需要。（我们不认为具有这些专利终止情况就不好，但是它们和GNU的GPL不兼容。）但是这些因素对于终端用户和第三方（如模块开发者或发布者）来说并不是问题。Linux（GPL）厂商例行公事地在他们的产品中包括了Apache，也有很多的Apache模块是GPL许可的。Linux发布者同时遵守两种许可，模块开发者为他们的工作选择遵从某个许可，这些都没有问题。即使是最崇尚单一的、对法律最小心翼翼的Debian发布版本也为Apache发布了GPL的模块。当和GPL软件进行接口时，许可的不兼容会导致一些问题。以MySQL的实现为例，MySQL是一个GPL许可下的SQL数据库软件包，为了遵从MySQL的GPL许可要求，MySQL的Apache/APR驱动也是GPL许可的，因此不能被ASF集成在Apache中进行发布。作为替代选择，它可以从其作者的网站上进行单独下载，或者从第三方作为一个单独的软件包获取。这就只和自己编译Apache的用户相关，而那些使用软件包安装的用户就永远不需要关注这些细节问题。专利和反强盗条款对于技术开发者来说，当今最大的危险就来自于专利，这种情况在美国尤为突出。在美国，专利系统一直被看作是维护经济垄断的工具：为“我们”的公司申请成千上万的专利，然后通过世界贸易组织（World Trade Organization，WTO）的条约将这些专利执行，以期获得全球竞争优势。结果就是，美国的专利局要处理大量的专利事务，导致没有办法对每个专利进行详细审查和质量控制。很多这样的专利就掌握在对技术没有丝毫兴趣的人手上，他们期望从合法的商业中勒索钱财。切实的感受就是：这就是当今的强盗。在过去，某个国家、省或者城市的统治者会为“他们的”海进行圈地声明，向每一个经过他们领地的外来船只收取一定数量的过路费，并且允许私掠船（战时特准攻击敌方商船）保护他们的财产权利，查封任何经过而没交费的船只。类似的，如今的专利持有人向合法的商业索取费用，雇佣律师来强化他们的财产。事实上，如今的这种强盗行径比过去更为恶劣：如今专利的数量比过去海上的强盗数目多得多，也不再存在安全的航线了。Apache许可证的一个非同寻常的限制就是尽可能地处理这种情况。接受Apache的许可意味着不能有任何反对Apache软件基金会和Apache用户的专利权限。据我所知，Apache从没有卷入到知识产权的法律案件中。这和在SCO案件中Linux面临的情况形成了鲜明的对比（尽管看起来Linux很可能会辩护成功），更不用提和微软所面临情况的对比：微软的用户已经为微软软件中由于违反专利而向第三方支付了大量的补偿，。 1.4.2 第三方知识产权Apache的知识产权通过版权和许可证进行保护。当然，Apache也不会侵犯其他人的知识产权，这点也很重要。这就意味着所有对Apache的重要贡献都必须使用正确的方式进行捐赠。在一个开发人员成为提交者之前，他（她）必须签署一份贡献者许可协议（Contributor License Agreement，CLA），使得Apache软件基金会被授予所有必需的权利来使用这个开发者的贡献，并将其通过Apache软件基金会条款向第三方进行许可。贡献者许可协议使得开发者在加入Apache之前，限制他们承认所有的贡献不是他们自己的原创工作，而是签字移交给Apache。贡献者许可协议的全文可以参考附录B。如果一个开发者自己不能决定（例如，一个雇员的雇主可能对他或她的工作拥有权利）时，需要该开发者的授权上级领导（例如，首席技术官或者IT主管）签发一个企业贡献者许可协议（Corporate CLA，CCLA），企业贡献者许可协议的全文可以参考附录B。在开发者可以被授予提交访问权限之前，所有的贡献者许可协议、企业贡献者许可协议必须形成文档并保留在Apache软件基金会。这些协议被用来保证提交者和他们的雇主不能阻止Apache软件基金会或Apache的用户使用他们的贡献。职责首先，每一个提交者都必须保证他（她）的贡献没有侵犯第三方的知识产权，这是他们的职责。全面的职责是属于项目管理委员会的，它将质疑任何出现可疑情况的贡献，特别是主要的新贡献。审计尽管所有都考虑到了，仍然可能出现第三方知识产权的问题。Apache有一条完整的审计链，由Subversion管理。因此，即使在最坏的情况下，任何有问题的代码都可以被查出来并删除。1.5.1 交互式在线论坛公共邮件列表Apache模块开发者列表是一个讨论任何和模块开发相关问题的好地方。这个列表在2006年9月移到，因此可以查看这两个列表上的资料。Apache Web服务器的官方开发者列表是，欢迎大家参与，不过请不要离题。Apache 可移植运行时库（Apache Portable Runtime, APR）的官方开发者列表是，欢迎大家参与，不过请不要离题。Apache的用户列表是，是一个讨论各种问题和进行用户支持的论坛。用户组systems.www.servers.unix|windows|mac|misc新闻组是一个对不同平台上Apache的各种问题进行讨论的好地方。在线交谈在irc:/上有几个频道和Apache相关。#apache：通用支持/非官方的帮助台频道。可以问一些有意义的问题并等待答案。但是首先你必须做功课，特别是要看错误日志。注意fajita，它是#apache的机器人程序，它将做很多的常规工作如回答你的问题，或者贴出一些相关的文档页面地址。#apache-modules：针对模块开发的频道。这个频道非常适合本书的读者。#apr：APR半官方的频道，包括自动的、对APR代码仓库变动的实时通告。#httpd-dev：Web服务器开发的半官方频道，包括自动的、对代码仓库变动的实时通告，以及文档和网站。#asfinfra：Apache的架构频道。1.5.2 会议Apache软件基金会为专注于Apache软件基金会项目的开发者组织了ApacheCon会议。这些会议将很多的开发人员聚集到一起（这些开发人员在网上论坛中互相都比较熟悉，但是他们中间很多人都不曾面对面相聚过）。用户也许只是过来学习的，但是他们有时也会给开发者带来一些新的见解。会上有开发者和用户共同参与的教程和报告，可能是官方组织的，也可能是非正式的社会事务，安排得非常紧凑。1.5.3 网站官方和半官方的Apache网站/ Apache软件基金会/ Apache Web服务器/ APR主站/ Apache代码仓库/ Bug数据库/ Apache 模块注册/modules/ 更新的模块注册（正在建设中）/ 邮件列表文档/ Apache提交者的个人主页/ ApacheCon会议/ mod_perl/ （Apache的Perl API）/ mod_python （Apache的Python API）/ Apache中的TCL语言/cli/ mod_aspdotnet （微软的ASP.Net）第三方扩展/ 笔者所编写的20多个模块http:/www.outoforder.cc/ 其他工作的12个有特色的模块/ PHP语言/ Ruby on Rails开发者文档/ API参考/dev/ 笔者创建和维护的开发者教程/apr/apr-tutorial/html/apr-tutorial.html 针对APR的有用教程，将它的角色从Web服务器中剥离出来/ 本书的官方网站，还没有完成其他的教程、新闻和文章/pub/q/all_apache_articles 大量的文章/ 新闻网站，也是Windows二进制程序的下载站点（通常比“官方”要早一些发布）/ 邮件列表文档1.6 小结本章介绍了Apache的社会背景、历史背景和法律背景，以及Apache的文化。第1章特别介绍了以下几个方面：Apache httpd的发展历史Apache软件基金会和它的文化Apache的开发者、流程、开发和技术支持的资源，包括如何参与ApacheApache对待知识产权的方法，包括Apache许可证和避免误用第三方知识产权的安全机制第1章是与技术无关的，而本书后续部分将全部是关于Apache开发的。本书以容易理解的概述开始，然后将转向对模块和应用程序开发进行实际操作训练。Apache作为常驻的后台任务运行：在UNIX系统中为守候进程（Daemon），在Windows系统中为服务（Service）。由于Apache服务器的启动阶段比较耗费时间和资源，因此它一般在操作系统启动时被启动并一直运行。Apache的早期版本曾支持inetd模式，但是该模式已经不再适合实际的应用。2.1 纵览Apache的HTTP服务器由一个相对较小的内核及一些模块组成，如图2.1所示。模块可以静态的编译到服务器中，但是通常都把模块放在/Modules/目录或者/libexec/目录下面，服务器运行时这些模块被动态加载。另外，Apache服务器依赖底层的可移植运行时库（Apache Portable Runtime，APR）。可移植运行时库提供跨平台的操作系统抽象层和功能函数，为上层模块提供统一的接口，这样模块可以避免受到不可移植的操作系统调用的影响。多处理模块（Multi-Processing Module，MPM）是一个特殊的功能模块，用来根据底层的操作系统来优化Apache。多处理模块通常是唯一直接访问操作系统的模块，其他模块可以通过可移植运行时库来访问操作系统。图2.1 Apache架构2.2 Apache运行的两个阶段Apache的运行分为启动阶段和运行阶段。启动阶段时，Apache以特权用户root启动，进行解析配置文件、加载模块和初始化一些系统资源（例如日志文件、共享内存段、数据库连接）等操作。处于运行阶段时，Apache放弃特权用户级别，使用非特权用户来接收和处理网络中用户的服务请求。这种基本安全机制可以阻止Apache中由于一个简单软件错误（也可能是模块或脚本）而导致的严重系统安全漏洞，例如微软的IIS就曾遭受“红色代码（Code Red）”和“尼姆达（Nimda）”等恶意代码的溢出攻击。Apache的这种两个阶段的运行方式对应用程序的架构具有一定影响。首先，任何需要系统级权限的操作都必须在系统启动时运行。其次，最好在启动阶段进行尽可能多的初始化工作来简化处理每个请求时的工作量。这样做带来的影响就是：由于耗费很多时间和资源的操作都集中在启动阶段完成，因此Apache以inetd或tcpserver模式运行时效率就会非常低。Apache的架构有一个不符合常规的古怪之处：配置代码实际上在启动阶段执行了两次（尽管不是重新启动）。第一次，检查服务器配置是否正确（至少，Apache能够成功启动）；第二次是真正的系统启动，然后引导至运行阶段。这种启动执行两次的行为大多数模块都能忽略（如APR池能够保证不会引起资源的泄漏），但是，对某些模块还是有影响的。例如，某些模块在系统启动阶段动态加载新的代码，如果想要这些代码只加载一次，那么就需要采用某些技巧（例如采用检查全局标志位的方法）来保证加载操作只做了一次。2.2.1 启动阶段Apache在启动阶段读取配置文件、加载模块和函数库，以及分配资源。每个模块可能都需要资源，并在启动阶段对这些资源进行初始化。Apache在启动阶段拥有系统最高权限，以单进程、单线程方式运行。 配置Apache的主配置文件通常为httpd.conf。但是由于这种命名方式为一般惯例，并非强制要求，因此提供.rpm或者.deb包的第三方，Apache发行版本可能使用不同的命名机制。另外，httpd.conf文件可能是单一文件，也可能是通过使用Include指令包含不同配置文件的多个文件集合。有些发行版本的配置非常复杂。例如Debian GNU/Linux的Apache配置需要对Debian非常熟悉而不是Apache。本书并不探讨不同配置设计的优缺点，因此，为了简化，我们认为配置文件为httpd.conf。httpd.conf文件是一个文本文件，在系统启动时被逐行解析。该文件由指令、容器和注释组成。配置文件内允许有空行和空格，它们在解析时被忽略不计。指令（Directives）httpd.conf文件中大多数内容是指令。指令可以没有参数，也可以有多个参数，参数之间用空格隔开。每一个指令有自己的语法格式，不同的指令允许不同的参数个数和参数类型（有字符串、数字、枚举、布尔或文件名等）。指令是在内核或者一些模块中实现的，我们将在第9章中介绍。以下是几个指令的实例。LoadModule foo_module modules/mod_foo.so这个指令由mod_so模块实现，用来加载一个模块。第一个参数是模块名（字符与数字组成的字符串），第二个参数是文件名，可以是服务器根目录的绝对路径或者相对路径。DocumentRoot /usr/local/Apache/htdocs这个指令由内核实现的，用来设置网页所在主文档树的根目录。SetEnv hello “Hello, World!”这个指令由mod_env模块实现，用设置环境变量。注意，由于第二个参数包含空格，我们必须用双引号把它包含起来。Choices On这个指令由mod_choices（将在第6章介绍）实现，用来激活模块的选项。容器（Containers）容器是一系列指令的集合，语法和标记语言很相像，使用尖括号进行归类。容器在语义上和其他指令不同，具有一个开始和结束的分隔行，在分隔行之间的指令为容器内部的指令。例如由内核模块中的容器如下所示，该容器定义了一个虚拟主机。 ServerName DocumentRoot /usr/www/example ServerAdmin W CustomLog /var/log/www/example.log 容器为里面的指令提供了上下文。在上面这个例子中，指令只对访问的请求进行响应。容器可以被嵌套使用，除非某个模块显式地声明容器不能嵌套。所有用到的指令，包括容器，都可能是上下文相关的，因此它们在某些具体的上下文中才有效。注释（Comments）如果一行语句以#号开头，那么该行被认为是注释语句。例如下面的语句为注释。# this line is a comment行中的#一般不会被认为是注释，除非模块明确地在实现该指令时支持行中注释。如果模块没有被加载，那么该模块所实现的指令就不能被识别。遇到这种情况时，Apache执行停止并返回一个语法错误。因此mod_so模块必须用静态的方式进行链接来加载其他模块。这一点非常重要！当你开发新的模块时没有静态地链接mod.so，那么每次在修正该模块时必须重新编译整个服务器程序。2.2.2 运行阶段在启动阶段末期，程序的控制转向多处理模块MPM（见2.3节）。MPM模块在系统级管理Apache的运行。它根据操作系统和应用的约束（如一些特殊场景的应用）维护进程池和/或线程池。MPM的进程作为控制者，管理一系列子工作进程。子工作进程用来处理接入请求，而控制者进程负责创建和删除子工作进程，以及处理信号量（如停止或者重启）。MPM的架构导致不可能在有限的的范围内描述运行阶段。尽管标准的MPM采用工作子进程的方式，但是MPM并没有被限制只能使用这一种方式。理论上MPM可以在系统层上实现其他完全不同的服务器架构。2.2.3 停止阶段虽然没有明确的停止阶段，但是需要在服务停止的时候完成的工作应被注册为清除操作（在第3章中介绍）。当Apache停止的时候，所有注册的清除操作都将运行。 2.3 多处理模块MPM在启动阶段的末期，当所有的配置信息被读取之后，Apache的控制转到多处理模块MPM。MPM提供Apache服务程序和其所在的操作系统之间的接口。该模块的主要职责是根据所在的操作系统平台来优化Apache，提高Apache的效率，保证Apache的安全。MPM自身也是一个模块，这点我们能够从它的命名看出。值得注意的是，MPM是Apache中唯一的一个系统层模块（因此开发MPM已经超出本书关于应用程序开发的范围）。同样一个Apache实例只能有一个在编译时所选择的MPM。2.3.1 为什么需要MPM老版本的NCSA server和Apache 1是在UNIX系统中成长起来的。当时Apache是一个多进程服务器，一个服务进程处理一个用户请求，如果当前并发客户访问数量大于服务进程数，Apache便