httpd，Apache HTTP 服务器

httpd，Apache HTTP 服务器
上一页	第 6 章服务器配置	下一页

Apache HTTP 服务器是Subversion可利用的一个“重型”网络服务器。通过一个定制的模块，httpd使 Subversion资料库可以通过WebDAV/DeltaV协议被客户端访问，这种协议是HTTP 1.1协议的一个扩展（更多的信息参见http://www.webdav.org/）。这种协议使用无所不在的、作为互联网核心的HTTP协议，并添加了写入 ——特别是，版本化的——能力。得到的是一个标准的，健壮的系统，为了方便，它被作为Apache 2.0软件的一部分打包，被大量操作系统和第三方产品所支持，并不需要网络管理员打开另一个指定的端口。 ^[21] 虽然Apache-Subversion服务器有比svnserve更多的特性，但是它也比较难设置。灵活性往往带来更多复杂性。

以下大部分讨论包含到Apache配置指南的引用。虽然一些例子给出了这些指南中用法，但是完整的描述他们不在本章范围之内。Apache 团队维护着很优秀的文档，在他们的http://httpd.apache.org网站上供公共使用。例如，对配置指南的通用参考位于http://httpd.apache.org/docs-2.0/mod/directives.html。

并且，在你对你的Apache配置作修改的过程中可能会犯错误。如果你还不熟悉Apache的日志系统，你应该去了解它。在你的 httpd.conf文件里有对指定Apache产生的访问和错误日志（分别是 CustomLog 和ErrorLog指导）的磁盘位置的指示。Subversion的mod_dav_svn也使用Apache的错误日志接口。你通常可以浏览这些文件的内容得到可能反映问题源头的信息，在其它地方不容易看出来。

为什么用 Apache 2?

如果你是一个系统管理员，那么很可能你已经在运行Apache web服务器并对它有些前面的经验。在开发的时候，Apache 1.3是那时为止最流行的Apache版本。大家在升级到Apache 2.X系列有点慢有各种原因：有些人们害怕改变，特别是改变像web服务器这样关键的东西。另一些人依赖于只能工作于Apache 1.3 API的插件模块，而在等待到2.X 的移植。不管什么原因，许多人们在刚发现Subversion的Apache模块是特别为Apache 2 API而写的后就开始担心。

对这个问题的正确的反应是：不要担心。同时运行 Apache 1.3 和 Apache 2是很容易的。只要在分开的地方安装他们就行了，并使用 Apache 2 作为运行在不同于80端口的其它端口上的专用的Subversion服务器。客户端可以通过在URL中指定端口号来访问资料库。

$ svn checkout http://host.example.com:7382/repos/project
…

先决条件

要让你的资料库通过HTTP上网，你基本上需要四个组件，它们在两个包中。你需要Apache httpd 2.0， mod_dav随它而来，以及Subversion，和随它发行的mod_dav_svn文件系统提供模块。只要你有了所有这些组件，那么让你的资料库上网就像下面这样简单：

让httpd 2.0起来并和mod_dav模块一起运行,
安装mod_dav的mod_dav_svn 插件，它使用Subversion的库来访问程序库，并且
配置你的httpd.conf文件来公开资料库。

你可以用两种办法完成头两步：从源代码编译httpd 和 Subversion，或者通过在你的系统上安装预构建的二进制包。要看最新的关于如何编译Subversion来使它可和Apache HTTP服务器一起使用，以及如何为这目的编译和配置Apache本身的说明，参见在Subversion 源代码树顶级目录的INSTALL文件。

基本的Apache配置

一旦你在系统上安装了所有必需的组件，剩下的就是通过Apache的httpd.conf文件来配置它。要使用 LoadModule指令来命令Apache加载mod_dav_svn 模块。这个指令必须置于其它所有有关Subversion的配置条目之前。如果你的Apache是用缺省布局安装的，那么你的mod_dav_svn模块应该已经被安装在你的Apache安装位置（通常是 /usr/local/apache2）的modules子目录中。LoadModule语法简单，就是把一个命名的模块映射到磁盘上的共享库位置：

LoadModule dav_svn_module     modules/mod_dav_svn.so

注意如果mod_dav被作为一个共享对象编译（而不是直接静态链接到httpd二进制文件），那么你也需要相似的LoadModule语句，而且一定要放在mod_dav_svn行之前：

LoadModule dav_module         modules/mod_dav.so
LoadModule dav_svn_module     modules/mod_dav_svn.so

现在，在你的配置文件后边一点，你需要告诉Apache你在哪里保存你的Subversion资料库（或那些资料库）。Location指令有点像XML格式，开始与一个打开标签，并结束于一个关闭标签，中间有各种其它的配置指令。 Location指令的目的是通知Apache在处理定向到某个给定的URL或它们某个孩子的请求时作某些特殊的事。在Subversion的情况下，你只是要Apache把对指向版本化资源的URL的支持交给DAV层。你可以命令Apache把对所有路径（跟在服务器名字和可选的端口号后的部分）以/repos/开头的所有URL的处理委托给一个DAV提供者，它的资料库位于/absolute/path/to/repository。这使用下面的httpd.conf语法：

<Location /repos>
  DAV svn
  SVNPath /absolute/path/to/repository
</Location>

如果你计划支持多个资料库，它们位于你本地盘的同一个父目录里，那么你可以使用另一个指令，SVNParentPath，来指明共同的父目录。例如，如果你知道你会在/usr/local/svn目录创建多个Subversion资料库，它将通过类似http://my.server.com/svn/repos1， http://my.server.com/svn/repos2，等等的URL来访问，那么你可以用下面例子中的 httpd.conf配置语法：

<Location /svn>
  DAV svn

  # any "/svn/foo" URL will map to a repository /usr/local/svn/foo
  SVNParentPath /usr/local/svn
</Location>

使用前面的语法，Apache将把对所有路径以/svn/开头的URL的处理交给Subversion DAV提供者，它将假设任何在被SVNParentPath指令指定的目录里的对象是实际的Subversion资料库。这是个非常便利的语法，因为不像SVNPath那样，你不必重起Apache来创建新资料库并使它上网。

在你定义你的新Location时，一定要确定它没有和其他输出位置重叠。例如，如果你主要的DocumentRoot是/www，那么不要公开在<Location /www/repos>里的Subversion资料库。如果进来一个对URI /www/repos/foo.c的请求， Apache会不知道是该找在DocumentRoot里的repos/foo.c文件还是该委托mod_dav_svn从Subversion资料库里返回foo.c文件。

服务器名字和COPY请求

Subversion利用COPY请求类型来执行服务器端的文件和目录复制。作为Apache模块健全性检查的一部分，复制的源应该和复制的目的地位于相同的机器上。为了满足这个需求，你需要告诉mod_dav你服务器主机的名字。通常，你可以在httpd.conf文件里使用ServerName指令来实现：

ServerName svn.example.com

如果你在通过NameVirtualHost指令来使用Apache的虚拟主机支持，那么你可能需要使用ServerAlias指令来指定你的服务器认识的其它名字。同样，参考Apache文档可以得到全部细节。

现在，你应该严肃考虑权限的问题。如果你已经运行了Apache一段时间，那么你可能已经有了一些内容——网页，脚本等等。这些对象已经配置了一组权限，使它们可以和Apache一起工作，或更恰当的说，使Apache可以和这些文件一起工作。当Apache作为一个Subversion服务器使用时，也会需要正确的权限来读写你的Subversion资料库（参见服务器和权限：一点警告）。

你需设置一个权限系统来满足Subversion的需要而不扰乱任何先前存在的网页或安装的脚本。这可能意味着修改你的Subversion资料库的权限来配合Apache为你提供服务所用到的其它东西的权限，或者可能意味着在httpd.conf中使用User和Group指令来指定Apache以拥有你的Subversion 资料库的用户和组来运行。没有正确设置你的权限的唯一方法，每个管理员有各种原因从而要用特定的方式。只要明白权限相关问题可能是在为和Apahe一起使用而配置Subversion资料库时最常忽视的事。

认证选项

这时，如果你配置的httpd.conf包含像这样的东西

<Location /svn>
  DAV svn
  SVNParentPath /usr/local/svn
</Location>

……那么你的资料库是可以被全世界“匿名”访问的。除非你配置了某些认证和授权政策，否则通过Location指令供使用的Subversion资料库将可以被每个人访问。换句话说，

任何人都可以使用Subversion客户端来检出资料库URL（或任何它的子目录）的工作副本，
任何人都可以交互式的浏览资料库最新的修订版，只要把他们的web浏览器指向资料库URL，并且
任何人都可以提交到资料库。

基本HTTP认证

认证客户端的最简单的方式是通过HTTP基本认证机制，它只用用户名和密码来验证用户是她所宣称自己是的那个人。Apache提供了 htpasswd工具来管理可接受的用户名和密码的列表，那些是你希望授予对你的资料库特殊访问权的用户。让我们来授予Sally和Harry提交访问权。首先，我们需要把他们加到密码文件里。

$ ### First time: use -c to create the file
$ ### Use -m to use MD5 encryption of the password, which is more secure
$ htpasswd -cm /etc/svn-auth-file harry
New password: ***** 
Re-type new password: *****
Adding password for user harry
$ htpasswd /etc/svn-auth-file -m sally
New password: *******
Re-type new password: *******
Adding password for user sally
$

接下来，你需要在你的Location块里再添加某些httpd.conf指令来告诉Apache如何处理你的新密码文件。 AuthType指令指定了使用的认证系统类型。在现在这种情况下，我们要指定Basic认证系统。AuthName是你为认证域给定的任意名字。大部分浏览器在询问用户名字和密码时会显示一个弹出对话框。最后，使用AuthUserFile指令来指定你使用htpasswd创建的密码文件的位置。

在加了这三个指令后，你的<Location>块会看起来像这样：

<Location /svn>
  DAV svn
  SVNParentPath /usr/local/svn
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /etc/svn-auth-file
</Location>

这个<Location>还没有完成，没有什么用处。它仅仅告诉Apache，在任何需要认证的到时候，Apache应该从Subversion客户端获取用户名和密码。但是，这儿缺少的是告诉Apache哪种客户请求需要授权的指令。在任何需要授权的时候，Apache也要求认证。最简单的做法是保护所有的请求。加上Require valid-user告诉Apache所有请求都需要用户认证：

<Location /svn>
  DAV svn
  SVNParentPath /usr/local/svn
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /etc/svn-auth-file
  Require valid-user
</Location>

一定要读下一节（“Authorization 选项”一节）来得到关于Require的更多细节和其它设置授权政策的方法。

一点警告：HTTP基本认证的密码在网络让以接近明文的形式来传送，因而非常不安全。如果你担心密码窥探，那么最好使用某种SSL加密，从而客户端认证要通过https://而不是 http://；最少，你可以把Apache配置为使用自签名的服务器证书。 ^[22] 可以查询Apache的文档（和OpenSSL文档）来查找如何实现这种配置。

SSL 证书管理

由于业务需要，要公开他们的资料库从而使得它们可以从公司防火墙外访问时，应该意识到未授权部分的网络流有可能被“嗅探”。 SSL能减少因这种讨厌的关注而导致敏感数据泄露的可能。

如果Subversion客户端是使用OpenSSL来编译的，那么它就获得了通过https:// URL来和Apache服务器交互的能力。 Subversion客户端使用的Neon程序库不仅能验证服务器证书，而且也能在需要时提供客户端认证。当客户端和服务器已经交换了SSL证书并成功地互相认证时，所有以后的通讯将被一个会话秘钥（session key）加密。

描述怎样产生客户和服务器证书以及怎样配置Apache来使用他们超出了本书的范围。其它很多书，包括Apache自己的文档，都描述了这个任务。但可以在这里谈的是怎样从一个普通的Subversion客户端来管理服务器和客户证书。

在通过https://和Apache交互时，Subversion客户端可以接受两种不同类型的信息：

服务器证书
对客户证书的请求

如果客户端收到服务器证书，它需要验证是否信任整个证书：这个服务器确实是它宣称是的那个么？OpenSSL库通过检查服务器证书的签名者或者说是发证机构（CA）来验证。如果OpenSSL不能自动信任CA，或者如果发生了某些问题（比如过期证书或不匹配的主机名），Subvresion命令行客户程序会问你是否无论如何都要信任服务器证书：

$ svn list https://host.example.com/repos/project

Error validating server certificate for 'https://host.example.com:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: host.example.com
 - Valid: from Jan 30 19:23:56 2004 GMT until Jan 30 19:23:56 2006 GMT
 - Issuer: CA, example.com, Sometown, California, US
 - Fingerprint: 7d:e1:a9:34:33:39:ba:6a:e9:a5:c4:22:98:7b:76:5c:92:a0:9c:7b

(R)eject, accept (t)emporarily or accept (p)ermanently?

这个对话应该看起来很熟悉；实际上它你可能从你的web浏览器（它就像Subversion不过是一个HTTP客户端）看到过相同的提问。如果你选择(p)ermanent这个选项，服务器证书将被缓存到你的私有的运行时auth/区域，和缓存你的用户名和密码的方式相同（参见“客户凭证缓存”一节）。如果做了缓存，Subversion会自动记住在将来交互时要信任这个证书。

你的运行时servers文件也给了你让你的Subversion客户端来自动认证指定的CA们的能力，可以是全局的也可以以每个主机为基础。只要设置ssl-authority-files变量，给它一个以分号分隔的PEM编码的CA证书列表。

[global]
ssl-authority-files = /path/to/CAcert1.pem;/path/to/CAcert2.pem

很多OpenSSL安装后也会有一组预定义的“缺省的”CA，它们几乎是普遍被信任的。要让Subversion客户端资料库信任这些标准的授权机构，需要设置ssl-trust-default-ca变量为true。

当和Apache交谈时，Subversion客户端可能也收到对客户证书的要求。Apache在要求客户端确定自己的身份：这个客户端确实是它说自己是的那个么？如果一切正确，Subversion客户送回一个私有的、被Apache信任的CA签名的证书。客户端证书通常以加密格式存储在磁盘上，并被本地密码保护。当Subversion收到这个要求，它会问你证书的路径和保护它的密码：

$ svn list https://host.example.com/repos/project

Authentication realm: https://host.example.com:443
Client certificate filename: /path/to/my/cert.p12
Passphrase for '/path/to/my/cert.p12':  ********
…

注意客户证书是“p12”文件。为了在Subversion中使用客户证书，它一定要是PKCS#12格式的，这是一个可移植的标准。大部分web浏览器已经能用这种格式导入和导出证书。另一个选择是使用OpenSSL 命令行工具来把现有的证书转换为PKCS#12格式。

此外，运行时servers文件使你能基于每个主机来自动处理认证需求。所需的两种信息都可以用运行时变量描述。

[groups]
examplehost = host.example.com

[examplehost]
ssl-client-cert-file = /path/to/my/cert.p12
ssl-client-cert-password = somepassword

只要你设置了ssl-client-cert-file 和 ssl-client-cert-password变量，Subversion客户端就能自动回应客户端的认证要求而不用提示你。 ^[23]

Authorization 选项

到这时，你已经配置了认证，但还没配置授权。Apache会质询客户端并证实身份，但是它还不知道怎样运行或限制具有这样身份的客户端的访问权限。本节描述两种控制对你资料库访问的策略。

普适的访问控制

访问控制最简单的形式是授予一定的用户或者是对资料库的只读访问权，或者是对资料库的读/写访问权。

你可以通过在你的<Location>块里添加Require valid-user指令来在所有资料库操作上限制访问权。还用我们前面的例子，这将意味着只有哪些宣称自己是harry 或 sally而且为他们各自的用户名提供了正确的密码的客户端，才被允许在Subversion资料库上做任何事情：

<Location /svn>
  DAV svn
  SVNParentPath /usr/local/svn

  # how to authenticate a user
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /path/to/users/file
  
  # only authenticated users may access the repository
  Require valid-user
</Location>

有时你不需要如此严谨的管理。例如，Subversion自己的源代码资料库位于http://svn.collab.net/repos/svn，允许全世界任何人执行只读的资料库任务（比如检出工作副本，和用web浏览器浏览资料库），但是所有写操作都需要用户认证。要做到这种选择性的限制，你可以用Limit 和LimitExcept指令。和Location类似，这些块有开始和结束标记，你可以把它们嵌入在你的 <Location>块里。

Limit 和 LimitExcept的参数是被这个块影响的HTTP请求类型。例如，如果你想禁止除了目前支持的只读操作之外的所有其他对你资料库的访问，你可以用LimitExcept指令，传递GET， PROPFIND，OPTIONS和 REPORT请求类型为参数。然后前面提到的Require valid-user要被放进 <LimitExcept>块而不是只在<Location>块里。

<Location /svn>
  DAV svn
  SVNParentPath /usr/local/svn

  # how to authenticate a user
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /path/to/users/file

  # For any operations other than these, require an authenticated user.
  <LimitExcept GET PROPFIND OPTIONS REPORT>
    Require valid-user
  </LimitExcept>
</Location>

这里只举了几个简单例子。关于Apache访问控制和Require指令的更深入的信息，参见Apache文档的教程集http://httpd.apache.org/docs-2.0/misc/tutorials.htmlSecurity 中 Security一节。

基于目录的访问控制

也可以通过使用另一个Apache httpd 模块设置mod_authz_svn更细粒度的权限。这个模块截取从客户端传递到服务器的各种难懂的URL，让mod_dav_svn把它们解码，然后根据在配置文件中定义的访问策略可能会否决这些请求。

如果你是从源码来构建Subversion的，mod_authz_svn自动被构建并和mod_dav_svn一起安装。很多二进制分发版也自动安装了它。要验证是否正确安装了这个模块，请确认在httpd.conf文件中它跟在mod_dav_svn的LoadModule指令后：

LoadModule dav_module         modules/mod_dav.so
LoadModule dav_svn_module     modules/mod_dav_svn.so
LoadModule authz_svn_module   modules/mod_authz_svn.so

要激活这个模块，你需要配置你的Location块使用AuthzSVNAccessFile指令，它指定了一个包含对你资料库中路径的权限方针的文件。（很快，我们就会讨论这个文件的格式。）

Apache很灵活，因此你可选择三种常用的模式来配置你的块。我们先选择一种基本的配置模式。（下面的例子很简单；需要更多关于Apache授权和认证选项的详细信息，请查看Apache本身的文档。）

最简单的块是对所有人开放访问权。在这种场景下，Apache不发出认证要求，因此所有用户被认为是“匿名的anonymous”。

例 6.1. 匿名访问的一个配置范例。

            <Location /repos>
              DAV svn
              SVNParentPath /usr/local/svn

              # our access control policy
              AuthzSVNAccessFile /path/to/access/file                 
            </Location>

在另一个过度焦虑的极端，你可以配置你的块来对每个人要求认证。所有客户端必须提供认证信息来表明自己的身份。你的块通过 Require valid-user指令来无条件的要求认证，并定义认证的方式。

例 6.2. 认证访问的一个配置范例。

            <Location /repos>
              DAV svn
              SVNParentPath /usr/local/svn
            
              # our access control policy
              AuthzSVNAccessFile /path/to/access/file                 
            
              # only authenticated users may access the repository
              Require valid-user
            
              # how to authenticate a user
              AuthType Basic
              AuthName "Subversion repository"
              AuthUserFile /path/to/users/file                  
            </Location>

第三种非常普遍的模式是认证和匿名访问的组合。例如，许多管理员想允许匿名用户读资料库的某些部分，但只允许认证的用户读（或写）更敏感的区域。在这种设置下，所有用户开始都能匿名访问资料库。如果你的访问控制策略在某时需要真实的用户名，Apache会要求来自客户端的认证。要做到这样，你要配合使用 Satisfy Any和Require valid-user指令。

例 6.3. 混合认证/匿名访问的一个配置范例。

            <Location /repos>
              DAV svn
              SVNParentPath /usr/local/svn
            
              # our access control policy
              AuthzSVNAccessFile /path/to/access/file                 
            
              # try anonymous access first, resort to real 
              # authentication if necessary.
              Satisfy Any
              Require valid-user
            
              # how to authenticate a user
              AuthType Basic
              AuthName "Subversion repository"
              AuthUserFile /path/to/users/file                  
            </Location>

只要你的基本Location块配置好后，你就可以创建访问文件（access file）并在其中定义一些认证规则。

访问文件的语法和svnserve.conf文件以及运行时配置文件使用相同的、我们熟悉的语法。以#符号开头的行被忽略。最简单的形式是段名指定了一个资料库和在它里面的路径，认证的用户名是节内的选项名。每个选项的值描述了用户访问资料库路径的水平：r （只读）或者 rw（读写）。如果根本没有提到这个用户，那么任何访问都不允许。

更明确一点，段名是[repos-name:path]或者[path]这样的形式。如果你使用了 SVNParentPath指令，那么在你的小节里指定资料库名字很重要。如果你遗漏了它们，那么像[/some/dir]这样的段将匹配每个资料库里的/some/dir路径。然而如果你用了SVNPath指令，那么只定义在你段中的路径就没问题——毕竟，只有一个资料库。

[calc:/branches/calc/bug-142]
harry = rw
sally = r

在第一个例子里，用户harry对calc资料库里的/branches/calc/bug-142目录有完全的读写访问权，而用户sally只有只读的访问权。任何别的用户都被禁止访问这个目录。

当然，权限是从父目录到子目录继承的。这意味着我们可以指定某个子目录给Sarry不同的访问策略：

[calc:/branches/calc/bug-142]
harry = rw
sally = r

# give sally write access only to the 'testing' subdir
[calc:/branches/calc/bug-142/testing]
sally = rw

现在 Sally 可以写入这个分支的testing子目录，但是只能读其他的部分。同时Harry仍然可以对整个分支有完全的读写访问权。

也可以通过设置用户变量名为空来明确的拒绝某人的访问：

[calc:/branches/calc/bug-142]
harry = rw
sally = r

[calc:/branches/calc/bug-142/secret]
harry =

在这个例子里，Harry有整个bug-142树的读写权限，但是对其中的secret子目录完全没有访问权。

要记住的是最明确的路径最先匹配。mod_authz_svn模块尝试匹配路径本身，然后是路径的父目录，然后是再上一级的父目录等等。最终的效果是在访问文件中提到的特定路径总是覆盖从父目录继承来的权限。

缺省情况下，任何人对资料库都没有访问权。这意味着如果以一个空文件开始，那么你至少要给所有用户对资料库根目录的读权限。你可以通过*号变量来这么做，它表示“所有用户”：

[/]
* = r

这是一个常见的设置；注意在段名里没有提到任何资料库名。这使得所有用户可以读所有资料库，不管你用SVNPath 还是SVNParentPath。当所有用户对资料库有了读权限，你可以给某些用户在特定资料库里特定的子目录上明确的rw权限。

星号变量（*）特别值得一提：它是唯一匹配匿名用户的模式。如果你已经把你的Location块配置为允许匿名和认证混合的的访问，那么所有用户都从匿名开始访问Apache。mod_authz_svn查找被访问的路径是否有*值；如果没法找到，Apache将要求客户端的真正认证。

访问文件也允许你定义用户组，很像Unix的/etc/group文件：

[groups]
calc-developers = harry, sally, joe
paint-developers = frank, sally, jane
everyone = harry, sally, joe, frank, sally, jane

组可以像用户一样来授予访问权。用@符号标明它是一个组：

[calc:/projects/calc]
@calc-developers = rw

[paint:/projects/paint]
@paint-developers = rw
jane = r

...到这里关于这个我们已经说得够多的了。

特别奉献

我们已经覆盖了Apache和mod_dav_svn的大部分认证和授权选项。但是这里还有几个Apache提供的其他的好特性。

资料库浏览

为你的Subversion资料库配置Apache/WebDAV的最有用的好处是你的最新的版本化文件和目录立即可以通过常规的Web浏览器来查看。因为Subversion使用URL来标识版本化资源，那些基于HTTP的资料库访问的URL可以直接被敲入Web浏览器中。你的浏览器会对这个URL发起一个GET，根据URL代表的是一个版本化目录还是文件，mod_dav_svn 将回应目录列表或文件内容。

由于URL不包含你想看资源的哪个版本的信息，mod_dav_svn总是回应以最新的版本。这个功能有个非常好的副作用，你可以把Subversion的URL作为到文档的引用传给你的同伴，这些URL将始终指向最新的文档。当然，你也可以在其他web网站把这些URL作为超链接使用。

通常你会更多的使用指向版本化文件的URL——毕竟，哪儿才有你感兴趣的内容。但是你偶尔也可能要浏览Subversoin目录列表，在那儿你很快会注意到生成的显示列表的HTML非常基本，完全没有打算引起审美快感（甚至是兴趣）。要启用对目录显示的定制，Subversoin提供了一个XML索引功能。在httpd.conf文件中关于你资料库的Location块里使用一个SVNIndexXSLT指令将指示mod_dav_svn 在显示目录列表的时候生成XML输出，并且参照你选择的XSLT样式表：

<Location /svn>
  DAV svn
  SVNParentPath /usr/local/svn
  SVNIndexXSLT "/svnindex.xsl"
  …
</Location>

使用SVNIndexXSLT指令和有创意的XSLT样式表，你可以使你的目录列表和你的网站其他部分使用的配色方案和意象相符合。或者，如果你愿意，你可以用Subversion源代码分发版tools/xslt/目录中提供的例子样式表。记住SVNIndexXSLT所指定的目录路径实际上是一个URL路径——浏览器需要能读你的样式表以便能使用它们！

我可以浏览旧的修订版么？

用一个普通的web浏览器？一句话：不行。至少，只使用mod_dav_svn工具是不行的。

你的web浏览器只能使用普通的HTTP协议。这意味着它只知道如何GET公开的URL，这些URL代表文件和目录的最新版本。根据WebDAV/DeltaV规范，每个服务器为资源的旧版本定义了一个私有的URL语法，这个语法对客户是不透明的。要找到一个文件的旧版本，客户端必须遵循一个特定的过程来“发现”正确的URL；这个过程涉及发起一系列WebDAV PROPFIND请求并理解DeltaV 的概念。这些你的web浏览器无法做到。

要回答这个问题，一个明显可以用来查看文件和目录的旧版本的方法是传递--revision参数给svn list 和 svn cat。不过，要用你的web浏览器浏览旧的修订版，你可以使用第三方软件。一个好的例子是ViewCVS （http://viewcvs.sourceforge.net/）。ViewCVS开始是写来用于通过web来显示CVS资料库，现在最新的版本（还在开发中）也能理解Subversion资料库了。

其他特性

Apache作为一个稳定的Web服务器，已经提供了一些特性，它们也可以被用来增加Subversion的功能性和安全性。Subversion使用Neon和Apache通信，它是一个通用的HTTP/WebDAV库，带有像SSL（Secure Socket Layer，前面讨论过）和Deflate 压缩（和gzip以及 PKZIP程序用相同的算法把文件“缩紧”成较小的数据块）这样的功能。你只要把你需要的特性支持编译进Subversion和Apache，并正确的配置使用这些特性的程序。

Deflate压缩给客户端和服务器增加了一点负担，他们要压缩和解压网络传送数据来最小化实际的网络流量。在网络带宽紧张的情况下，这种压缩可以大幅度提高服务器和客户端之间的传输速度。在极端情况下，最小化网络流量对操作超时还是能成功完成起决定作用。

Apache和Subversion联合的其他功能没这么有趣，但同样有用，比如指定自定义的端口（不用缺省的HTTP 端口80 ）或虚拟域名，可通过它访问Subversion资料库，或通过代理访问资料库的能力。这些特性都被Neon支持，所以Subversion免费得到了这些支持。

最后，因为mod_dav_svn说得是WebDAV/DeltaV的半完成状态的方言，所以可以通过第三方DAV客户端访问资料库。大部分现代操作系统（Win32，OS X，和Linux）有内建的把DAV服务器作为一个标准网络“共享”来挂接（mount）的功能。这是个复杂的话题；要详细了解，请读???。

^[21]他们很不乐意这样做。

^[22] 虽然自签名服务器证书对于“中间人man in the middle”攻击仍然是脆弱的，但比起嗅探未保护的密码来，这种攻击对偶然的目击者来说实现起来还是要困难的多。

^[23] 比较关心安全问题的人可能不想把客户认证密码保存在运行时servers文件里。

上一页	上一级	下一页
svnserve，定制的服务器	起始页	支持多种资料库访问方式