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
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>
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>
21
<p><span>Available Languages: </span><a href="../en/rewrite/rewrite_tech.html" title="English"> en </a></p>
24
<p>This document discusses some of the technical details of mod_rewrite
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>
37
<h2><a name="Internal" id="Internal">Internal Processing</a></h2>
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
43
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
45
<h2><a name="InternalAPI" id="InternalAPI">API Phases</a></h2>
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>
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>
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
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
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>
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>
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
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>
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
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>
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 2006 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>
b'\\ No newline at end of file'