Commit ff85f6ca authored by Richard Bowen's avatar Richard Bowen
Browse files

Rebuilds varions transformation.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1180930 13f79535-47bb-0310-9956-ffa450edef68
parent 256e130f
Loading
Loading
Loading
Loading
+1 −1
Original line number Diff line number Diff line
<?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
+1 −1
Original line number Diff line number Diff line
<?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
+1 −1
Original line number Diff line number Diff line
<?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>
+73 −75
Original line number Diff line number Diff line
@@ -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>Don't forget these two points!</p>
    <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">&lt;Virtualhost&gt;</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">&lt;Directory&gt;</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>

</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>