URL重写技术.docx_第1页
URL重写技术.docx_第2页
URL重写技术.docx_第3页
URL重写技术.docx_第4页
URL重写技术.docx_第5页
已阅读5页,还剩22页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

URL重写技术本文是mod_rewrite的参考文档,阐述在实际应用中如何解决网管所面临的基于URL的典型问题,并详细描述如何配置URL重写规则集以解决问题。rewritemapApache的mod_rewrite是提供了强大URL操作的杀手级的模块,可以实现几乎所有你梦想的URL操作类型,其代价是你必须接受其复杂性,因为mod_rewrite的主要障碍就是初学者不容易理解和运用,即使是Apache专家有时也会发掘出mod_rewrite的新用途。换句话说:对mod_rewrite,或者是打退堂鼓永不再用,或者是喜欢它并一生受用。本文试图通过对已有方案的表述来创造一个成功的开端,以免你放弃。实践方案我自己创造和收集了许多实践方案,不要有畏惧心理,从这些例子开始学习URL重写的黑匣子吧。URL的规划规范的URL说明: 在有些网站服务器上,一个资源会拥有多个URL,在实际应用和发布中应该被使用的是规范的URL,其他的则是简写或者是内部使用的。无论用户在请求中使用什么形式的URL,他最终看见的都应该是规范的URL。方案: 对所有的不规范的URL执行一个外部的HTTP重定向,以改变它在浏览器地址栏中的显示及其后继的请求。下例中的规则集用规范的/u/user替换/user,并修正了/u/user所遗漏的后缀的斜杠。RewriteRule /(/+)/?(.*) /u/$1/$2 RRewriteRule /(uge)/(/+)$ /$1/$2/ R规范的主机名说明: . 方案: RewriteCond %HTTP_HOST ! NCRewriteCond %HTTP_HOST !$RewriteCond %SERVER_PORT !80$RewriteRule /(.*) /.name:%SERVER_PORT/$1 L,RRewriteCond %HTTP_HOST ! NCRewriteCond %HTTP_HOST !$RewriteRule /(.*) /.name/$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 onRewriteRule /$ /e/www/ R后缀斜杠的问题说明: 每个网管对引用目录后缀斜杠的问题都有一本苦经,如果遗漏了,服务器会产生一个错误,因为如果请求是/quux/foo而不是/quux/foo/,服务器会去找一个叫foo的文件,而它是一个目录,所以就报错了。事实上,大多数情况下,它自己会试图修正这个错误,但是有时候需要你手工纠正,比如,在重写了许多CGI脚本中的复杂的URL以后。方案: 解决这个微妙问题的方案是让服务器自动添加后缀的斜杠。对此,必须使用一个外部的重定向,使浏览器正确地处理后继的对诸如图片的请求。如果仅仅作一个内部的重写,可能只对目录页面有效,而对内嵌有使用相对URL的图片的页面则无效,因为浏览器有请求内嵌目标的可能。比如,如果不用外部重定向,/quux/foo/index.html页面中对image.gif的请求,其结果将是/quux/image.gif!。所以,应该这样写:RewriteEngine onRewriteBase /quux/RewriteRule foo$ foo/ R又懒又疯狂的做法是把这些写入其宿主目录中的顶级.htaccess中,但是须注意,如此会带来一些处理上的开销。RewriteEngine onRewriteBase /quux/RewriteCond %REQUEST_FILENAME -dRewriteRule (.+/)$ $1/ R集群网站的同类URL规划说明: 我们希望在一个Intranet集群网站中,对所有WWW服务器建立一个同类的一致性的URL规划,也就是,所有的URL(对单个服务器来说,是本地的依赖于此服务器的!)是独立于服务器的!我们需要的是一个具有独立于服务器的一致性规划的WWW名称空间,即,URL不需要包含正确的物理的目标服务器,而由集群本身来自动定位物理的目标主机。方案: 首先,目标服务器的信息来自(产生)于包含有用户、组以及实体的外部地图,其格式形如:user1 server_of_user1user2 server_of_user2: :这些信息被存入map.xxx-to-host文件。其次,如果URL在一个服务器上无效,需要引导所有的服务器重定向URL/u/user/anypath/g/group/anypath/e/entity/anypath到http:/physical-host/u/user/anypathhttp:/physical-host/g/group/anypathhttp:/physical-host/e/entity/anypath以下规则集依靠地图文件来完成这个操作(假定,如果一个用户在地图中没有对应的项,则使用server0为默认服务器):RewriteEngine onRewriteMap user-to-host txt:/path/to/map.user-to-hostRewriteMap group-to-host txt:/path/to/map.group-to-hostRewriteMap entity-to-host txt:/path/to/map.entity-to-hostRewriteRule /u/(/+)/?(.*) http:/$user-to-host:$1|server0/u/$1/$2RewriteRule /g/(/+)/?(.*) http:/$group-to-host:$1|server0/g/$1/$2RewriteRule /e/(/+)/?(.*) http:/$entity-to-host:$1|server0/e/$1/$2RewriteRule /(uge)/(/+)/?$ /$1/$2/.www/RewriteRule /(uge)/(/+)/(.+.+) /$1/$2/.www/$3移动宿主目录到不同的网站服务器说明: 通常,许多网管在建立一个新的网站服务器时,都会有这样的要求:重定向一个网站服务器上的所有宿主目录到另一个网站服务器。方案: 很简单,用mod_rewrite。在老的网站服务器上重定向所有的URL /user/anypath到http:/newserver/user/anypath。RewriteEngine onRewriteRule /(.+) http:/newserver/$1 R,L结构化的宿主目录说明: 一些拥有几千个用户的网站通常都使用结构化的宿主目录规划,即,每个宿主目录位于一个带有特定前缀比如其用户名的第一个字符的子目录下。那么,/foo/anypath代表/home/f/foo/.www/anypath,而/bar/anypath代表/home/b/bar/.www/anypath。方案: 可以使用下列规则集来扩展以达到上述目的。RewriteEngine onRewriteRule /(a-z)a-z0-9+)(.*) /home/$2/$1/.www$3文件系统的重组说明: 这是一个不加雕琢的例子:一个大量使用针对目录的规则集以实现平滑观感,而从来不用调整数据结构的杀手级的应用。背景:net.sw从1992年开始,存放了我收集的免费的有效的Unix软件包。它是我的爱好也是我的工作,因为在学习计算机科学的同时,业余时间还做了多年的系统和网络的管理员。每周我都需要整理软件,因而建立了一个层次很深的目录结构来存放各种软件包:drwxrwxr-x 2 netsw users 512 Aug 3 18:39 Audio/drwxrwxr-x 2 netsw users 512 Jul 9 14:37 Benchmark/drwxrwxr-x 12 netsw users 512 Jul 9 00:34 Crypto/drwxrwxr-x 5 netsw users 512 Jul 9 00:41 Database/drwxrwxr-x 4 netsw users 512 Jul 30 19:25 Dicts/drwxrwxr-x 10 netsw users 512 Jul 9 01:54 Graphic/drwxrwxr-x 5 netsw users 512 Jul 9 01:58 Hackers/drwxrwxr-x 8 netsw users 512 Jul 9 03:19 InfoSys/drwxrwxr-x 3 netsw users 512 Jul 9 03:21 Math/drwxrwxr-x 3 netsw users 512 Jul 9 03:24 Misc/drwxrwxr-x 9 netsw users 512 Aug 1 16:33 Network/drwxrwxr-x 2 netsw users 512 Jul 9 05:53 Office/drwxrwxr-x 7 netsw users 512 Jul 9 09:24 SoftEng/drwxrwxr-x 7 netsw users 512 Jul 9 12:17 System/drwxrwxr-x 12 netsw users 512 Aug 3 20:15 Typesetting/drwxrwxr-x 10 netsw users 512 Jul 9 14:08 X11/1996年7月,我决定通过一个漂亮的Web接口公开我的收藏。“漂亮”是指提供一个接口以直接浏览整个目录结构,同时不对这个结构做任何改变 - 甚至也不在结构顶部放置CGI脚本。为什么呢?因为这个结构还要能够被FTP访问,而且我不希望其中有任何Web或者CGI的成分。方案: 这个方案分为两个部分:第一个部分,是用于在空闲时间建立所有目录页面的CGI脚本集。我把它们放在/e/netsw/.www/,如下:-rw-r-r- 1 netsw users 1318 Aug 1 18:10 .wwwacldrwxr-xr-x 18 netsw users 512 Aug 5 15:51 DATA/-rw-rw-rw- 1 netsw users 372982 Aug 5 16:35 LOGFILE-rw-r-r- 1 netsw users 659 Aug 4 09:27 TODO-rw-r-r- 1 netsw users 5697 Aug 1 18:01 netsw-about.html-rwxr-xr-x 1 netsw users 579 Aug 2 10:33 netsw-access.pl-rwxr-xr-x 1 netsw users 1532 Aug 1 17:35 netsw-changes.cgi-rwxr-xr-x 1 netsw users 2866 Aug 5 14:49 netsw-home.cgidrwxr-xr-x 2 netsw users 512 Jul 8 23:47 netsw-img/-rwxr-xr-x 1 netsw users 24050 Aug 5 15:49 netsw-lsdir.cgi-rwxr-xr-x 1 netsw users 1589 Aug 3 18:43 netsw-search.cgi-rwxr-xr-x 1 netsw users 1885 Aug 1 17:41 netsw-tree.cgi-rw-r-r- 1 netsw users 234 Jul 30 16:35 netsw-unlimit.lst其中的DATA/子目录包含了上述目录结构,即实在的net.sw,由rdist在需要的时候自动更新。第二个部分的遗留问题是:如何连接这两个结构为一个平滑观感的URL树?我希望在运行适当的CGI脚本而使用各种URL的时候,使用户感觉不到DATA/目录的存在。方案如下:首先,我把下列配置放在服务器上DocumentRoot中的针对目录的配置文件里,以重写公布的URL /net.sw/ 为内部路径 /e/netsw:RewriteRule net.sw$ net.sw/ RRewriteRule net.sw/(.*)$ e/netsw/$1第一条规则是针对遗漏后缀斜杠的请求的!第二条规则才是真正实现功能的。接着,就是放在针对目录的配置文件/e/netsw/.www/.wwwacl中的杀手级的配置了:Options ExecCGI FollowSymLinks Includes MultiViewsRewriteEngine on# we are reached via /net.sw/ prefixRewriteBase /net.sw/# first we rewrite the root dir to# the handling cgi scriptRewriteRule $ netsw-home.cgi LRewriteRule index.html$ netsw-home.cgi L# strip out the subdirs when# the browser requests us from perdir pagesRewriteRule .+/(netsw-/+/.+)$ $1 L# and now break the rewriting for local filesRewriteRule netsw-home.cgi.* - LRewriteRule netsw-changes.cgi.* - LRewriteRule netsw-search.cgi.* - LRewriteRule netsw-tree.cgi$ - LRewriteRule netsw-about.html$ - LRewriteRule netsw-img/.*$ - L# anything else is a subdir which gets handled# by another cgi scriptRewriteRule !netsw-lsdir.cgi.* - CRewriteRule (.*) netsw-lsdir.cgi/$1阅读提示:注意前半部分中的标志L(最后),和无对应项(-) 注意后半部分中的符号!(非),和标志C (链) 注意最后一条规则的全匹配模式 NCSA imagemap和Apache mod_imap说明: 许多人都希望在从NCSA网站服务器向较现代的Apache网站服务器转移中实现平滑过渡,即希望老的NCSA imagemap程序能在Apache的较现代的mod_imap支持下正常运作。但问题在于,到处都是通过/cgi-bin/imagemap/path/to/page.map引用imagemap程序的连接,而在Apache下,应该写成/path/to/page.map。方案: 使用全局规则在空闲时间去除所有这些请求的前缀:RewriteEngine onRewriteRule /cgi-bin/imagemap(.*) $1 PT在多个目录中搜索页面说明: 有时会有必要使网站服务器在多个目录中搜索页面,对此,MultiViews或者其他技术无能为力。方案: 编制一个明确的规则集以搜索目录中的文件。RewriteEngine on# first try to find it in custom/.# .and if found stop and be happy:RewriteCond /your/docroot/dir1/%REQUEST_FILENAME -fRewriteRule (.+) /your/docroot/dir1/$1 L# second try to find it in pub/.# .and if found stop and be happy:RewriteCond /your/docroot/dir2/%REQUEST_FILENAME -fRewriteRule (.+) /your/docroot/dir2/$1 L# else go on for other Alias or ScriptAlias directives,# etc.RewriteRule (.+) - PT按照URL的片段设置环境变量说明: 如果希望保持请求之间的状态信息,但又不希望使用CGI来包装所有页面,而只通过分离URL中的有用信息来编码。方案: 可以用一个规则集来分离出状态信息,并设置环境变量以备此后用于XSSI或CGI。如此,一个/foo/S=java/bar/的URL会被解析为/foo/bar/,而环境变量STATUS则被设置为java。RewriteEngine onRewriteRule (.*)/S=(/+)/(.*) $1/$3 E=STATUS:$2虚拟用户主机说明: 如果需要为用户username支持一个的主页,但不是用在此机器上建虚拟主机的方法,而是用仅在此机器上增加一个DNS记录的方法实现。 方案: 对HTTP/1.0的请求,这是无法实现的;但是对HTTP/1.1的在HTTP头中包含有主机名的请求,可以用以下规则集来内部地重写/anypath为/home/username/anypath:RewriteEngine onRewriteCond %HTTP_HOST www.+.$RewriteRule (.+) %HTTP_HOST$1 CRewriteRule www.(.+).(.*) /home/$1$2为外来访问者重定向宿主目录说明: 对不是来自本地域的外来访问者的请求,重定向其宿主目录URL到另一个网站服务器,有时这种做法也会用在虚拟主机的上下文中。方案: 只须一个重写条件:RewriteEngine onRewriteCond %REMOTE_HOST !.+.$RewriteRule (/.+) /$1 R,L重定向失败的URL到其他网站服务器说明: 如何重写URL以重定向对网站服务器A的失败请求到服务器B,是一个常见的问题。一般,可以用Perl写的CGI脚本通过ErrorDocument来解决,此外,还有mod_rewrite方案。但是须注意,这种方法的执行效率不如用ErrorDocument的CGI脚本!方案: 第一种方案,有最好的性能而灵活性欠佳,出错概率小所以安全:RewriteEngine onRewriteCond /your/docroot/%REQUEST_FILENAME !-fRewriteRule (.+) http:/webserverB.dom/$1但是其问题在于,它只对位于DocumentRoot中的页面有效。虽然可以增加更多的条件(比如同时还处理宿主目录,等等),但是还有一个更好的方法:RewriteEngine onRewriteCond %REQUEST_URI !-URewriteRule (.+) http:/webserverB.dom/$1这种方法使用了mod_rewrite提供的“向前参照(look-ahead)”的功能,是一种对所有URL类型都有效而且安全的方法。但是,对网站服务器的性能会有影响,所以如果网站服务器有一个强大的CPU,那就用这个方法。而在慢速机器上,可以用第一种方法,或者用性能更好的ErrorDocument CGI脚本。扩展的重定向说明: 有时候,我们会需要更多的对重定向URL的(有关字符转义机制方面的)控制。通常,Apache内核中的URL转义函数uri_escape()同时还会对anchor转义,即,类似url#anchor的URL,因此,你不能用mod_rewrite对此类URL直接重定向。那么如何实现呢?方案: 必须用NPH-CGI脚本使它自己重定向,因为对NPH(non-parseable headers 无须解析的HTTP头)不会发生转义操作。首先,在针对服务器的配置中(应该位于所有重写规则的最后),引入一种新的URL类型xredirect::RewriteRule xredirect:(.+) /path/to/nph-xredirect.cgi/$1 T=application/x-httpd-cgi,L以强制所有带xredirect:前缀的URL被传送到如下的nph-xredirect.cgi程序:#!/path/to/perl# nph-xredirect.cgi - NPH/CGI script for extended redirects# Copyright (c) 1997 Ralf S. Engelschall, All Rights Reserved.#$| = 1;$url = $ENVPATH_INFO;print HTTP/1.0 302 Moved Temporarilyn;print Server: $ENVSERVER_SOFTWAREn;print Location: $urln;print Content-type: text/htmln;print n;print n;print n;print 302 Moved Temporarily (EXTENDED)n;print n;print n;print Moved Temporarily (EXTENDED)n;print The document has moved here.n;print n;print n;#EOF#这是一种可以重定向所有URL类型的方法,包括不被mod_rewrite直接支持的类型。所以,还可以这样重定向news:newsgroup:RewriteRule anyurl xredirect:news:newsgroup注意:无须对上述规则加R或R,L,因为xredirect:会在稍后被其特殊的传送规则扩展。文档访问的多路复用说明: 你知道/CPAN的CPAN(Comprehensive Perl Archive Network)吗?它实现了一个重定向以提供,全世界的CPAN镜像中离访问者最近的一个FTP站点,也可以称之为FTP访问多路复用服务。CPAN是通过CGI脚本实现的,那么用mod_rewrite如何实现呢?方案: 首先,我们注意到mod_rewrite从3.0.0版本开始,还可以重写ftp:类型。其次,对客户端顶级域名的路径最近的求取可以用RewriteMap实现。利用链式规则集,并用顶级域名作为查找多路复用地图的键,可以这样做:RewriteEngine onRewriteMap multiplex txt:/path/to/map.cxanRewriteRule /CxAN/(.*) %REMOTE_HOST:$1 CRewriteRule .+.(a-zA-Z+):(.*)$ $multiplex:$1|ftp.default.dom$2 R,L# map.cxan - Multiplexing Map for CxAN#de ftp:/ftp.cxan.de/CxAN/uk ftp:/ftp.cxan.uk/CxAN/com /CxAN/ :#EOF#依赖于时间的重写说明: 在页面内容依时间不同而变化的场合,比如重定向特定页面,许多网管仍然采用CGI脚本的方法,如何用mod_rewrite来实现呢?方案: 有许多类似TIME_xxx的变量可以用在重写条件中,利用STRING和=STRING的类型比较,并加以连接,就可以实现依赖于时间的重写:RewriteEngine onRewriteCond %TIME_HOUR%TIME_MIN 0700RewriteCond %TIME_HOUR%TIME_MIN 1024 - Host www2.quux-corp.dom Port 80DENY Host * Port * - Host www2.quux-corp.dom Port 80按你的实际配置,只要对上例稍作调整即可。接着,建立通过代理后台获取丢失数据的mod_rewrite规则:RewriteRule /(/+)/?(.*) /home/$1/.www/$2RewriteCond %REQUEST_FILENAME !-fRewriteCond %REQUEST_FILENAME !-dRewriteRule /home/(/+)/.www/?(.*) http:/www2.quux-corp.dom/$1/pub/$2 P负载的均衡说明: 如何均衡的负载到(一共是6个服务器)?方案: 这个问题有许多可能的解决方案,在此,我们讨论通称为“基于DNS(DNS-based)的”方案,和特殊的使用mod_rewrite的方案:DNS循环(DNS Round-Robin) 最简单的方法是用BIND的DNS循环特性,只要按惯例设置的DNS的A(地址)记录,如:www0 IN A www1 IN A www2 IN A www3 IN A www4 IN A www5 IN A 然后,增加以下各项:www IN CNAME . IN CNAME . IN CNAME . IN CNAME . IN CNAME . IN CNAME . IN CNAME .注意,上述看起来似乎是错误的,但事实上,它的确是BIND中的一个预期的特性,而且也可以这样用。无论如何,现在已经被解析,BIND可以给出www0-www6 - 虽然每次在次序上会有轻微的置换/循环,客户端的请求可以被分散到各个服务器。可是,这并不是一个优秀的负载均衡方案,因为,DNS解析信息可以被网络中其他名称服务器缓冲,而一旦被解析为wwwN.,则其后继请求都将被送往。但是最终结果是正确的,因为请求的总量的确被分散到各个服务器了DNS 负载均衡 一种成熟的基于DNS的负载均衡方法是使用/schemers/docs/lbnamed/lbnamed.html的lbnamed程序,它是一个Perl 5程序,带有若干辅助工具,实现了真正的基于DNS的负载均衡。代理吞吐循环(Proxy Throughput Round-Robin) 这是一个使用mod_rewrite及其代理吞吐特性的方法。首先,在DNS记录中,将固定为,如下:www IN CNAME .其次,将转换为一个专职代理服务器,即,由这个机器把所有到来的URL通过内部代理分散到另外5个服务器(www1-www5)。为此,必须建立一个规则集,对所有URL调用一个负载均衡脚本lb.pl。RewriteEngine onRewriteMap lb prg:/path/to/lb.plRewriteRule /(.+)$ $lb:$1 P,L以下是lb.pl:#!/path/to/perl# lb.pl - load balancing script#$| = 1;$name = www; # the hostname base$first = 1; # the first server (not 0 here, because 0 is myself)$last = 5; # the last server in the round-robin$domain = foo.dom; # the domainname$cnt = 0;while () $cnt = ($cnt+1) % ($last+1-$first); $server = sprintf(%s%d.%s, $name, $cnt+$first, $domain); print http:/$server/$_;#EOF#最后的说明:这样有用吗?似乎也会超载呀?答案是:没错,它的确会超载,但是它超载的仅仅是简单的代理吞吐请求!所有诸如SSI、CGI、ePerl等等的处理完全是由其他机器完成的,这个才是要点。硬件/TCP循环 还有一个硬件解决方案。Cisco有一个叫LocalDirector的东西,实现了TCP/IP层的负载均衡,事实上,它是一个位于网站集群前端的电路级网关。如果你有足够

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论