反向动态镜像
说明:
...
方案:
| 代码: |
| RewriteEngine on RewriteCond /mirror/of/remotesite/$1 -U RewriteRule ^http://www\.remotesite\.com/(.*)$ /mirror/of/remotesite/$1 |
通过Intranet取得丢失的数据
说明:
这是一种在受防火墙保护的(内部的)Intranet(www2.quux-corp.dom)上保存和维护实际数据，而虚拟地运行企业级(外部的)Internet网站服务器(www.quux-corp.dom)的巧妙的方法。这种方法是外部服务器在空闲时间从内部服务器取得被请求的数据。
方案:
首先，必须确保防火墙对内部服务器的保护，并只允许此外部服务器取得数据。对包过滤(packet-filtering)防火墙，可以如下制定防火墙规则：
| 代码: |
| ALLOW Host www.quux-corp.dom Port >1024 --> Host www2.quux-corp.dom Port 80 DENY Host * Port * --> Host www2.quux-corp.dom Port 80 |
按你的实际配置，只要对上例稍作调整即可。接着，建立通过代理后台获取丢失数据的mod_rewrite规则：
| 代码: |
| RewriteRule ^/~([^/]+)/?(.*) /home/$1/.www/$2 RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^/home/([^/]+)/.www/?(.*) http://www2.quux-corp.dom/~$1/pub/$2 [P] |
负载的均衡
说明:
如何均衡www.foo.com的负载到www[0-5].foo.com(一共是6个服务器)?
方案:
这个问题有许多可能的解决方案，在此，我们讨论通称为“基于DNS(DNS-based)的”方案，和特殊的使用mod_rewrite的方案:
DNS循环(DNS Round-Robin)
最简单的方法是用BIND的DNS循环特性，只要按惯例设置www[0-9].foo.com的DNS的A(地址)记录，如：
| 代码: |
| www0 IN A 1.2.3.1 www1 IN A 1.2.3.2 www2 IN A 1.2.3.3 www3 IN A 1.2.3.4 www4 IN A 1.2.3.5 www5 IN A 1.2.3.6 |
然后，增加以下各项:
| 代码: |
| www IN CNAME www0.foo.com. IN CNAME www1.foo.com. IN CNAME www2.foo.com. IN CNAME www3.foo.com. IN CNAME www4.foo.com. IN CNAME www5.foo.com. IN CNAME www6.foo.com. |
注意，上述看起来似乎是错误的，但事实上，它的确是BIND中的一个预期的特性，而且也可以这样用。无论如何，现在www.foo.com已经被解析，BIND可以给出www0-www6 - 虽然每次在次序上会有轻微的置换/循环，客户端的请求可以被分散到各个服务器。可是，这并不是一个优秀的负载均衡方案，因为，DNS解析信息可以被网络中其他名称服务器缓冲，而一旦www.foo.com被解析为wwwN.foo.com，则其后继请求都将被送往www.foo.com。但是最终结果是正确的，因为请求的总量的确被分散到各个服务器了
DNS 负载均衡
一种成熟的基于DNS的负载均衡方法是使用http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html的lbnamed程序，它是一个Perl 5程序，带有若干辅助工具，实现了真正的基于DNS的负载均衡。
代理吞吐循环(Proxy Throughput Round-Robin)
这是一个使用mod_rewrite及其代理吞吐特性的方法。首先，在DNS记录中，将www0.foo.com固定为www.foo.com，如下：
| 代码: |
| www IN CNAME www0.foo.com. |
其次，将www0.foo.com转换为一个专职代理服务器，即，由这个机器把所有到来的URL通过内部代理分散到另外5个服务器(www1-www5)。为此，必须建立一个规则集，对所有URL调用一个负载均衡脚本lb.pl。
| 代码: |
| RewriteEngine on RewriteMap lb prg:/path/to/lb.pl RewriteRule ^/(.+)$ ${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 (<STDIN>) { $cnt = (($cnt+1) % ($last+1-$first)); $server = sprintf("%s%d.%s", $name, $cnt+$first, $domain); print "http://$server/$_"; } ##EOF## |
最后的说明：这样有用吗？www0.foo.com似乎也会超载呀？答案是：没错，它的确会超载，但是它超载的仅仅是简单的代理吞吐请求！所有诸如SSI、CGI、ePerl等等的处理完全是由其他机器完成的，这个才是要点。
硬件/TCP循环
还有一个硬件解决方案。Cisco有一个叫LocalDirector的东西，实现了TCP/IP层的负载均衡，事实上，它是一个位于网站集群前端的电路级网关。如果你有足够资金而且的确需要高性能的解决方案，那么可以用这个。
反向代理
说明:
...
方案:
| 代码: |
| ## ## apache-rproxy.conf -- Apache configuration for Reverse Proxy Usage ## # server type ServerType standalone Listen 8000 MinSpareServers 16 StartServers 16 MaxSpareServers 16 MaxClients 16 MaxRequestsPerChild 100 # server operation parameters KeepAlive on MaxKeepAliveRequests 100 KeepAliveTimeout 15 Timeout 400 IdentityCheck off HostnameLookups off # paths to runtime files PidFile /path/to/apache-rproxy.pid LockFile /path/to/apache-rproxy.lock ErrorLog /path/to/apache-rproxy.elog CustomLog /path/to/apache-rproxy.dlog "%{%v/%T}t %h -> %{SERVER}e URL: %U" # unused paths ServerRoot /tmp DocumentRoot /tmp CacheRoot /tmp RewriteLog /dev/null TransferLog /dev/null TypesConfig /dev/null AccessConfig /dev/null ResourceConfig /dev/null # speed up and secure processing <Directory /> Options -FollowSymLinks -SymLinksIfOwnerMatch AllowOverride None </Directory> # the status page for monitoring the reverse proxy <Location /apache-rproxy-status> SetHandler server-status </Location> # enable the URL rewriting engine RewriteEngine on RewriteLogLevel 0 # define a rewriting map with value-lists where # mod_rewrite randomly chooses a particular value RewriteMap server rnd:/path/to/apache-rproxy.conf-servers # make sure the status page is handled locally # and make sure no one uses our proxy except ourself RewriteRule ^/apache-rproxy-status.* - [L] RewriteRule ^(http|ftp)://.* - [F] # now choose the possible servers for particular URL types RewriteRule ^/(.*\.(cgi|shtml))$ to://${server:dynamic}/$1 [S=1] RewriteRule ^/(.*)$ to://${server:static}/$1 # and delegate the generated URL by passing it # through the proxy module RewriteRule ^to://([^/]+)/(.*) http://$1/$2 [E=SERVER:$1,P,L] # and make really sure all other stuff is forbidden # when it should survive the above rules... RewriteRule .* - [F] # enable the Proxy module without caching ProxyRequests on NoCache * # setup URL reverse mapping for redirect reponses ProxyPassReverse / http://www1.foo.dom/ ProxyPassReverse / http://www2.foo.dom/ ProxyPassReverse / http://www3.foo.dom/ ProxyPassReverse / http://www4.foo.dom/ ProxyPassReverse / http://www5.foo.dom/ ProxyPassReverse / http://www6.foo.dom/ ## ## apache-rproxy.conf-servers -- Apache/mod_rewrite selection table ## # list of backend servers which serve static # pages (HTML files and Images, etc.) static www1.foo.dom|www2.foo.dom|www3.foo.dom|www4.foo.dom # list of backend servers which serve dynamically # generated page (CGI programs or mod_perl scripts) dynamic www5.foo.dom|www6.foo.dom |
新的MIME类型，新的服务
说明:
网上有许多很技巧的CGI程序，但是用法晦涩，许多网管弃之不用。即使是Apache的MEME类型的动作处理器，也仅仅在CGI程序不需要在其输入中包含特殊URL(PATH_INFO和QUERY_STRINGS)时才很好用。首先，配置一种新的后缀为.scgi(for secure CGI)文件类型，其处理器是很常见的cgiwrap程序。问题是：如果使用同类URL规划(见上述)，而用户宿主目录中的一个文件的URL是/u/user/foo/bar.scgi，可是cgiwrap要求的URL的格式是/~user/foo/bar.scgi/，以下规则解决了这个问题：
| 代码: |
| RewriteRule ^/[uge]/([^/]+)/\.www/(.+)\.scgi(.*) ... ... /internal/cgi/user/cgiwrap/~$1/$2.scgi$3 [NS,T=application/x-http-cgi] |
另外，假设需要使用其他程序：wwwlog(显示access.log中的一个URL子树)和wwwidx(对一个URL子树运行Glimpse)，则必须对这些程序提供URL区域作为其操作对象。比如，对/u/user/foo/执行swwidx程序的超链是这样的：
| 代码: |
| /internal/cgi/user/swwidx?i=/u/user/foo/ |
其缺点是，必须同时硬编码超链中的区域和CGI的路径，如果重组了这个区域，就需要花费大量时间来修改各个超链。
方案:
方案是用一个特殊的新的URL格式，自动拼装CGI参数：
| 代码: |
| RewriteRule ^/([uge])/([^/]+)(/?.*)/\* /internal/cgi/user/wwwidx?i=/$1/$2$3/ RewriteRule ^/([uge])/([^/]+)(/?.*):log /internal/cgi/user/wwwlog?f=/$1/$2$3 |
现在，这个搜索到/u/user/foo/的超链简化成了：
| 代码: |
| HREF="*" |
它会被内部地自动转换为
| 代码: |
| /internal/cgi/user/wwwidx?i=/u/user/foo/ |
如此，可以为使用:log的超链，拼装出调用CGI程序的参数。
从静态到动态
说明:
如何无缝转换静态页面foo.html为动态的foo.cgi，而不为浏览器/用户所察觉。
方案:
只须重写此URL为CGI-script，以强制为可以作为CGI-script运行的正确的MIME类型。如此，对/~quux/foo.html的请求其实会执行/~quux/foo.cgi。
| 代码: |
| RewriteEngine on RewriteBase /~quux/ RewriteRule ^foo\.html$ foo.cgi [T=application/x-httpd-cgi] |
空闲时间内的内容协商
说明:
这是一个很难解的功能：动态生成的静态页面，即，它应该作为静态页面发送(从文件系统中读出，然后直接发出去)，但是如果它丢失了，则由服务器动态生成。如此，可以静态地提供CGI生成的页面，除非有人(或者是一个cronjob)删除了这些静态页面，而且其内容可以得到更新。
方案:
以下规则集实现这个功能：
| 代码: |
| RewriteCond %{REQUEST_FILENAME} !-s RewriteRule ^page\.html$ page.cgi [T=application/x-httpd-cgi,L] |
自动更新的文档
说明:
建立一个复杂的页面，能够在用编辑器写了一个更新的版本时自动在浏览器上得到刷新，这不是很好吗？这可能吗？
方案:
这是可行的! 这需要综合利用MIME多成分、网站服务器的NPH和mod_rewrite的URL操控特性。首先，建立一个新的URL特性：对在文件系统中更新时需要刷新的所有URL加上:refresh。
| 代码: |
| RewriteRule ^(/[uge]/[^/]+/?.*):refresh /internal/cgi/apache/nph-refresh?f=$1 |
然后，修改URL
| 代码: |
| /u/foo/bar/page.html:refresh |
以内部地操控此URL
| 代码: |
| /internal/cgi/apache/nph-refresh?f=/u/foo/bar/page.html |
接着就是NPH-CGI脚本部分了。虽然，人们常说"left as an exercise to the reader"
，我还是给出答案了。 | 代码: |
| #!/sw/bin/perl ## ## nph-refresh -- NPH/CGI script for auto refreshing pages ## Copyright (c) 1997 Ralf S. Engelschall, All Rights Reserved. ## $| = 1; # split the QUERY_STRING variable @pairs = split(/&/, $ENV{'QUERY_STRING'}); foreach $pair (@pairs) { ($name, $value) = split(/=/, $pair); $name =~ tr/A-Z/a-z/; $name = 'QS_' . $name; $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg; eval "\$$name = \"$value\""; } $QS_s = 1 if ($QS_s eq ''); $QS_n = 3600 if ($QS_n eq ''); if ($QS_f eq '') { print "HTTP/1.0 200 OK\n"; print "Content-type: text/html\n\n"; print "&b&ERROR&/b&: No file given\n"; exit(0); } if (! -f $QS_f) { print "HTTP/1.0 200 OK\n"; print "Content-type: text/html\n\n"; print "&b&ERROR&/b&: File $QS_f not found\n"; exit(0); } sub print_http_headers_multipart_begin { print "HTTP/1.0 200 OK\n"; $bound = "ThisRandomString12345"; print "Content-type: multipart/x-mixed-replace;boundary=$bound\n"; &print_http_headers_multipart_next; } sub print_http_headers_multipart_next { print "\n--$bound\n"; } sub print_http_headers_multipart_end { print "\n--$bound--\n"; } sub displayhtml { local($buffer) = @_; $len = length($buffer); print "Content-type: text/html\n"; print "Content-length: $len\n\n"; print $buffer; } sub readfile { local($file) = @_; local(*FP, $size, $buffer, $bytes); ($x, $x, $x, $x, $x, $x, $x, $size) = stat($file); $size = sprintf("%d", $size); open(FP, "&$file"); $bytes = sysread(FP, $buffer, $size); close(FP); return $buffer; } $buffer = &readfile($QS_f); &print_http_headers_multipart_begin; &displayhtml($buffer); sub mystat { local($file) = $_[0]; local($time); ($x, $x, $x, $x, $x, $x, $x, $x, $x, $mtime) = stat($file); return $mtime; } $mtimeL = &mystat($QS_f); $mtime = $mtime; for ($n = 0; $n & $QS_n; $n++) { while (1) { $mtime = &mystat($QS_f); if ($mtime ne $mtimeL) { $mtimeL = $mtime; sleep(2); $buffer = &readfile($QS_f); &print_http_headers_multipart_next; &displayhtml($buffer); sleep(5); $mtimeL = &mystat($QS_f); last; } sleep($QS_s); } } &print_http_headers_multipart_end; exit(0); ##EOF## |
说明:
Apache的<VirtualHost>功能很强，在有几十个虚拟主机的情况下运行得很好，但是如果你是ISP，需要提供几百个虚拟主机，那么这就不是一个最佳的选择了。
方案:
为此，需要用代理吞吐(Proxy Throughput)功能(flag [P])映射远程页面甚至整个远程网络区域到自己的名称空间：
| 代码: |
| ## ## vhost.map ## www.vhost1.dom:80 /path/to/docroot/vhost1 www.vhost2.dom:80 /path/to/docroot/vhost2 : www.vhostN.dom:80 /path/to/docroot/vhostN |
| 代码: |
| ## ## httpd.conf ## : # use the canonical hostname on redirects, etc. UseCanonicalName on : # add the virtual host in front of the CLF-format CustomLog /path/to/access_log "%{VHOST}e %h %l %u %t \"%r\" %>s %b" : # enable the rewriting engine in the main server RewriteEngine on # define two maps: one for fixing the URL and one which defines # the available virtual hosts with their corresponding # DocumentRoot. RewriteMap lowercase int:tolower RewriteMap vhost txt:/path/to/vhost.map # Now do the actual virtual host mapping # via a huge and complicated single rule: # # 1. make sure we don't map for common locations RewriteCond %{REQUEST_URL} !^/commonurl1/.* RewriteCond %{REQUEST_URL} !^/commonurl2/.* : RewriteCond %{REQUEST_URL} !^/commonurlN/.* # # 2. make sure we have a Host header, because # currently our approach only supports # virtual hosting through this header RewriteCond %{HTTP_HOST} !^$ # # 3. lowercase the hostname RewriteCond ${lowercase:%{HTTP_HOST}|NONE} ^(.+)$ # # 4. lookup this hostname in vhost.map and # remember it only when it is a path # (and not "NONE" from above) RewriteCond ${vhost:%1} ^(/.*)$ # # 5. finally we can map the URL to its docroot location # and remember the virtual host for logging puposes RewriteRule ^/(.*)$ %1/$1 [E=VHOST:${lowercase:%{HTTP_HOST}}] : |
对访问的限制
阻止Robots
说明:
如何阻止一个完全匿名的robot取得特定网络区域的页面？一个/robots.txt文件可以包含若干"Robot Exclusion Protocol(robot排除协议)"的行，但不足以阻止此类robot。
方案:
可以用一个规则集以拒绝对网络区域/~quux/foo/arc/(对一个很深的目录区域进行列表可能会使服务器产生很大的负载)的访问。还必须确保仅阻止特定的robot，就是说，仅仅阻止robot访问主机是不够的，这样会同时也阻止了用户访问该主机。为此，就需要对HTTP头的User-Agent信息作匹配。
| 代码: |
| RewriteCond %{HTTP_USER_AGENT} ^NameOfBadRobot.* RewriteCond %{REMOTE_ADDR} ^123\.45\.67\.[8-9]$ RewriteRule ^/~quux/foo/arc/.+ - [F] |
说明:
假设，http://www.quux-corp.de/~quux/有一些内嵌图片的页面，这些图片很好，所以就有人用超链连到他们自己的页面中了。由于这样徒然增加了我们的服务器的流量，因此，我们不愿意这种事情发生。
方案:
虽然，我们不能100%地保护这些图片不被写入别人的页面，但至少可以对发出HTTP Referer头的浏览器加以限制。
| 代码: |
| RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http://www.quux-corp.de/~quux/.*$ [NC] RewriteRule .*\.gif$ - [F] RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !.*/foo-with-gif\.html$ RewriteRule ^inlined-in-foo\.gif$ - [F] |
对主机的拒绝
说明:
如何拒绝一批外部列表中的主机对我们服务器的使用？
方案:
| 代码: |
| For Apache >= 1.3b6: RewriteEngine on RewriteMap hosts-deny txt:/path/to/hosts.deny RewriteCond ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND} !=NOT-FOUND [OR] RewriteCond ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND} !=NOT-FOUND RewriteRule ^/.* - [F] For Apache <= 1.3b6: RewriteEngine on RewriteMap hosts-deny txt:/path/to/hosts.deny RewriteRule ^/(.*)$ ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND}/$1 RewriteRule !^NOT-FOUND/.* - [F] RewriteRule ^NOT-FOUND/(.*)$ ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND}/$1 RewriteRule !^NOT-FOUND/.* - [F] RewriteRule ^NOT-FOUND/(.*)$ /$1 |
| 代码: |
| ## ## hosts.deny ## ## ATTENTION! This is a map, not a list, even when we treat it as such. ## mod_rewrite parses it for key/value pairs, so at least a ## dummy value "-" must be present for each entry. ## 193.102.180.41 - bsdti1.sdm.de - 192.76.162.40 - |
对代理的拒绝
说明:
如何拒绝某个主机或者来自特定主机的用户使用Apache代理？
方案:
首先，要确保Apache网站服务器在编译时配置文件中mod_rewrite在mod_proxy的下面(!)，使它在mod_proxy之前被调用。然后，如下拒绝某个主机...
| 代码: |
| RewriteCond %{REMOTE_HOST} ^badhost\.mydomain\.com$ RewriteRule !^http://[^/.]\.mydomain.com.* - [F] |
...如下拒绝user@host-dependent:
| 代码: |
| RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} ^badguy@badhost\.mydomain\.com$ RewriteRule !^http://[^/.]\.mydomain.com.* - [F] |
特殊的认证
说明:
有时候，会需要一种非常特殊的认证，即，对一组明确指定的用户，允许其访问，而没有(在使用mod_access的基本认证方法时可能会出现的)任何提示。
方案:
可是使用一个重写条件列表来排除所有的朋友：
| 代码: |
| RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend1@client1.quux-corp\.com$ RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend2@client2.quux-corp\.com$ RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend3@client3.quux-corp\.com$ RewriteRule ^/~quux/only-for-friends/ - [F] |
基于提交者(Referer)的反射器
说明:
如何配置一个基于HTTP头"Referer"的反射器以反射到任意数量的提交页面?
方案:
使用这个很技巧的规则集...
| 代码: |
| RewriteMap deflector txt:/path/to/deflector.map RewriteCond %{HTTP_REFERER} !="" RewriteCond ${deflector:%{HTTP_REFERER}} ^-$ RewriteRule ^.* %{HTTP_REFERER} [R,L] RewriteCond %{HTTP_REFERER} !="" RewriteCond ${deflector:%{HTTP_REFERER}|NOT-FOUND} !=NOT-FOUND RewriteRule ^.* ${deflector:%{HTTP_REFERER}} [R,L] |
... 并结合对应的重写地图:
| 代码: |
| ## ## deflector.map ## http://www.badguys.com/bad/index.html - http://www.badguys.com/bad/index2.html - http://www.badguys.com/bad/index3.html http://somewhere.com/ |
它可以自动将请求(在地图中指定了"-"值的时候)反射回其提交页面，或者(在地图中URL有第二个参数时)反射到一个特定的URL。
其他
外部重写引擎
说明:
一个常见的问题: 如何解决似乎无法用mod_rewrite解决的FOO/BAR/QUUX/之类的问题？
方案:
可以使用一个与RewriteMap功能相同的外部RewriteMap程序，一旦它在Apache启动时被执行，则从STDIN接收被请求的URL，并将处理过(通常是重写过的)的URL(以相同顺序!)在STDOUT输出。
| 代码: |
| RewriteEngine on RewriteMap quux-map prg:/path/to/map.quux.pl RewriteRule ^/~quux/(.*)$ /~quux/${quux-map:$1} |
| 代码: |
| #!/path/to/perl # disable buffered I/O which would lead # to deadloops for the Apache server $| = 1; # read URLs one per line from stdin and # generate substitution URL on stdout while (<>) { s|^foo/|bar/|; print $_; } |
这是一个作演示的例子，只是把所有的URL /~quux/foo/...重写为/~quux/bar/...，而事实上，可以把它修改以获得任何你需要的功能。但是要注意，虽然一般用户都可以使用，可是只有系统管理员才可以定义这样的地图。
发表评论 
打印本文
推荐本文
加入收藏
返回顶部
关闭窗口
