home *** CD-ROM | disk | FTP | other *** search
/ Cricao de Sites - 650 Layouts Prontos / WebMasters.iso / Servidores / apache_2.2.8-win32-x86-no_ssl.msi / Data1.cab / _CF63B78CAEBEB9B039D57A05BBA89FF3 < prev    next >
Extensible Markup Language  |  2007-09-01  |  10KB  |  167 lines

  1. <?xml version="1.0" encoding="ISO-8859-1"?>
  2. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
  3. <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><!--
  4.         XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  5.               This file is generated from xml source: DO NOT EDIT
  6.         XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  7.       -->
  8. <title>Apache mod_rewrite Technical Details - Apache HTTP Server</title>
  9. <link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
  10. <link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
  11. <link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" />
  12. <link href="../images/favicon.ico" rel="shortcut icon" /></head>
  13. <body id="manual-page"><div id="page-header">
  14. <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>
  15. <p class="apache">Apache HTTP Server Version 2.2</p>
  16. <img alt="" src="../images/feather.gif" /></div>
  17. <div class="up"><a href="./index.html"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
  18. <div id="path">
  19. <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.2</a></div><div id="page-content"><div id="preamble"><h1>Apache mod_rewrite Technical Details</h1>
  20. <div class="toplang">
  21. <p><span>Available Languages: </span><a href="../en/rewrite/rewrite_tech.html" title="English"> en </a></p>
  22. </div>
  23.  
  24. <p>This document discusses some of the technical details of mod_rewrite
  25. and URL matching.</p>
  26. </div>
  27. <div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#Internal">Internal Processing</a></li>
  28. <li><img alt="" src="../images/down.gif" /> <a href="#InternalAPI">API Phases</a></li>
  29. <li><img alt="" src="../images/down.gif" /> <a href="#InternalRuleset">Ruleset Processing</a></li>
  30. </ul><h3>See also</h3><ul class="seealso"><li><a href="../mod/mod_rewrite.html">Module
  31. documentation</a></li><li><a href="rewrite_intro.html">mod_rewrite
  32. introduction</a></li><li><a href="rewrite_guide.html">Practical solutions to common
  33. problems</a></li><li><a href="rewrite_guide_advanced.html">Practical solutions to
  34. advanced problems</a></li></ul></div>
  35. <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
  36. <div class="section">
  37. <h2><a name="Internal" id="Internal">Internal Processing</a></h2>
  38.  
  39.       <p>The internal processing of this module is very complex but
  40.       needs to be explained once even to the average user to avoid
  41.       common mistakes and to let you exploit its full
  42.       functionality.</p>
  43. </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
  44. <div class="section">
  45. <h2><a name="InternalAPI" id="InternalAPI">API Phases</a></h2>
  46.  
  47.       <p>First you have to understand that when Apache processes a
  48.       HTTP request it does this in phases. A hook for each of these
  49.       phases is provided by the Apache API. Mod_rewrite uses two of
  50.       these hooks: the URL-to-filename translation hook which is
  51.       used after the HTTP request has been read but before any
  52.       authorization starts and the Fixup hook which is triggered
  53.       after the authorization phases and after the per-directory
  54.       config files (<code>.htaccess</code>) have been read, but
  55.       before the content handler is activated.</p>
  56.  
  57.       <p>So, after a request comes in and Apache has determined the
  58.       corresponding server (or virtual server) the rewriting engine
  59.       starts processing of all mod_rewrite directives from the
  60.       per-server configuration in the URL-to-filename phase. A few
  61.       steps later when the final data directories are found, the
  62.       per-directory configuration directives of mod_rewrite are
  63.       triggered in the Fixup phase. In both situations mod_rewrite
  64.       rewrites URLs either to new URLs or to filenames, although
  65.       there is no obvious distinction between them. This is a usage
  66.       of the API which was not intended to be this way when the API
  67.       was designed, but as of Apache 1.x this is the only way
  68.       mod_rewrite can operate. To make this point more clear
  69.       remember the following two points:</p>
  70.  
  71.       <ol>
  72.         <li>Although mod_rewrite rewrites URLs to URLs, URLs to
  73.         filenames and even filenames to filenames, the API
  74.         currently provides only a URL-to-filename hook. In Apache
  75.         2.0 the two missing hooks will be added to make the
  76.         processing more clear. But this point has no drawbacks for
  77.         the user, it is just a fact which should be remembered:
  78.         Apache does more in the URL-to-filename hook than the API
  79.         intends for it.</li>
  80.  
  81.         <li>
  82.           Unbelievably mod_rewrite provides URL manipulations in
  83.           per-directory context, <em>i.e.</em>, within
  84.           <code>.htaccess</code> files, although these are reached
  85.           a very long time after the URLs have been translated to
  86.           filenames. It has to be this way because
  87.           <code>.htaccess</code> files live in the filesystem, so
  88.           processing has already reached this stage. In other
  89.           words: According to the API phases at this time it is too
  90.           late for any URL manipulations. To overcome this chicken
  91.           and egg problem mod_rewrite uses a trick: When you
  92.           manipulate a URL/filename in per-directory context
  93.           mod_rewrite first rewrites the filename back to its
  94.           corresponding URL (which is usually impossible, but see
  95.           the <code>RewriteBase</code> directive below for the
  96.           trick to achieve this) and then initiates a new internal
  97.           sub-request with the new URL. This restarts processing of
  98.           the API phases. 
  99.  
  100.           <p>Again mod_rewrite tries hard to make this complicated
  101.           step totally transparent to the user, but you should
  102.           remember here: While URL manipulations in per-server
  103.           context are really fast and efficient, per-directory
  104.           rewrites are slow and inefficient due to this chicken and
  105.           egg problem. But on the other hand this is the only way
  106.           mod_rewrite can provide (locally restricted) URL
  107.           manipulations to the average user.</p>
  108.         </li>
  109.       </ol>
  110.  
  111.       <p>Don't forget these two points!</p>
  112. </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
  113. <div class="section">
  114. <h2><a name="InternalRuleset" id="InternalRuleset">Ruleset Processing</a></h2>
  115.  
  116.       <p>Now when mod_rewrite is triggered in these two API phases, it
  117.       reads the configured rulesets from its configuration
  118.       structure (which itself was either created on startup for
  119.       per-server context or during the directory walk of the Apache
  120.       kernel for per-directory context). Then the URL rewriting
  121.       engine is started with the contained ruleset (one or more
  122.       rules together with their conditions). The operation of the
  123.       URL rewriting engine itself is exactly the same for both
  124.       configuration contexts. Only the final result processing is
  125.       different. </p>
  126.  
  127.       <p>The order of rules in the ruleset is important because the
  128.       rewriting engine processes them in a special (and not very
  129.       obvious) order. The rule is this: The rewriting engine loops
  130.       through the ruleset rule by rule (<code class="directive"><a href="../mod/mod_rewrite.html#rewriterule">RewriteRule</a></code> directives) and
  131.       when a particular rule matches it optionally loops through
  132.       existing corresponding conditions (<code>RewriteCond</code>
  133.       directives). For historical reasons the conditions are given
  134.       first, and so the control flow is a little bit long-winded. See
  135.       Figure 1 for more details.</p>
  136. <p class="figure">
  137.       <img src="../images/mod_rewrite_fig1.gif" width="428" height="385" alt="[Needs graphics capability to display]" /><br />
  138.       <dfn>Figure 1:</dfn>The control flow through the rewriting ruleset
  139. </p>
  140.       <p>As you can see, first the URL is matched against the
  141.       <em>Pattern</em> of each rule. When it fails mod_rewrite
  142.       immediately stops processing this rule and continues with the
  143.       next rule. If the <em>Pattern</em> matches, mod_rewrite looks
  144.       for corresponding rule conditions. If none are present, it
  145.       just substitutes the URL with a new value which is
  146.       constructed from the string <em>Substitution</em> and goes on
  147.       with its rule-looping. But if conditions exist, it starts an
  148.       inner loop for processing them in the order that they are
  149.       listed. For conditions the logic is different: we don't match
  150.       a pattern against the current URL. Instead we first create a
  151.       string <em>TestString</em> by expanding variables,
  152.       back-references, map lookups, <em>etc.</em> and then we try
  153.       to match <em>CondPattern</em> against it. If the pattern
  154.       doesn't match, the complete set of conditions and the
  155.       corresponding rule fails. If the pattern matches, then the
  156.       next condition is processed until no more conditions are
  157.       available. If all conditions match, processing is continued
  158.       with the substitution of the URL with
  159.       <em>Substitution</em>.</p>
  160.  
  161. </div></div>
  162. <div class="bottomlang">
  163. <p><span>Available Languages: </span><a href="../en/rewrite/rewrite_tech.html" title="English"> en </a></p>
  164. </div><div id="footer">
  165. <p class="apache">Copyright 2007 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
  166. <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></div>
  167. </body></html>