📄 mod_rewrite.html.en
字号:
System-view. </p> <p>Notice: These variables hold the URI/URL <em>as they were initially requested</em>, <em>i.e.</em>, <em>before</em> any rewriting. This is important because the rewriting process is primarily used to rewrite logical URLs to physical pathnames.</p><div class="example"><h3>Example</h3><pre>SCRIPT_NAME=/sw/lib/w3s/tree/global/u/rse/.www/index.htmlSCRIPT_FILENAME=/u/rse/.www/index.htmlSCRIPT_URL=/u/rse/SCRIPT_URI=http://en1.engelschall.com/u/rse/</pre></div></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="Solutions" id="Solutions">Practical Solutions</a></h2> <p>We also have an <a href="../misc/rewriteguide.html">URL Rewriting Guide</a> available, which provides a collection of practical solutions for URL-based problems. There you can find real-life rulesets and additional information about mod_rewrite.</p></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="RewriteBase" id="RewriteBase">RewriteBase</a> <a name="rewritebase" id="rewritebase">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Sets the base URL for per-directory rewrites</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>RewriteBase <em>URL-path</em></code></td></tr><tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>See usage for information.</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:</a></th><td>directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:</a></th><td>FileInfo</td></tr><tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr><tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_rewrite</td></tr></table> <p>The <code class="directive">RewriteBase</code> directive explicitly sets the base URL for per-directory rewrites. As you will see below, <code class="directive"><a href="#rewriterule">RewriteRule</a></code> can be used in per-directory config files (<code>.htaccess</code>). There it will act locally, <em>i.e.</em>, the local directory prefix is stripped at this stage of processing and your rewriting rules act only on the remainder. At the end it is automatically added back to the path. The default setting is; <code class="directive">RewriteBase</code> <em>physical-directory-path</em></p> <p>When a substitution occurs for a new URL, this module has to re-inject the URL into the server processing. To be able to do this it needs to know what the corresponding URL-prefix or URL-base is. By default this prefix is the corresponding filepath itself. <strong>But at most websites URLs are NOT directly related to physical filename paths, so this assumption will usually be wrong!</strong> There you have to use the <code>RewriteBase</code> directive to specify the correct URL-prefix.</p><div class="note"> If your webserver's URLs are <strong>not</strong> directlyrelated to physical file paths, you have to use<code class="directive">RewriteBase</code> in every <code>.htaccess</code>files where you want to use <code class="directive"><a href="#rewriterule">RewriteRule</a></code> directives.</div> <p> For example, assume the following per-directory config file:</p><div class="example"><pre>## /abc/def/.htaccess -- per-dir config file for directory /abc/def# Remember: /abc/def is the physical path of /xyz, <em>i.e.</em>, the server# has a 'Alias /xyz /abc/def' directive <em>e.g.</em>#RewriteEngine On# let the server know that we were reached via /xyz and not# via the physical path prefix /abc/defRewriteBase /xyz# now the rewriting rulesRewriteRule ^oldstuff\.html$ newstuff.html</pre></div> <p>In the above example, a request to <code>/xyz/oldstuff.html</code> gets correctly rewritten to the physical file <code>/abc/def/newstuff.html</code>.</p><div class="note"><h3>For Apache Hackers</h3><p>The following list gives detailed information about the internal processing steps:</p><pre>Request: /xyz/oldstuff.htmlInternal Processing: /xyz/oldstuff.html -> /abc/def/oldstuff.html (per-server Alias) /abc/def/oldstuff.html -> /abc/def/newstuff.html (per-dir RewriteRule) /abc/def/newstuff.html -> /xyz/newstuff.html (per-dir RewriteBase) /xyz/newstuff.html -> /abc/def/newstuff.html (per-server Alias)Result: /abc/def/newstuff.html</pre> <p>This seems very complicated but is the correct Apache internal processing, because the per-directory rewriting comes too late in the process. So, when it occurs the (rewritten) request has to be re-injected into the Apache kernel! BUT: While this seems like a serious overhead, it really isn't, because this re-injection happens fully internally to the Apache server and the same procedure is used by many other operations inside Apache. So, you can be sure the design and implementation is correct.</p></div></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="RewriteCond" id="RewriteCond">RewriteCond</a> <a name="rewritecond" id="rewritecond">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Defines a condition under which rewriting will take place</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code> RewriteCond <em>TestString</em> <em>CondPattern</em></code></td></tr><tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:</a></th><td>FileInfo</td></tr><tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr><tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_rewrite</td></tr></table> <p>The <code class="directive">RewriteCond</code> directive defines a rule condition. Precede a <code class="directive"><a href="#rewriterule">RewriteRule</a></code> directive with one or more <code class="directive">RewriteCond</code> directives. The following rewriting rule is only used if its pattern matches the current state of the URI <strong>and</strong> if these additional conditions apply too.</p> <p><em>TestString</em> is a string which can contains the following expanded constructs in addition to plain text:</p> <ul> <li> <strong>RewriteRule backreferences</strong>: These are backreferences of the form <p class="indent"> <strong><code>$N</code></strong> </p> (0 <= N <= 9) which provide access to the grouped parts (parenthesis!) of the pattern from the corresponding <code>RewriteRule</code> directive (the one following the current bunch of <code>RewriteCond</code> directives). </li> <li> <strong>RewriteCond backreferences</strong>: These are backreferences of the form <p class="indent"> <strong><code>%N</code></strong> </p> (1 <= N <= 9) which provide access to the grouped parts (parentheses!) of the pattern from the last matched <code>RewriteCond</code> directive in the current bunch of conditions. </li> <li> <strong>RewriteMap expansions</strong>: These are expansions of the form <p class="indent"> <strong><code>${mapname:key|default}</code></strong> </p> See <a href="#mapfunc">the documentation for RewriteMap</a> for more details. </li> <li> <strong>Server-Variables</strong>: These are variables of the form <p class="indent"> <strong><code>%{</code> <em>NAME_OF_VARIABLE</em> <code>}</code></strong> </p> where <em>NAME_OF_VARIABLE</em> can be a string taken from the following list: <table> <tr> <th>HTTP headers:</th> <th>connection & request:</th> <th /> </tr> <tr> <td> HTTP_USER_AGENT<br /> HTTP_REFERER<br /> HTTP_COOKIE<br /> HTTP_FORWARDED<br /> HTTP_HOST<br /> HTTP_PROXY_CONNECTION<br /> HTTP_ACCEPT<br /> </td> <td> REMOTE_ADDR<br /> REMOTE_HOST<br /> REMOTE_USER<br /> REMOTE_IDENT<br /> REQUEST_METHOD<br /> SCRIPT_FILENAME<br /> PATH_INFO<br /> QUERY_STRING<br /> AUTH_TYPE<br /> </td> <td /> </tr> <tr> <th>server internals:</th> <th>system stuff:</th> <th>specials:</th> </tr> <tr> <td> DOCUMENT_ROOT<br /> SERVER_ADMIN<br /> SERVER_NAME<br /> SERVER_ADDR<br /> SERVER_PORT<br /> SERVER_PROTOCOL<br /> SERVER_SOFTWARE<br /> </td> <td> TIME_YEAR<br /> TIME_MON<br /> TIME_DAY<br /> TIME_HOUR<br /> TIME_MIN<br /> TIME_SEC<br /> TIME_WDAY<br /> TIME<br /> </td> <td> API_VERSION<br /> THE_REQUEST<br /> REQUEST_URI<br /> REQUEST_FILENAME<br /> IS_SUBREQ<br /> HTTPS<br /> </td> </tr> </table><div class="note"> <p>These variables all correspond to the similarly named HTTP MIME-headers, C variables of the Apache server or <code>struct tm</code> fields of the Unix system. Most are documented elsewhere in the Manual or in the CGI specification. Those that are special to mod_rewrite include:</p> <dl> <dt><code>IS_SUBREQ</code></dt> <dd>Will contain the text "true" if the request currently being processed is a sub-request, "false" otherwise. Sub-requests may be generated by modules that need to resolve additional files or URIs in order to complete their tasks.</dd> <dt><code>API_VERSION</code></dt> <dd>This is the version of the Apache module API (the internal interface between server and module) in the current httpd build, as defined in
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -