Apache的ReWrite的应用.docVIP

Apache的ReWrite的应用 Apache的mod_rewrite是提供了强大URL操作的杀手级的模块，可以实现几乎所有你梦想的URL操作类型，其代价是你必须接受其复杂性，因为mod_rewrite的主要障碍就是初学者不容易理解和运用，即使是Apache专家有时也会发掘出mod_rewrite的新用途。 换句话说：对mod_rewrite，或者是打退堂鼓永不再用，或者是喜欢它并一生受用。 ReWrite?可以应用在以下方面或者解决以下问题： URL的规划 规范的URL 说明: 在有些网站服务器上，一个资源会拥有多个URL，在实际应用和发布中应该被使用的是规范的URL，其他的则是简写或者是内部使用的。无论用户在请求中使用什么形式的URL，他最终看见的都应该是规范的URL。 方案: 对所有的不规范的URL执行一个外部的HTTP重定向，以改变它在浏览器地址栏中的显示及其后继的请求。下例中的规则集用规范的/u/user替换/~user，并修正了/u/user所遗漏的后缀的斜杠。 代码: RewriteRule? ^/~([^/]+)/?(.*) /u/$1/$2 [R] RewriteRule? ^/([uge])/([^/]+)$ /$1/$2/ [R] 规范的主机名 说明: ... 方案: 代码: RewriteCond? %{HTTP_HOST} !^fully\.qualified\.domain\.name [NC] RewriteCond? %{HTTP_HOST} !^$ RewriteCond? %{SERVER_PORT} !^80$ RewriteRule? ^/(.*) :%{SERVER_PORT}/$1 [L,R] RewriteCond? %{HTTP_HOST} !^fully\.qualified\.domain\.name [NC] RewriteCond? %{HTTP_HOST} !^$ RewriteRule? ^/(.*) /$1 [L,R] 被移动过的DocumentRoot 说明: 通常，网站服务器的DocumentRoot直接对应于URL/，但是，它常常不是处于最高一级，而可能只是众多数据池中的一个实体。比如，在Intranet站点中，有/e/www/(WWW的主页)、/e/sww/ (Intranet的主页)等等，而DocumentRoot指向了/e/www/，则必须保证此数据池中的所有内嵌的图片和其他元素对后继请求有效。 方案: 只须重定向URL /到/e/www/即可。这个方案看起来很简单，但只是有了mod_rewrite模块的支持，它才简单，因为传统的URL Aliases机制(由mod_alias及其相关模块提供)只是作了一个前缀匹配，DocumentRoot是一个对所有URL的前缀，因而无法实现这样的重定向。而用mod_rewrite的确很简单: 代码: RewriteEngine? on RewriteRule? ^/$ /e/www/ [R] 后缀斜杠的问题 说明: 每个网管对引用目录后缀斜杠的问题都有一本苦经，如果遗漏了，服务器会产生一个错误，因为如果请求是/~quux/foo而不是/~quux/foo/，服务器会去找一个叫foo的文件，而它是一个目录，所以就报错了。事实上，大多数情况下，它自己会试图修正这个错误，但是有时候需要你手工纠正，比如，在重写了许多CGI脚本中的复杂的URL以后。 方案: 解决这个微妙问题的方案是让服务器自动添加后缀的斜杠。对此，必须使用一个外部的重定向，使浏览器正确地处理后继的对诸如图片的请求。如果仅仅作一个内部的重写，可能只对目录页面有效，而对内嵌有使用相对URL的图片的页面则无效，因为浏览器有请求内嵌目标的可能。比如，如果不用外部重定向，/~quux/foo/index.html页面中对image.gif的请求，其结果将是/~quux/image.gif！。 所以，应该这样写： 代码: RewriteEngine? on RewriteBase? /~quux/ RewriteRule? ^foo$ foo/ [R] 又懒又疯狂的做法是把这些写入其宿主目录中的顶级.htaccess中，但是须注意，如此会带来一些处理上的开销。 代码: RewriteEngine? on RewriteBase? /~quux/ RewriteCond? %{REQUEST_FILENAME} -d RewriteRule? ^(.+[^/])$ $1/ [R] 集群网站的同类URL规划 说明: 我们希望在一个Intranet集群网站中，对所有WWW服务器建立一个同类的一致性的URL