httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rbo...@apache.org
Subject svn commit: r157850 - httpd/httpd/trunk/docs/manual/mod/mod_rewrite.html.en httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml
Date Thu, 17 Mar 2005 01:47:46 GMT
Author: rbowen
Date: Wed Mar 16 17:47:45 2005
New Revision: 157850

URL: http://svn.apache.org/viewcvs?view=rev&rev=157850
Log:
Moved some of the gorey details out of the module reference doc and into
the supporting documentation. Might want to move some more, too. Haven't
decided yet.

Modified:
    httpd/httpd/trunk/docs/manual/mod/mod_rewrite.html.en
    httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml

Modified: httpd/httpd/trunk/docs/manual/mod/mod_rewrite.html.en
URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/docs/manual/mod/mod_rewrite.html.en?view=diff&r1=157849&r2=157850
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_rewrite.html.en (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_rewrite.html.en Wed Mar 16 17:47:45 2005
@@ -31,31 +31,6 @@
 <tr><th><a href="module-dict.html#Compatibility">Compatibility:</a></th><td>Available
in Apache 1.3 and later</td></tr></table>
 <h3>Summary</h3>
 
-      <blockquote>
-            <p>``The great thing about mod_rewrite is it gives you
-            all the configurability and flexibility of Sendmail.
-            The downside to mod_rewrite is that it gives you all
-            the configurability and flexibility of Sendmail.''</p>
-
-            <p class="cite">-- <cite>Brian Behlendorf</cite><br />
-            Apache Group</p>
-
-      </blockquote>
-
-      <blockquote>
-            <p>`` Despite the tons of examples and docs,
-            mod_rewrite is voodoo. Damned cool voodoo, but still
-            voodoo. ''</p>
-
-            <p class="cite">-- <cite>Brian Moore</cite><br />
-            bem@news.cmc.net</p>
-
-      </blockquote>
-
-
-      <p>Welcome to mod_rewrite, the Swiss Army Knife of URL
-      manipulation!</p>
-
       <p>This module uses a rule-based rewriting engine (based on a
       regular-expression parser) to rewrite requested URLs on the
       fly. It supports an unlimited number of rules and an
@@ -75,20 +50,8 @@
       sub-processing, external request redirection or even to an
       internal proxy throughput.</p>
 
-      <p>But all this functionality and flexibility has its
-      drawback: complexity. So don't expect to understand this
-      entire module in just one day.</p>
-
-      <p>This module was invented and originally written in April
-      1996 and gifted exclusively to the The Apache Group in July 1997
-      by</p>
-
-      <p class="indent">
-        <a href="http://www.engelschall.com/"><code>Ralf S.
-        Engelschall</code></a><br />
-         <a href="mailto:rse@engelschall.com"><code>rse@engelschall.com</code></a><br
/>
-         <a href="http://www.engelschall.com/"><code>www.engelschall.com</code></a>
-      </p>
+      <p>Further details, discussion, and examples, are provided in the
+      <a href="../rewrite/">detailed mod_rewrite documentation</a>.</p>
 </div>
 <div id="quickview"><h3 class="directives">Directives</h3>
 <ul id="toc">
@@ -104,138 +67,14 @@
 </ul>
 <h3>Topics</h3>
 <ul id="topics">
-<li><img alt="" src="../images/down.gif" /> <a href="#Internal">Internal
Processing</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#quoting">Quoting
Special Characters</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#InternalBackRefs">Regex
Back-Reference Availability</a></li>
 <li><img alt="" src="../images/down.gif" /> <a href="#EnvVar">Environment
Variables</a></li>
 <li><img alt="" src="../images/down.gif" /> <a href="#Solutions">Practical
Solutions</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>
-
-<h3><a name="InternalAPI" id="InternalAPI">API Phases</a></h3>
-
-      <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>
-
-
-<h3><a name="InternalRuleset" id="InternalRuleset">Ruleset Processing</a></h3>
- 
-      <p>Now when mod_rewrite is triggered in these two API phases, it
-      reads the configured rulesets from its configuration
-      structure (which itself was either created on startup for
-      per-server context or during the directory walk of the Apache
-      kernel for per-directory context). Then the URL rewriting
-      engine is started with the contained ruleset (one or more
-      rules together with their conditions). The operation of the
-      URL rewriting engine itself is exactly the same for both
-      configuration contexts. Only the final result processing is
-      different. </p>
-
-      <p>The order of rules in the ruleset is important because the
-      rewriting engine processes them in a special (and not very
-      obvious) order. The rule is this: The rewriting engine loops
-      through the ruleset rule by rule (<code class="directive"><a href="#rewriterule">RewriteRule</a></code>
directives) and
-      when a particular rule matches it optionally loops through
-      existing corresponding conditions (<code>RewriteCond</code>
-      directives). For historical reasons the conditions are given
-      first, and so the control flow is a little bit long-winded. See
-      Figure 1 for more details.</p>
-<p class="figure">
-      <img src="../images/mod_rewrite_fig1.gif" width="428" height="385" alt="[Needs graphics
capability to display]" /><br />
-      <dfn>Figure 1:</dfn>The control flow through the rewriting ruleset
-</p>
-      <p>As you can see, first the URL is matched against the
-      <em>Pattern</em> of each rule. When it fails mod_rewrite
-      immediately stops processing this rule and continues with the
-      next rule. If the <em>Pattern</em> matches, mod_rewrite looks
-      for corresponding rule conditions. If none are present, it
-      just substitutes the URL with a new value which is
-      constructed from the string <em>Substitution</em> and goes on
-      with its rule-looping. But if conditions exist, it starts an
-      inner loop for processing them in the order that they are
-      listed. For conditions the logic is different: we don't match
-      a pattern against the current URL. Instead we first create a
-      string <em>TestString</em> by expanding variables,
-      back-references, map lookups, <em>etc.</em> and then we try
-      to match <em>CondPattern</em> against it. If the pattern
-      doesn't match, the complete set of conditions and the
-      corresponding rule fails. If the pattern matches, then the
-      next condition is processed until no more conditions are
-      available. If all conditions match, processing is continued
-      with the substitution of the URL with
-      <em>Substitution</em>.</p>
-
-
-
-<h3><a name="quoting" id="quoting">Quoting Special Characters</a></h3>
+<h2><a name="quoting" id="quoting">Quoting Special Characters</a></h2>
 
       <p>As of Apache 1.3.20, special characters in
       <em>TestString</em> and <em>Substitution</em> strings can be
@@ -245,9 +84,9 @@
       dollar-sign character in a <em>Substitution</em> string by
       using '<code>\$</code>'; this keeps mod_rewrite from trying
       to treat it as a backreference.</p>
-
-
-<h3><a name="InternalBackRefs" id="InternalBackRefs">Regex Back-Reference Availability</a></h3>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"
/></a></div>
+<div class="section">
+<h2><a name="InternalBackRefs" id="InternalBackRefs">Regex Back-Reference Availability</a></h2>
 
       <p>One important thing here has to be remembered: Whenever you
       use parentheses in <em>Pattern</em> or in one of the
@@ -267,7 +106,6 @@
       reading the following documentation of the available
       directives.</p>
 
-
 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"
/></a></div>
 <div class="section">
 <h2><a name="EnvVar" id="EnvVar">Environment Variables</a></h2>
@@ -297,11 +135,11 @@
 <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>
+    <p>For numerous examples of common, and not-so-common, uses for
+    mod_rewrite, see the <a href="../rewrite/rewrite_guide.html">Rewrite
+    Guide</a>, and the <a href="../rewrite/rewrite_guide_advanced.html">Advanced
Rewrite
+    Guide</a> documents.</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>

Modified: httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml
URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml?view=diff&r1=157849&r2=157850
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml Wed Mar 16 17:47:45 2005
@@ -33,31 +33,6 @@
 <compatibility>Available in Apache 1.3 and later</compatibility>
 
 <summary>
-      <blockquote>
-            <p>``The great thing about mod_rewrite is it gives you
-            all the configurability and flexibility of Sendmail.
-            The downside to mod_rewrite is that it gives you all
-            the configurability and flexibility of Sendmail.''</p>
-
-            <p class="cite">-- <cite>Brian Behlendorf</cite><br />
-            Apache Group</p>
-
-      </blockquote>
-
-      <blockquote>
-            <p>`` Despite the tons of examples and docs,
-            mod_rewrite is voodoo. Damned cool voodoo, but still
-            voodoo. ''</p>
-
-            <p class="cite">-- <cite>Brian Moore</cite><br />
-            bem@news.cmc.net</p>
-
-      </blockquote>
-
-
-      <p>Welcome to mod_rewrite, the Swiss Army Knife of URL
-      manipulation!</p>
-
       <p>This module uses a rule-based rewriting engine (based on a
       regular-expression parser) to rewrite requested URLs on the
       fly. It supports an unlimited number of rules and an
@@ -77,151 +52,10 @@
       sub-processing, external request redirection or even to an
       internal proxy throughput.</p>
 
-      <p>But all this functionality and flexibility has its
-      drawback: complexity. So don't expect to understand this
-      entire module in just one day.</p>
-
-      <p>This module was invented and originally written in April
-      1996 and gifted exclusively to the The Apache Group in July 1997
-      by</p>
-
-      <p class="indent">
-        <a href="http://www.engelschall.com/"><code>Ralf S.
-        Engelschall</code></a><br />
-         <a
-        href="mailto:rse@engelschall.com"><code>rse@engelschall.com</code></a><br
/>
-         <a
-        href="http://www.engelschall.com/"><code>www.engelschall.com</code></a>
-      </p>
+      <p>Further details, discussion, and examples, are provided in the
+      <a href="../rewrite/">detailed mod_rewrite documentation</a>.</p>
 </summary>
 
-<section id="Internal"><title>Internal Processing</title>
-
-      <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>
-
-<section id="InternalAPI"><title>API Phases</title>
-
-      <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>
-</section>
-
-<section id="InternalRuleset"><title>Ruleset Processing</title>
- 
-      <p>Now when mod_rewrite is triggered in these two API phases, it
-      reads the configured rulesets from its configuration
-      structure (which itself was either created on startup for
-      per-server context or during the directory walk of the Apache
-      kernel for per-directory context). Then the URL rewriting
-      engine is started with the contained ruleset (one or more
-      rules together with their conditions). The operation of the
-      URL rewriting engine itself is exactly the same for both
-      configuration contexts. Only the final result processing is
-      different. </p>
-
-      <p>The order of rules in the ruleset is important because the
-      rewriting engine processes them in a special (and not very
-      obvious) order. The rule is this: The rewriting engine loops
-      through the ruleset rule by rule (<directive
-      module="mod_rewrite">RewriteRule</directive> directives) and
-      when a particular rule matches it optionally loops through
-      existing corresponding conditions (<code>RewriteCond</code>
-      directives). For historical reasons the conditions are given
-      first, and so the control flow is a little bit long-winded. See
-      Figure 1 for more details.</p>
-<p class="figure">
-      <img src="../images/mod_rewrite_fig1.gif" width="428"
-           height="385" alt="[Needs graphics capability to display]" /><br />
-      <dfn>Figure 1:</dfn>The control flow through the rewriting ruleset
-</p>
-      <p>As you can see, first the URL is matched against the
-      <em>Pattern</em> of each rule. When it fails mod_rewrite
-      immediately stops processing this rule and continues with the
-      next rule. If the <em>Pattern</em> matches, mod_rewrite looks
-      for corresponding rule conditions. If none are present, it
-      just substitutes the URL with a new value which is
-      constructed from the string <em>Substitution</em> and goes on
-      with its rule-looping. But if conditions exist, it starts an
-      inner loop for processing them in the order that they are
-      listed. For conditions the logic is different: we don't match
-      a pattern against the current URL. Instead we first create a
-      string <em>TestString</em> by expanding variables,
-      back-references, map lookups, <em>etc.</em> and then we try
-      to match <em>CondPattern</em> against it. If the pattern
-      doesn't match, the complete set of conditions and the
-      corresponding rule fails. If the pattern matches, then the
-      next condition is processed until no more conditions are
-      available. If all conditions match, processing is continued
-      with the substitution of the URL with
-      <em>Substitution</em>.</p>
-
-</section>
-
 <section id="quoting"><title>Quoting Special Characters</title>
 
       <p>As of Apache 1.3.20, special characters in
@@ -256,7 +90,6 @@
       directives.</p>
 
 </section>
-</section>
 
 <section id="EnvVar"><title>Environment Variables</title>
 
@@ -287,13 +120,13 @@
 
 <section id="Solutions"><title>Practical Solutions</title>
 
-      <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>
-</section>
+    <p>For numerous examples of common, and not-so-common, uses for
+    mod_rewrite, see the <a href="../rewrite/rewrite_guide.html">Rewrite
+    Guide</a>, and the <a
+    href="../rewrite/rewrite_guide_advanced.html">Advanced Rewrite
+    Guide</a> documents.</p>
 
+</section>
 
 <directivesynopsis>
 <name>RewriteEngine</name>



Mime
View raw message