You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by rb...@apache.org on 2011/10/10 14:54:12 UTC
svn commit: r1180930 - in /httpd/httpd/trunk/docs/manual:
mod/mod_setenvif.xml.ja mod/mod_setenvif.xml.ko mod/mod_setenvif.xml.tr
rewrite/tech.html.en
Author: rbowen
Date: Mon Oct 10 12:54:12 2011
New Revision: 1180930
URL: http://svn.apache.org/viewvc?rev=1180930&view=rev
Log:
Rebuilds varions transformation.
Modified:
httpd/httpd/trunk/docs/manual/mod/mod_setenvif.xml.ja
httpd/httpd/trunk/docs/manual/mod/mod_setenvif.xml.ko
httpd/httpd/trunk/docs/manual/mod/mod_setenvif.xml.tr
httpd/httpd/trunk/docs/manual/rewrite/tech.html.en
Modified: httpd/httpd/trunk/docs/manual/mod/mod_setenvif.xml.ja
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_setenvif.xml.ja?rev=1180930&r1=1180929&r2=1180930&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_setenvif.xml.ja [utf-8] (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_setenvif.xml.ja [utf-8] Mon Oct 10 12:54:12 2011
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 658546:1174747 (outdated) -->
+<!-- English Revision: 658546:1180828 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
Modified: httpd/httpd/trunk/docs/manual/mod/mod_setenvif.xml.ko
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_setenvif.xml.ko?rev=1180930&r1=1180929&r2=1180930&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_setenvif.xml.ko [euc-kr] (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_setenvif.xml.ko [euc-kr] Mon Oct 10 12:54:12 2011
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="EUC-KR" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
-<!-- English Revision: 151408:1174747 (outdated) -->
+<!-- English Revision: 151408:1180828 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
Modified: httpd/httpd/trunk/docs/manual/mod/mod_setenvif.xml.tr
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_setenvif.xml.tr?rev=1180930&r1=1180929&r2=1180930&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_setenvif.xml.tr [utf-8] (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_setenvif.xml.tr [utf-8] Mon Oct 10 12:54:12 2011
@@ -1,7 +1,7 @@
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.tr.xsl"?>
-<!-- English Revision: 658546:1174747 (outdated) -->
+<!-- English Revision: 658546:1180828 (outdated) -->
<!-- =====================================================
Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
Reviewed by: Orhan Berent <berent belgeler.org>
Modified: httpd/httpd/trunk/docs/manual/rewrite/tech.html.en
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/rewrite/tech.html.en?rev=1180930&r1=1180929&r2=1180930&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/rewrite/tech.html.en (original)
+++ httpd/httpd/trunk/docs/manual/rewrite/tech.html.en Mon Oct 10 12:54:12 2011
@@ -25,87 +25,85 @@
<p>This document discusses some of the technical details of mod_rewrite
and URL matching.</p>
</div>
-<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#Internal">Internal Processing</a></li>
-<li><img alt="" src="../images/down.gif" /> <a href="#InternalAPI">API Phases</a></li>
+<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#InternalAPI">API Phases</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#InternalRuleset">Ruleset Processing</a></li>
</ul><h3>See also</h3><ul class="seealso"><li><a href="../mod/mod_rewrite.html">Module documentation</a></li><li><a href="intro.html">mod_rewrite introduction</a></li><li><a href="remapping.html">Redirection and remapping</a></li><li><a href="access.html">Controlling access</a></li><li><a href="vhosts.html">Virtual hosts</a></li><li><a href="proxy.html">Proxying</a></li><li><a href="rewritemap.html">Using RewriteMap</a></li><li><a href="advanced.html">Advanced techniques</a></li><li><a href="avoid.html">When not to use mod_rewrite</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="Internal" id="Internal">Internal Processing</a></h2>
-
- <p>The internal processing of this module is very complex but
- needs to be explained once even to the average user to avoid
- common mistakes and to let you exploit its full
- functionality.</p>
-</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
<h2><a name="InternalAPI" id="InternalAPI">API Phases</a></h2>
- <p>First you have to understand that when Apache processes a
- HTTP request it does this in phases. A hook for each of these
- phases is provided by the Apache API. Mod_rewrite uses two of
- these hooks: the URL-to-filename translation hook which is
- used after the HTTP request has been read but before any
- authorization starts and the Fixup hook which is triggered
- after the authorization phases and after the per-directory
- config files (<code>.htaccess</code>) have been read, but
- before the content handler is activated.</p>
-
- <p>So, after a request comes in and Apache has determined the
- corresponding server (or virtual server) the rewriting engine
- starts processing of all mod_rewrite directives from the
- per-server configuration in the URL-to-filename phase. A few
- steps later when the final data directories are found, the
- per-directory configuration directives of mod_rewrite are
- triggered in the Fixup phase. In both situations mod_rewrite
- rewrites URLs either to new URLs or to filenames, although
- there is no obvious distinction between them. This is a usage
- of the API which was not intended to be this way when the API
- was designed, but as of Apache 1.x this is the only way
- mod_rewrite can operate. To make this point more clear
- remember the following two points:</p>
-
- <ol>
- <li>Although mod_rewrite rewrites URLs to URLs, URLs to
- filenames and even filenames to filenames, the API
- currently provides only a URL-to-filename hook. In Apache
- 2.0 the two missing hooks will be added to make the
- processing more clear. But this point has no drawbacks for
- the user, it is just a fact which should be remembered:
- Apache does more in the URL-to-filename hook than the API
- intends for it.</li>
-
- <li>
- Unbelievably mod_rewrite provides URL manipulations in
- per-directory context, <em>i.e.</em>, within
- <code>.htaccess</code> files, although these are reached
- a very long time after the URLs have been translated to
- filenames. It has to be this way because
- <code>.htaccess</code> files live in the filesystem, so
- processing has already reached this stage. In other
- words: According to the API phases at this time it is too
- late for any URL manipulations. To overcome this chicken
- and egg problem mod_rewrite uses a trick: When you
- manipulate a URL/filename in per-directory context
- mod_rewrite first rewrites the filename back to its
- corresponding URL (which is usually impossible, but see
- the <code>RewriteBase</code> directive below for the
- trick to achieve this) and then initiates a new internal
- sub-request with the new URL. This restarts processing of
- the API phases.
-
- <p>Again mod_rewrite tries hard to make this complicated
- step totally transparent to the user, but you should
- remember here: While URL manipulations in per-server
- context are really fast and efficient, per-directory
- rewrites are slow and inefficient due to this chicken and
- egg problem. But on the other hand this is the only way
- mod_rewrite can provide (locally restricted) URL
- manipulations to the average user.</p>
- </li>
- </ol>
+ <p>The Apache HTTP Server handles requests in several phases. At
+ each of these phases, one or more modules may be called upon to
+ handle that portion of the request lifecycle. Phases include things
+ like URL-to-filename translation, authentication, authorization,
+ content, and logging. (These is not an exhaustive list.)</p>
+
+ <p>mod_rewrite acts in two of these phases (or "hooks", as they are
+ sometimes called) to influence how URLs may be rewritten.</p>
+
+ <p>First, it uses the URL-to-filename translation hook, which occurs
+ after the HTTP request has been read, but before any authorization
+ starts. Secondly, it uses the Fixup hook, which is after the
+ authorizatin phases, and after per-directory configuration files
+ (<code>.htaccess</code> files) have been read, but before the
+ content handler is called.</p>
+
+ <p>So, after a request comes in and a corresponding server or
+ virtual host has been determined, the rewriting engine starts
+ processing any <code>mod_rewrite</code> directives appearing in the
+ per-server configuration. (ie, in the main server configuration file
+ and <code class="directive"><a href="../mod/core.html#virtualhost"><Virtualhost></a></code>
+ sections.) This happens in the URL-to-filename phase.</p>
+
+ <p>A few steps later, when the finaly data directories are found,
+ the per-directory configuration directives (<code>.htaccess</code>
+ files and <code class="directive"><a href="../mod/core.html#directory"><Directory></a></code> blocks) are applied. This
+ happens in the Fixup phase.</p>
+
+ <p>In each of these cases, mod_rewrite rewrites the
+ <code>REQUEST_URI</code> either to a new URI, or to a filename.</p>
+
+ <p>In per-directory context (ie, within <code>.htaccess</code> files
+ and <code>Directory</code> blocks), these rules are being applied
+ after a URI has already been translated to a filename. Because of
+ this, mod_rewrite temporarily translates the filename back into a URI,
+ by stripping off directory paty before appling the rules. (See the
+ <code class="directive"><a href="../mod/mod_rewrite.html#rewritebase">RewriteBase</a></code> directive to
+ see how you can further manipulate how this is handled.) Then, a new
+ internal subrequest is issued with the new URI. This restarts
+ processing of the API phases.</p>
+
+ <p>Because of this further manipulation of the URI in per-directory
+ context, you'll need to take care to craft your rewrite rules
+ differently in that context. In particular, remember that the
+ leading directory path will be stripped off of the URI that your
+ rewrite rules will see. Consider the examples below for further
+ clarification.</p>
+
+ <table class="bordered">
+
+ <tr>
+ <th>Location of rule</th>
+ <th>Rule</th>
+ </tr>
+
+ <tr>
+ <td>VirtualHost section</td>
+ <td>RewriteRule ^/images/(.+)\.jpg /images/$1.gif</td>
+ </tr>
+
+ <tr>
+ <td>.htaccess file in document root</td>
+ <td>RewriteRule ^images/(.+)\.jpg images/$1.gif</td>
+ </tr>
+
+ <tr>
+ <td>.htaccess file in images directory</td>
+ <td>RewriteRule ^(.+)\.jpg $1.gif</td>
+ </tr>
+
+ </table>
- <p>Don't forget these two points!</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="InternalRuleset" id="InternalRuleset">Ruleset Processing</a></h2>