📄 rewriteguide.html.en
字号:
<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><!-- XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX This file is generated from xml source: DO NOT EDIT XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX --><title>URL Rewriting Guide - Apache HTTP Server</title><link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" /><link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" /><link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /><link href="../images/favicon.ico" rel="shortcut icon" /></head><body id="manual-page"><div id="page-header"><p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p><p class="apache">Apache HTTP Server Version 2.0</p><img alt="" src="../images/feather.gif" /></div><div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div><div id="path"><a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs/">Documentation</a> > <a href="../">Version 2.0</a> > <a href="./">Miscellaneous Documentation</a></div><div id="page-content"><div id="preamble"><h1>URL Rewriting Guide</h1><div class="toplang"><p><span>Available Languages: </span><a href="../en/misc/rewriteguide.html" title="English"> en </a> |<a href="../ko/misc/rewriteguide.html" hreflang="ko" rel="alternate" title="Korean"> ko </a></p></div> <div class="note"> <p>Originally written by<br /> <cite>Ralf S. Engelschall <rse@apache.org></cite><br /> December 1997</p> </div> <p>This document supplements the <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> <a href="../mod/mod_rewrite.html">reference documentation</a>. It describes how one can use Apache's <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> to solve typical URL-based problems with which webmasters are commonony confronted. We give detailed descriptions on how to solve each problem by configuring URL rewriting rulesets.</p> </div><div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#ToC1">Introduction to <code>mod_rewrite</code></a></li><li><img alt="" src="../images/down.gif" /> <a href="#ToC2">Practical Solutions</a></li><li><img alt="" src="../images/down.gif" /> <a href="#url">URL Layout</a></li><li><img alt="" src="../images/down.gif" /> <a href="#content">Content Handling</a></li><li><img alt="" src="../images/down.gif" /> <a href="#access">Access Restriction</a></li><li><img alt="" src="../images/down.gif" /> <a href="#other">Other</a></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="ToC1" id="ToC1">Introduction to <code>mod_rewrite</code></a></h2> <p>The Apache module <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> is a killer one, i.e. it is a really sophisticated module which provides a powerful way to do URL manipulations. With it you can do nearly all types of URL manipulations you ever dreamed about. The price you have to pay is to accept complexity, because <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>'s major drawback is that it is not easy to understand and use for the beginner. And even Apache experts sometimes discover new aspects where <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> can help.</p> <p>In other words: With <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> you either shoot yourself in the foot the first time and never use it again or love it for the rest of your life because of its power. This paper tries to give you a few initial success events to avoid the first case by presenting already invented solutions to you.</p> </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="ToC2" id="ToC2">Practical Solutions</a></h2> <p>Here come a lot of practical solutions I've either invented myself or collected from other people's solutions in the past. Feel free to learn the black magic of URL rewriting from these examples.</p> <div class="warning">ATTENTION: Depending on your server-configuration it can be necessary to slightly change the examples for your situation, e.g. adding the <code>[PT]</code> flag when additionally using <code class="module"><a href="../mod/mod_alias.html">mod_alias</a></code> and <code class="module"><a href="../mod/mod_userdir.html">mod_userdir</a></code>, etc. Or rewriting a ruleset to fit in <code>.htaccess</code> context instead of per-server context. Always try to understand what a particular ruleset really does before you use it. It avoid problems.</div> </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="url" id="url">URL Layout</a></h2> <h3>Canonical URLs</h3> <dl> <dt>Description:</dt> <dd> <p>On some webservers there are more than one URL for a resource. Usually there are canonical URLs (which should be actually used and distributed) and those which are just shortcuts, internal ones, etc. Independent of which URL the user supplied with the request he should finally see the canonical one only.</p> </dd> <dt>Solution:</dt> <dd> <p>We do an external HTTP redirect for all non-canonical URLs to fix them in the location view of the Browser and for all subsequent requests. In the example ruleset below we replace <code>/~user</code> by the canonical <code>/u/user</code> and fix a missing trailing slash for <code>/u/user</code>.</p><div class="example"><pre>RewriteRule ^/<strong>~</strong>([^/]+)/?(.*) /<strong>u</strong>/$1/$2 [<strong>R</strong>]RewriteRule ^/([uge])/(<strong>[^/]+</strong>)$ /$1/$2<strong>/</strong> [<strong>R</strong>]</pre></div> </dd> </dl> <h3>Canonical Hostnames</h3> <dl> <dt>Description:</dt> <dd>The goal of this rule is to force the use of a particular hostname, in preference to other hostnames which may be used to reach the same site. For example, if you wish to force the use of <strong>www.example.com</strong> instead of <strong>example.com</strong>, you might use a variant of the following recipe.</dd> <dt>Solution:</dt> <dd><div class="example"><pre># For sites running on a port other than 80RewriteCond %{HTTP_HOST} !^www\.example\.com [NC]RewriteCond %{HTTP_HOST} !^$RewriteCond %{SERVER_PORT} !^80$RewriteRule ^/(.*) http://www.example.com:%{SERVER_PORT}/$1 [L,R]# And for a site running on port 80RewriteCond %{HTTP_HOST} !^www\.example\.com [NC]RewriteCond %{HTTP_HOST} !^$RewriteRule ^/(.*) http://www.example.com/$1 [L,R]</pre></div> </dd> </dl> <h3>Moved <code>DocumentRoot</code></h3> <dl> <dt>Description:</dt> <dd> <p>Usually the <code class="directive"><a href="../mod/core.html#documentroot">DocumentRoot</a></code> of the webserver directly relates to the URL "<code>/</code>". But often this data is not really of top-level priority, it is perhaps just one entity of a lot of data pools. For instance at our Intranet sites there are <code>/e/www/</code> (the homepage for WWW), <code>/e/sww/</code> (the homepage for the Intranet) etc. Now because the data of the <code class="directive"><a href="../mod/core.html#documentroot">DocumentRoot</a></code> stays at <code>/e/www/</code> we had to make sure that all inlined images and other stuff inside this data pool work for subsequent requests.</p> </dd> <dt>Solution:</dt> <dd> <p>We redirect the URL <code>/</code> to <code>/e/www/</code>: </p> <div class="example"><pre>RewriteEngine onRewriteRule <strong>^/$</strong> /e/www/ [<strong>R</strong>]</pre></div> <p>Note that this can also be handled using the <code class="directive"><a href="../mod/mod_alias.html#redirectmatch">RedirectMatch</a></code> directive:</p> <div class="example"><p><code> RedirectMatch ^/$ http://example.com/e/www/ </code></p></div> </dd> </dl> <h3>Trailing Slash Problem</h3> <dl> <dt>Description:</dt> <dd> <p>Every webmaster can sing a song about the problem of the trailing slash on URLs referencing directories. If they are missing, the server dumps an error, because if you say <code>/~quux/foo</code> instead of <code>/~quux/foo/</code> then the server searches for a <em>file</em> named <code>foo</code>. And because this file is a directory it complains. Actually it tries to fix it itself in most of the cases, but sometimes this mechanism need to be emulated by you. For instance after you have done a lot of complicated URL rewritings to CGI scripts etc.</p> </dd> <dt>Solution:</dt> <dd> <p>The solution to this subtle problem is to let the server add the trailing slash automatically. To do this correctly we have to use an external redirect, so the browser correctly requests subsequent images etc. If we only did a internal rewrite, this would only work for the directory page, but would go wrong when any images are included into this page with relative URLs, because the browser would request an in-lined object. For instance, a request for <code>image.gif</code> in <code>/~quux/foo/index.html</code> would become <code>/~quux/image.gif</code> without the external redirect!</p> <p>So, to do this trick we write:</p><div class="example"><pre>RewriteEngine onRewriteBase /~quux/RewriteRule ^foo<strong>$</strong> foo<strong>/</strong> [<strong>R</strong>]</pre></div> <p>The crazy and lazy can even do the following in the top-level <code>.htaccess</code> file of their homedir. But notice that this creates some processing overhead.</p><div class="example"><pre>RewriteEngine onRewriteBase /~quux/RewriteCond %{REQUEST_FILENAME} <strong>-d</strong>RewriteRule ^(.+<strong>[^/]</strong>)$ $1<strong>/</strong> [R]</pre></div> </dd> </dl> <h3>Webcluster through Homogeneous URL Layout</h3> <dl> <dt>Description:</dt> <dd> <p>We want to create a homogeneous and consistent URL layout over all WWW servers on a Intranet webcluster, i.e. all URLs (per definition server local and thus server dependent!) become actually server <em>independent</em>! What we want is to give the WWW namespace a consistent server-independent layout: no URL should have to include any physically correct target server. The cluster itself should drive us automatically to the physical target host.</p> </dd> <dt>Solution:</dt> <dd> <p>First, the knowledge of the target servers come from (distributed) external maps which contain information where our users, groups and entities stay. The have the form</p><div class="example"><pre>user1 server_of_user1user2 server_of_user2: :</pre></div> <p>We put them into files <code>map.xxx-to-host</code>. Second we need to instruct all servers to redirect URLs of the forms</p><div class="example"><pre>/u/user/anypath/g/group/anypath/e/entity/anypath</pre></div> <p>to</p><div class="example"><pre>http://physical-host/u/user/anypathhttp://physical-host/g/group/anypathhttp://physical-host/e/entity/anypath</pre></div> <p>when the URL is not locally valid to a server. The following ruleset does this for us by the help of the map files (assuming that server0 is a default server which will be used if a user has no entry in the map):</p><div class="example"><pre>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/<strong>([^/]+)</strong>/?(.*) http://<strong>${user-to-host:$1|server0}</strong>/u/$1/$2RewriteRule ^/g/<strong>([^/]+)</strong>/?(.*) http://<strong>${group-to-host:$1|server0}</strong>/g/$1/$2RewriteRule ^/e/<strong>([^/]+)</strong>/?(.*) http://<strong>${entity-to-host:$1|server0}</strong>/e/$1/$2RewriteRule ^/([uge])/([^/]+)/?$ /$1/$2/.www/RewriteRule ^/([uge])/([^/]+)/([^.]+.+) /$1/$2/.www/$3\</pre></div> </dd> </dl> <h3>Move Homedirs to Different Webserver</h3> <dl> <dt>Description:</dt> <dd> <p>Many webmasters have asked for a solution to the following situation: They wanted to redirect just all homedirs on a webserver to another webserver. They usually need such things when establishing a newer webserver which will replace the old one over time.</p> </dd> <dt>Solution:</dt> <dd> <p>The solution is trivial with <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>. On the old webserver we just redirect all <code>/~user/anypath</code> URLs to <code>http://newserver/~user/anypath</code>.</p><div class="example"><pre>RewriteEngine onRewriteRule ^/~(.+) http://<strong>newserver</strong>/~$1 [R,L]</pre></div> </dd> </dl> <h3>Structured Homedirs</h3> <dl> <dt>Description:</dt> <dd> <p>Some sites with thousands of users usually use a structured homedir layout, i.e. each homedir is in a subdirectory which begins for instance with the first
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -