首先用“记事本”程序打开“httpd.conf”配置文件
。此文件存放在Apache
服务器安装路径下的“conf”文件夹内
。 一、使用mod_vhost_alias
1.简单的动态虚拟主机
(1)从Host:头中取得
服务器名字ServerName
UseCanonicalNameOff
(2)这里的日志格式
,可以在将来通过第一个参数域来分隔不同的虚拟主机的日志
LogFormat"%V%h%l%u%t"%r"%s%b"VCommon
CustomLoglogs/Access_logvcommon
(3)在返回请求的文件名的路径中包含进服务器名字:servername
VirtualDocumentRoot/www/hosts/%0/docs
VirtualScriptAlias/www/hosts/%0/CGI-bin
2.更为有效的基于IP地址的虚拟主机
(1)从IP地址反解析得到服务器名字(servername)
UseCanonicalNameDNS
(2)在日志中包含IP地址
,便于后续分发
LogFormat"%A%h%l%u%t"%r"%s%b"vcommon
CustomLoglogs/access_logvcommon
(3)在文件路径中包含IP地址
VirtualDocumentRootIP/www/hosts/%0/docs
VirtualScriptAliasIP/www/hosts/%0/
cgi-bin
二、使用mod_rewrite
1.使用mod_rewrite实现简单的动态虚拟主机
(1)从Host:头获取服务器名字
UseCanonicalNameOff
(2)可分割的日志
LogFormat"%{Host}i%h%l%u%t"%r"%s%b"vcommon
CustomLoglogs/access_logvcommon
<Directory/www/hosts>
ExecCGIisneededherebecausewecan'tforce
CGIexecutioninthewaythatScriptAliasdoes
OptionsFollowSymLinksExecCGI
</Directory>
(3)接下来是关键部分
RewriteEngineOn
aServerNamederivedfromaHost:headermaybeanycaseatallRewriteMaplowercaseint:tolower
首先处理普通文档:
允许变名/icons/起作用-其他变名类同
RewriteCond%{REQUEST_URI}!^/icons/
允许CGIS
RewriteCond%{REQUEST_URI}!^/
cgi-bin/
开始“变戏法”
RewriteRule^/(.*)$/www/hosts/${lowercase:%{SERVER_NAME}}/docs/$1
现在处理CGIs-我们需要强制使用一个MIME类型
RewriteCond%{REQUEST_URI}^/cgi-bin/
RewriteRule^/(.*)$/www/hosts/${lowercase:%{SERVER_NAME}}/cgi-bin/$1[T=application/x-httpd-cgi]
2.使用独立的虚拟主机配置文件vhost.map
(1)vhost.map文件包含了类似下面的内容:
www.customer-1.com/www/customers/1 www.customer-2.com/www/customers/2 ...
www.customer-N.com/www/customers/N (2)http.conf包含了:
RewriteEngineon
RewriteMaplowercaseint:tolower
(3)定义映像文件
RewriteMapvhosttxt:/www/conf/vhost.map
(4)和上面的例子一样,处理变名
RewriteCond%{REQUEST_URI}!^/icons/
RewriteCond%{REQUEST_URI}!^/cgi-bin/
RewriteCond${lowercase:%{SERVER_NAME}}^(.+)$
(5)这里做基于文件的重新映射
RewriteCond${vhost:%1}^(/.*)$
RewriteRule^/(.*)$%1/docs/$1
RewriteCond%{REQUEST_URI}^/cgi-bin/
RewriteCond${lowercase:%{SERVER_NAME}}^(.+)$
RewriteCond${vhost:%1}^(/.*)$
RewriteRule^/(.*)$%1/cgi-bin/$1
.htaccess文件功能
.htaccess文件的功能:"分布式配置文件"提供了针对目录改变配置的方法,即:在一个特定的文档目录中放置一个包含一个或多个指令的文件,以作用于此目录及其所有子目录。作为用户,所能使用的命令受到限制。管理员可以通过Apache的AllowOverride指令来设置.子目录中的指令会覆盖更高级目录或者主服务器配置文件中的指令。
一、错误文档的定位
(1)常用的客户端请求错误返回代码:
401AuthorizationRequired
403Forbidden
404NotFound
405MethodNotAllowed
408RequestTimedOut
411ContentLengthRequired
412PreconditionFailed
413RequestEntityTooLong
414RequestURITooLong
415UnsupportedMediaType
(2)常见的服务器错误返回代码:
500InternalServerError
(3)用户可以利用.htaccess指定自己事先制作好的错误提醒页面。一般情况下,人们可以专门设立一个目录,例如errors放置这些页面。然后再.htaccess中,加入如下的指令:
ErrorDocument404/errors/notfound.html
ErrorDocument500/errors/internalerror.html
一条指令一行。
上述第一条指令的意思是对于404,也就是没有找到所需要的文档的时候得显示页面为/errors目录下的notfound.html页面。不难看出语法格式为:
ErrorDocument错误代码/目录名/文件名.扩展名
如果所需要提示的信息很少的话,不必专门制作页面,直接在指令中使用HTML号了,例如下面这个例子:
ErrorDocument401"<bodybgcolor=#ffffff>
你没有权限访问该页面!
</body>"
二、文档访问的密码保护要利用.htaccess对某个目录下的文档设定访问用户和对应的密码,首先要做的是生成一个.htpasswd的文本文档,例如:
zheng:y4E7Ep8e7EYV
这里密码经过加密,用户可以自己找些工具将密码加密成.htaccess支持的编码。该文档最好不要放在www目录下,建议放在www根目录文档之外,这样更为
安全些。
有了授权用户文档,可以在.htaccess中加入如下指令了:
AuthUserFile.htpasswd的服务器目录
AuthGroupFile/dev/null(需要授权访问的目录)
AuthNameEntERPassword
AuthTypeBasic(授权类型)
requireuserwsabstract(允许访问的用户,如果希望表中所有用户都允许,可以使用requirevalid-user)
注:括号部分为学习时候自己添加的注释
三、拒绝来自某个IP的访问
如果我不想某个政府部门访问到我的站点的内容,那可以通过.htaccess中加入该部门的IP而将它们拒绝在外。例如:
orderallow,deny
denyfrom210.21.112.43
denyfrom219.146.95
allowfromall
注:第二行拒绝某个IP,第三行拒绝某个IP段,也就是219.146.95.0~219.146.95.255想要拒绝所有人?用denyfromall好了。不止用IP,也可以用域名来设定。
四、保护.htaccess文档
在使用.htaccess来设置目录的密码保护时,它包含了密码文件的路径。从
安全考虑,有必要把.htaccess也保护起来,不让别人看到其中的内容。虽然可以用其他方式做到这点,比如文档的权限。不过,.htaccess本身也能做到,只需加入如下的指令:
<Files.htaccess>
orderallow,deny
denyfromall
</Files>
五、URL转向
我们可能对网站进行重新规划,将文档进行了迁移,或者更改了目录。这时候,来自
搜索引擎或者其他网站链接过来的访问就可能出错。这种情况下,可以通过如下指令来完成旧的URL自动转向到新的地址:
Redirect/旧目录/旧文档名新文档的地址
或者整个目录的转向:
Redirect旧目录新目录
改变缺省的首页文件
一般情况下缺省的首页文件名有default、index等。不过,有些时候目录中没有缺省文件,而是某个特定的文件名,比如在pmwiki中是pmwiki.php。这种情况下,要用户记住文件名来访问很麻烦。在.htaccess中可以轻易的设置新的缺省文件名:
DirectoryIndex新的缺省文件名
也可以列出多个,顺序表明它们之间的优先级别,
例如:
DirectoryIndexfilename.htmlindex.cgiindex.pldefault.htm
rewrite重写功能
Apache模块mod_rewrite,一个基于一定规则的实时重写URL请求的引擎此模块提供了一个基于正则表达式分析器的重写引擎来实时重写URL请求。它支持每个完整规则可以拥有不限数量的子规则以及附加条件规则的灵活而且强大的URL操作机制。此URL操作可以依赖于各种测试,比如服务器变量、环境变量、HTTP头、时间标记,甚至各种格式的用于匹配URL组成部分的查找数据库。此模块可以操作URL的所有部分(包括路径信息部分),在服务器级的(httpd.conf)和目录级的(.htaccess)配置都有效,还可以生成最终请求字符串。此重写操作的结果可以是内部子处理,也可以是外部请求的转向,甚至还可以是内部代理处理。但是,所有这些功能和灵活性带来一个问题,那就是复杂性,因此,不要指望一天之内就能看懂整个模块。更多的讨论、细节、示例,请查看详细的URL重写文档。
(1)特殊字符的引用:
在Apache1.3.20中,TestString和Substitution中的特殊字符可以用前导斜杠()来实现转义(即忽略其特殊含义而视
之为普通字符)。比如,Substitution可以用"\___FCKpd___27quot;来包含一个美元符号,以避免mod_rewrite把它视为反向引用。
(2)环境变量
此模块会跟踪两个额外的(非标准)CGI/SSI环境变量,SCRIPT_URL和SCRIPT_URI。他们包含了当前资源的逻辑网络视图,而标准CGI/SSI变量SCRIPT_NAME和SCRIPT_FILENAME包含的是物理系统视图。注意:这些变量保持的是其最初被请求时的URI/URL,即在任何重写操作之前的URI/URL。其重要性在于他们是重写操作重写URL到物理路径名的原始依据。
示例:
SCRIPT_NAME=/sw/lib/w3s/tree/global/u/rse/.www/index.html
SCRIPT_FILENAME=/u/rse/.www/index.html
SCRIPT_URL=/u/rse/
SCRIPT_URI=http://en1.engelschall.com/u/rse/
(3)rewrite的指令
rewrite的指令有很多比如RewriteBase指令
RewriteBase指令显式地设置了目录级重写的基准URL。在下文中,你将看到RewriteRule可以用于目录级的配置文件中(.htaccess)并在局部范围内起作用,即规则实际处理的只是剥离了本地路径前缀的一部分。处理结束后,这个路径会被自动地附着回去。默认值是"RewriteBasephysical-directory-path"。
在对一个新的URL进行替换时,此模块必须把这个URL重新注入到服务器处理中。为此,它必须知道其对应的URL前缀或者说URL基准。通常,此前缀就是对应的文件路径。但是,大多数网站URL不是直接对应于其物理文件路径的,因而一般不能做这样的假定!所以在这种情况下,就必须用RewriteBase指令来指定正确的URL前缀。
如果你的网站服务器URL不是与物理文件路径直接对应的,而又需要使用RewriteBase指令,则必须在每个对应的.htaccess文件中指定RewriteRule。
例如,目录级配置文件内容如下:
/abc/def/.htaccess--/abc/def目录的配置文件
注意:/abc/def是/xyz的物理路径(例如存在一条'Alias/xyz/abc/def'指令)。
RewriteEngineOn
让服务器知道我们使用的是/xyz而不是物理路径/abc/def
RewriteBase/xyz
重写规则
RewriteRule^oldstuff.html$newstuff.html
注:上述例子中,对/xyz/oldstuff.html的请求被正确地重写为对物理文件/abc/def/newstuff.html的请求。
以下列出了内部处理的详细步骤:
请求:
/xyz/oldstuff.html
内部处理过程:
/xyz/oldstuff.html->/abc/def/oldstuff.html(per-serverAlias)
/abc/def/oldstuff.html->/abc/def/newstuff.html(per-dirRewriteRule)
/abc/def/newstuff.html->/xyz/newstuff.html(per-dirRewriteBase)
/xyz/newstuff.html->/abc/def/newstuff.html(per-serverAlias)
结果:
/abc/def/newstuff.html
虽然这个过程看来很繁复,但是由于目录级重写的到来时机已经太晚了,它不得不把这个(重写)请求重新注入到Apache核心中,所以Apache内部确实是这样处理的。但是:它的开销并不象看起来的那样大,因为重新注入完全在Apache服务器内部进行,而且这样的过程在Apache内部也为其他许多操作所使用。所以,你可以充分信任其设计和实现是正确的。