Mailing List Archive: Apache: CVS

svn commit: r832627 - in /httpd/httpd/trunk/docs/manual/mod: mod_rewrite.html.en mod_rewrite.xml

Index | Next | Previous | View Threaded

noirin at apache

Nov 3, 2009, 4:10 PM

Post #1 of 1 (105 views)
Permalink

svn commit: r832627 - in /httpd/httpd/trunk/docs/manual/mod: mod_rewrite.html.en mod_rewrite.xml

Author: noirin
Date: Wed Nov 4 00:10:36 2009
New Revision: 832627

URL: http://svn.apache.org/viewvc?rev=832627&view=rev
Log:
Split RewriteCond into two sections, brought TestString section up to date.

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/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_rewrite.html.en?rev=832627&r1=832626&r2=832627&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_rewrite.html.en (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_rewrite.html.en Wed Nov 4 00:10:36 2009
@@ -90,10 +90,11 @@
<code>.htaccess</code> file where you want to use <code class="directive"><a href="#rewriterule">RewriteRule</a></code> directives. 

The example below demonstrates how to map
- http://example.com/foo/index.html to
- /home/www/example/newsite.html, in a <code>.htaccess</code> file. This
- assumes that the content available at
- http://example.com/ is on disk at /home/www/example/
+ <code>http://example.com/foo/index.html</code> to
+ <code>/home/www/example/newsite.html</code>, in a <code>.htaccess</code>
+ file. This assumes that the content available at
+ <code>http://example.com/</code> is on disk at
+ <code>/home/www/example/</code>.
<div class="example"><pre>
RewriteEngine On
RewriteBase /foo/
@@ -114,47 +115,45 @@
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_rewrite</td></tr>
</table>
- The <code class="directive">RewriteCond</code> directive defines a
- rule condition. One or more <code class="directive">RewriteCond</code>
- can precede a <code class="directive"><a href="#rewriterule">RewriteRule</a></code>
- directive. The following rule is then only used if both
- the current state of the URI matches its pattern, and if these conditions are met.
-
- TestString is a string which can contain the
- following expanded constructs in addition to plain text:
-
+ The <code class="directive"><a href="#rewritecond">RewriteCond</a></code>
+ directive defines a rule condition. One or more <code class="directive"><a href="#rewritecond">RewriteCond</a></code>
+ conditions can precede a <code class="directive"><a href="#rewriterule">RewriteRule</a></code> directive. The following rewrite rule is then
+ used only if these conditions are met, and if the URI matches the pattern
+ specified in the rule.
+
+ <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="TestString" id="TestString">TestString</a></h2>
+
+ <code>TestString</code> can contain plain text, any of the
+ following expanded constructs, or both.
<ul>
<li>
RewriteRule backreferences: These are
backreferences of the form <code>$N</code>
- (0 <= N <= 9), which provide access to the grouped
- parts (in parentheses) of the pattern, from the
- <code>RewriteRule</code> which is subject to the current
- set of <code>RewriteCond</code> conditions.
- </li>
+ (1 <= N <= 9). They provide access to the grouped
+ parts of the current <code>RewriteRule</code> pattern. The grouped
+ parts of the pattern are those in parentheses.</li>
<li>
RewriteCond backreferences: These are
backreferences of the form <code>%N</code>
- (1 <= N <= 9), which provide access to the grouped
- parts (again, in parentheses) of the pattern, from the last matched
- <code>RewriteCond</code> in the current set
- of conditions.
- </li>
+ (1 <= N <= 9). They provide access to the grouped
+ parts of the last-matched <code>RewriteCond</code> pattern. The
+ grouped parts of the pattern are those in parentheses.</li>
<li>
RewriteMap expansions: These are
expansions of the form <code>${mapname:key|default}</code>.
- See <a href="#mapfunc">the documentation for
- RewriteMap</a> for more details.
+ See the <a href="#mapfunc">RewriteMap documentation</a>
+ for more details.
</li>
<li>
- Server-Variables: These are variables of
+ Server variables: These are variables of
the form
- <code>%{</code> NAME_OF_VARIABLE
- <code>}</code>
- where NAME_OF_VARIABLE can be a string taken
- from the following list:
-
- <table>
+ <code>%{ NAME_OF_VARIABLE }</code>,
+ where NAME_OF_VARIABLE is one of the server variables from
+ the table below:
+
+ <table>

<tr>
<th>HTTP headers:</th> <th>connection & request:</th> <th />
@@ -223,34 +222,23 @@
</td>
</tr>
</table>
-
- These variables all
- correspond to the similarly named HTTP
- MIME-headers, C variables of the Apache server or
- <code>struct tm</code> fields of the Unix system.
- Most are documented elsewhere in the Manual or in
- the CGI specification. Those that are special to
- mod_rewrite include those below.
- <div class="note">
+ </li></ul>
+ <div class="note">The following variables are specific to
+ <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>:
<dl>
<dt><code>IS_SUBREQ</code></dt>

- <dd>Will contain the text "true" if the request
- currently being processed is a sub-request,
+ <dd>Contains the text "true" if the request
+ currently being processed is a sub-request, or
"false" otherwise. Sub-requests may be generated
by modules that need to resolve additional files
or URIs in order to complete their tasks.</dd>

<dt><code>API_VERSION</code></dt>

- <dd>This is the version of the Apache module API
- (the internal interface between server and
- module) in the current httpd build, as defined in
- include/ap_mmn.h. The module API version
- corresponds to the version of Apache in use (in
- the release version of Apache 1.3.14, for
- instance, it is 19990320:10), but is mainly of
- interest to module authors.</dd>
+ <dd>The version of the Apache module API contained in the
+ current httpd build, as defined in
+ include/ap_mmn.h.</dd>

<dt><code>THE_REQUEST</code></dt>

@@ -263,108 +251,79 @@
<dt><code>REQUEST_URI</code></dt>

<dd>The resource requested in the HTTP request
- line. (In the example above, this would be
- "/index.html".)</dd>
+ line.</dd>

<dt><code>REQUEST_FILENAME</code></dt>

- <dd>The full local filesystem path to the file or
+ <dd>The full local filesystem path of the file or
script matching the request.</dd>

<dt><code>HTTPS</code></dt>

- <dd>Will contain the text "on" if the connection is
- using SSL/TLS, or "off" otherwise. (This variable
- can be safely used regardless of whether or not
- <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> is loaded).</dd>
+ <dd>Contains the text "on" if the connection is
+ using SSL/TLS, or "off" otherwise. This variable
+ does not depend on <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> being loaded.</dd>

</dl>
</div>
- </li>
- </ul>

- Other things you should be aware of:
-
- <ol>
- <li>
- The variables SCRIPT_FILENAME and REQUEST_FILENAME
- contain the same value - the value of the
+ Note that the <code>SCRIPT_FILENAME</code> and
+ <code>REQUEST_FILENAME</code>
+ variables both contain the value of the
<code>filename</code> field of the internal
- <code>request_rec</code> structure of the Apache server.
- The first name is the commonly known CGI variable name
- while the second is the appropriate counterpart of
- REQUEST_URI (which contains the value of the
- <code>uri</code> field of <code>request_rec</code>).
- If a substitution occurred and the rewriting continues,
- the value of both variables will be updated accordingly.
- If used in per-server context (i.e., before the
- request is mapped to the filesystem) SCRIPT_FILENAME and
- REQUEST_FILENAME cannot contain the full local filesystem
- path since the path is unknown at this stage of processing.
- Both variables will initially contain the value of REQUEST_URI
- in that case. In order to obtain the full local filesystem
- path of the request in per-server context, use an URL-based
+ <code>request_rec</code> structure.
+ If a substitution occurs and rewriting continues,
+ the value of both variables will be updated accordingly.
+ In a per-server context, before the
+ request is mapped to the filesystem, these variables contain the value
+ of <code>REQUEST_URI</code>, because the full filesystem path is not
+ yet known. To obtain the full filesystem
+ path of a request in a per-server context, use a URL-based
look-ahead <code>%{LA-U:REQUEST_FILENAME}</code> to determine
- the final value of REQUEST_FILENAME.</li>
+ the final value of <code>REQUEST_FILENAME</code>.

- <li>
- <code>%{ENV:variable}</code>, where variable can be
- any environment variable, is also available.
- This is looked-up via internal
- Apache structures and (if not found there) via
- <code>getenv()</code> from the Apache server process.</li>
+ Other available variables include the following:
+ <ul><li>
+ <code>%{ENV:variable}</code>, where variable can be
+ any environment variable.</li>

<li>
- <code>%{SSL:variable}</code>, where variable is the
+ <code>%{SSL:variable}</code>, where variable is the
name of an <a href="mod_ssl.html#envvars">SSL environment
- variable</a>, can be used whether or not
- <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> is loaded, but will always expand to
- the empty string if it is not. Example:
- <code>%{SSL:SSL_CIPHER_USEKEYSIZE}</code> may expand to
- <code>128</code>.</li>
-
+ variable</a>. If <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> is not loaded, this
+ will always expand to the empty string.</li>
<li>
- <code>%{HTTP:header}</code>, where header can be
- any HTTP MIME-header name, can always be used to obtain the
- value of a header sent in the HTTP request.
- Example: <code>%{HTTP:Proxy-Connection}</code> is
- the value of the HTTP header
- ``<code>Proxy-Connection:</code>''.
- If a HTTP header is used in a condition this header is added to
- the Vary header of the response in case the condition evaluates to
- to true for the request. It is not added if the
- condition evaluates to false for the request. Adding the HTTP header
- to the Vary header of the response is needed for proper caching.
- It has to be kept in mind that conditions follow a short circuit
- logic in the case of the '<code>ornext|OR</code>' flag
- so that certain conditions might not be evaluated at all.</li>
-
+ <code>%{HTTP:header}</code>, where header can be
+ any HTTP MIME-header name. For example,
+ <code>%{HTTP:Proxy-Connection}</code> is the value of the HTTP header
+ ``<code>Proxy-Connection:</code>''. If a HTTP header is used in a
+ condition, and the condition evaluates to <code>true</code>, then that
+ header is added to the Vary header of the response. This is used to
+ ensure proper caching.
+ If a previous condition has evaluated to <code>true</code> and the
+ '<code>ornext|OR</code>' flag is in use, later
+ conditions are not evaluated, and therefore headers are not added to the
+ Vary header.</li>
<li>
- <code>%{LA-U:variable}</code> can be used for look-aheads which perform
- an internal (URL-based) sub-request to determine the final
- value of variable. This can be used to access
- variable for rewriting which is not available at the current
- stage, but will be set in a later phase.
- For instance, to rewrite according to the
- <code>REMOTE_USER</code> variable from within the
- per-server context (<code>httpd.conf</code> file) you must
- use <code>%{LA-U:REMOTE_USER}</code> - this
- variable is set by the authorization phases, which come
- after the URL translation phase (during which mod_rewrite
- operates).
- On the other hand, because mod_rewrite implements
- its per-directory context (<code>.htaccess</code> file) via
- the Fixup phase of the API and because the authorization
- phases come before this phase, you just can use
- <code>%{REMOTE_USER}</code> in that context.</li>
-
- <li>
- <code>%{LA-F:variable}</code> can be used to perform an internal
- (filename-based) sub-request, to determine the final value
- of variable. Most of the time, this is the same as
- LA-U above.</li>
- </ol>
+ <code>%{LA-U:variable}</code>, which is used to perform
+ an internal URL-based sub-request, to determine the final
+ value of variable. This can be used to access the value of
+ a variable which is to be set in a later phase. For example, the
+ <code>REMOTE_USER</code> variable is set in the authorization phase of
+ processing. This comes after the URL translation phase, where rewrite
+ rules in <code>httpd.conf</code> are applied, but before the fixup
+ phase, where rewrite rules in a <code>.htaccess</code> file are applied.
+ Therefore, to obtain the value of the <code>REMOTE_USER</code> variable
+ within <code>httpd.conf</code>, you must use <code>%{LA-U:REMOTE_USER}</code>. To obtain the value of the
+ <code>REMOTE_USER</code> variable within a <code>.htaccess</code> file,
+ simply use <code>%{REMOTE_USER}</code></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="CondPattern" id="CondPattern">CondPattern</a></h2>
+
CondPattern is the condition pattern,
a regular expression which is applied to the
current instance of the TestString.
@@ -536,6 +495,7 @@
or your browser identifies itself as something non-standard), you get
the std (standard) homepage.

+</div>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>

Modified: httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml?rev=832627&r1=832626&r2=832627&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml Wed Nov 4 00:10:36 2009
@@ -516,10 +516,11 @@
module="mod_rewrite">RewriteRule</directive> directives. 

The example below demonstrates how to map
- http://example.com/foo/index.html to
- /home/www/example/newsite.html, in a <code>.htaccess</code> file. This
- assumes that the content available at
- http://example.com/ is on disk at /home/www/example/
+ <code>http://example.com/foo/index.html</code> to
+ <code>/home/www/example/newsite.html</code>, in a <code>.htaccess</code>
+ file. This assumes that the content available at
+ <code>http://example.com/</code> is on disk at
+ <code>/home/www/example/</code>.
<example>
<pre>
RewriteEngine On
@@ -543,49 +544,46 @@
<override>FileInfo</override>

<usage>
- The <directive>RewriteCond</directive> directive defines a
- rule condition. One or more <directive>RewriteCond</directive>
- can precede a <directive module="mod_rewrite">RewriteRule</directive>
- directive. The following rule is then only used if both
- the current state of the URI matches its pattern, and if these conditions are met.
-
- TestString is a string which can contain the
- following expanded constructs in addition to plain text:
-
+ The <directive module="mod_rewrite">RewriteCond</directive>
+ directive defines a rule condition. One or more <directive
+ module="mod_rewrite">RewriteCond</directive>
+ conditions can precede a <directive module="mod_rewrite"
+ >RewriteRule</directive> directive. The following rewrite rule is then
+ used only if these conditions are met, and if the URI matches the pattern
+ specified in the rule.
+
+ <section id="TestString">
+ <title>TestString</title>
+ <code>TestString</code> can contain plain text, any of the
+ following expanded constructs, or both.
<ul>
<li>
RewriteRule backreferences: These are
backreferences of the form <code>$N</code>
- (0 <= N <= 9), which provide access to the grouped
- parts (in parentheses) of the pattern, from the
- <code>RewriteRule</code> which is subject to the current
- set of <code>RewriteCond</code> conditions.
- </li>
+ (1 <= N <= 9). They provide access to the grouped
+ parts of the current <code>RewriteRule</code> pattern. The grouped
+ parts of the pattern are those in parentheses.</li>
<li>
RewriteCond backreferences: These are
backreferences of the form <code>%N</code>
- (1 <= N <= 9), which provide access to the grouped
- parts (again, in parentheses) of the pattern, from the last matched
- <code>RewriteCond</code> in the current set
- of conditions.
- </li>
+ (1 <= N <= 9). They provide access to the grouped
+ parts of the last-matched <code>RewriteCond</code> pattern. The
+ grouped parts of the pattern are those in parentheses.</li>
<li>
RewriteMap expansions: These are
expansions of the form <code
>${mapname:key|default}</code>.
- See <a href="#mapfunc">the documentation for
- RewriteMap</a> for more details.
+ See the <a href="#mapfunc">RewriteMap documentation</a>
+ for more details.
</li>
<li>
- Server-Variables: These are variables of
+ Server variables: These are variables of
the form
- <code>%{</code> NAME_OF_VARIABLE
- <code>}</code>
- where NAME_OF_VARIABLE can be a string taken
- from the following list:
-
- <table>
+ <code>%{ NAME_OF_VARIABLE }</code>,
+ where NAME_OF_VARIABLE is one of the server variables from
+ the table below:
+
+ <table>
<columnspec><column width=".3"/><column width=".3"/>
<column width=".3"/></columnspec>
<tr>
@@ -655,34 +653,23 @@
</td>
</tr>
</table>
-
- These variables all
- correspond to the similarly named HTTP
- MIME-headers, C variables of the Apache server or
- <code>struct tm</code> fields of the Unix system.
- Most are documented elsewhere in the Manual or in
- the CGI specification. Those that are special to
- mod_rewrite include those below.
- <note>
+ </li></ul>
+ <note>The following variables are specific to
+ <module>mod_rewrite</module>:
<dl>
<dt><code>IS_SUBREQ</code></dt>

- <dd>Will contain the text "true" if the request
- currently being processed is a sub-request,
+ <dd>Contains the text "true" if the request
+ currently being processed is a sub-request, or
"false" otherwise. Sub-requests may be generated
by modules that need to resolve additional files
or URIs in order to complete their tasks.</dd>

<dt><code>API_VERSION</code></dt>

- <dd>This is the version of the Apache module API
- (the internal interface between server and
- module) in the current httpd build, as defined in
- include/ap_mmn.h. The module API version
- corresponds to the version of Apache in use (in
- the release version of Apache 1.3.14, for
- instance, it is 19990320:10), but is mainly of
- interest to module authors.</dd>
+ <dd>The version of the Apache module API contained in the
+ current httpd build, as defined in
+ include/ap_mmn.h.</dd>

<dt><code>THE_REQUEST</code></dt>

@@ -695,108 +682,78 @@
<dt><code>REQUEST_URI</code></dt>

<dd>The resource requested in the HTTP request
- line. (In the example above, this would be
- "/index.html".)</dd>
+ line.</dd>

<dt><code>REQUEST_FILENAME</code></dt>

- <dd>The full local filesystem path to the file or
+ <dd>The full local filesystem path of the file or
script matching the request.</dd>

<dt><code>HTTPS</code></dt>

- <dd>Will contain the text "on" if the connection is
- using SSL/TLS, or "off" otherwise. (This variable
- can be safely used regardless of whether or not
- <module>mod_ssl</module> is loaded).</dd>
+ <dd>Contains the text "on" if the connection is
+ using SSL/TLS, or "off" otherwise. This variable
+ does not depend on <module>mod_ssl</module> being loaded.</dd>

</dl>
</note>
- </li>
- </ul>
-
- Other things you should be aware of:

- <ol>
- <li>
- The variables SCRIPT_FILENAME and REQUEST_FILENAME
- contain the same value - the value of the
+ Note that the <code>SCRIPT_FILENAME</code> and
+ <code>REQUEST_FILENAME</code>
+ variables both contain the value of the
<code>filename</code> field of the internal
- <code>request_rec</code> structure of the Apache server.
- The first name is the commonly known CGI variable name
- while the second is the appropriate counterpart of
- REQUEST_URI (which contains the value of the
- <code>uri</code> field of <code>request_rec</code>).
- If a substitution occurred and the rewriting continues,
- the value of both variables will be updated accordingly.
- If used in per-server context (i.e., before the
- request is mapped to the filesystem) SCRIPT_FILENAME and
- REQUEST_FILENAME cannot contain the full local filesystem
- path since the path is unknown at this stage of processing.
- Both variables will initially contain the value of REQUEST_URI
- in that case. In order to obtain the full local filesystem
- path of the request in per-server context, use an URL-based
+ <code>request_rec</code> structure.
+ If a substitution occurs and rewriting continues,
+ the value of both variables will be updated accordingly.
+ In a per-server context, before the
+ request is mapped to the filesystem, these variables contain the value
+ of <code>REQUEST_URI</code>, because the full filesystem path is not
+ yet known. To obtain the full filesystem
+ path of a request in a per-server context, use a URL-based
look-ahead <code>%{LA-U:REQUEST_FILENAME}</code> to determine
- the final value of REQUEST_FILENAME.</li>
+ the final value of <code>REQUEST_FILENAME</code>.

- <li>
- <code>%{ENV:variable}</code>, where variable can be
- any environment variable, is also available.
- This is looked-up via internal
- Apache structures and (if not found there) via
- <code>getenv()</code> from the Apache server process.</li>
+ Other available variables include the following:
+ <ul><li>
+ <code>%{ENV:variable}</code>, where variable can be
+ any environment variable.</li>

<li>
- <code>%{SSL:variable}</code>, where variable is the
+ <code>%{SSL:variable}</code>, where variable is the
name of an <a href="mod_ssl.html#envvars">SSL environment
- variable</a>, can be used whether or not
- <module>mod_ssl</module> is loaded, but will always expand to
- the empty string if it is not. Example:
- <code>%{SSL:SSL_CIPHER_USEKEYSIZE}</code> may expand to
- <code>128</code>.</li>
-
+ variable</a>. If <module>mod_ssl</module> is not loaded, this
+ will always expand to the empty string.</li>
<li>
- <code>%{HTTP:header}</code>, where header can be
- any HTTP MIME-header name, can always be used to obtain the
- value of a header sent in the HTTP request.
- Example: <code>%{HTTP:Proxy-Connection}</code> is
- the value of the HTTP header
- ``<code>Proxy-Connection:</code>''.
- If a HTTP header is used in a condition this header is added to
- the Vary header of the response in case the condition evaluates to
- to true for the request. It is not added if the
- condition evaluates to false for the request. Adding the HTTP header
- to the Vary header of the response is needed for proper caching.
- It has to be kept in mind that conditions follow a short circuit
- logic in the case of the '<code>ornext|OR</code>' flag
- so that certain conditions might not be evaluated at all.</li>
-
+ <code>%{HTTP:header}</code>, where header can be
+ any HTTP MIME-header name. For example,
+ <code>%{HTTP:Proxy-Connection}</code> is the value of the HTTP header
+ ``<code>Proxy-Connection:</code>''. If a HTTP header is used in a
+ condition, and the condition evaluates to <code>true</code>, then that
+ header is added to the Vary header of the response. This is used to
+ ensure proper caching.
+ If a previous condition has evaluated to <code>true</code> and the
+ '<code>ornext|OR</code>' flag is in use, later
+ conditions are not evaluated, and therefore headers are not added to the
+ Vary header.</li>
<li>
- <code>%{LA-U:variable}</code> can be used for look-aheads which perform
- an internal (URL-based) sub-request to determine the final
- value of variable. This can be used to access
- variable for rewriting which is not available at the current
- stage, but will be set in a later phase.
- For instance, to rewrite according to the
- <code>REMOTE_USER</code> variable from within the
- per-server context (<code>httpd.conf</code> file) you must
- use <code>%{LA-U:REMOTE_USER}</code> - this
- variable is set by the authorization phases, which come
- after the URL translation phase (during which mod_rewrite
- operates).
- On the other hand, because mod_rewrite implements
- its per-directory context (<code>.htaccess</code> file) via
- the Fixup phase of the API and because the authorization
- phases come before this phase, you just can use
- <code>%{REMOTE_USER}</code> in that context.</li>
-
- <li>
- <code>%{LA-F:variable}</code> can be used to perform an internal
- (filename-based) sub-request, to determine the final value
- of variable. Most of the time, this is the same as
- LA-U above.</li>
- </ol>
+ <code>%{LA-U:variable}</code>, which is used to perform
+ an internal URL-based sub-request, to determine the final
+ value of variable. This can be used to access the value of
+ a variable which is to be set in a later phase. For example, the
+ <code>REMOTE_USER</code> variable is set in the authorization phase of
+ processing. This comes after the URL translation phase, where rewrite
+ rules in <code>httpd.conf</code> are applied, but before the fixup
+ phase, where rewrite rules in a <code>.htaccess</code> file are applied.
+ Therefore, to obtain the value of the <code>REMOTE_USER</code> variable
+ within <code>httpd.conf</code>, you must use <code
+ >%{LA-U:REMOTE_USER}</code>. To obtain the value of the
+ <code>REMOTE_USER</code> variable within a <code>.htaccess</code> file,
+ simply use <code>%{REMOTE_USER}</code></li>
+ </ul>
+ </section>

+ <section id="CondPattern">
+ <title>CondPattern</title>
CondPattern is the condition pattern,
a regular expression which is applied to the
current instance of the TestString.
@@ -972,6 +929,7 @@
or your browser identifies itself as something non-standard), you get
the std (standard) homepage.

+</section>
</usage>

</directivesynopsis>

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads