mirror of
https://github.com/apache/httpd.git
synced 2025-09-11 09:30:48 +03:00
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@729539 13f79535-47bb-0310-9956-ffa450edef68
453 lines
16 KiB
XML
453 lines
16 KiB
XML
<?xml version='1.0' encoding='UTF-8' ?>
|
|
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
|
|
<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
|
|
<!-- $LastChangedRevision$ -->
|
|
|
|
<!--
|
|
Licensed to the Apache Software Foundation (ASF) under one or more
|
|
contributor license agreements. See the NOTICE file distributed with
|
|
this work for additional information regarding copyright ownership.
|
|
The ASF licenses this file to You under the Apache License, Version 2.0
|
|
(the "License"); you may not use this file except in compliance with
|
|
the License. You may obtain a copy of the License at
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
Unless required by applicable law or agreed to in writing, software
|
|
distributed under the License is distributed on an "AS IS" BASIS,
|
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
See the License for the specific language governing permissions and
|
|
limitations under the License.
|
|
-->
|
|
|
|
<manualpage metafile="rewrite_flags.xml.meta">
|
|
<parentdocument href="./">Rewrite</parentdocument>
|
|
|
|
<title>Apache mod_rewrite Flags</title>
|
|
|
|
<summary>
|
|
<p>This document discusses the flags which are available to the
|
|
<directive module="mod_rewrite">RewriteRule</directive> directive,
|
|
providing detailed explanations and examples. This is not necessarily
|
|
a comprehensive list of all flags available, so be sure to also
|
|
consult the reference documentation.</p>
|
|
</summary>
|
|
|
|
<seealso><a href="../mod/mod_rewrite.html">Module documentation</a></seealso>
|
|
<seealso><a href="rewrite_tech.html">Technical details</a></seealso>
|
|
<seealso><a href="rewrite_guide.html">Rewrite Guide - useful examples</a></seealso>
|
|
<seealso><a href="rewrite_guide_advanced.html">Advanced Rewrite Guide -
|
|
advanced useful examples</a></seealso>
|
|
|
|
<section id="introduction"><title>Introduction</title>
|
|
<p><directive module="mod_rewrite">RewriteRule</directive>s can have
|
|
their behavior modified by one or more flags. Flags are included in
|
|
square brackets at the end of the rule, and multiple flags are separated
|
|
by commas.</p>
|
|
<example>
|
|
RewriteRule pattern target [Flag1,Flag2,Flag3]
|
|
</example>
|
|
|
|
<p>The flags all have a short form, such as <code>CO</code>, as well as
|
|
a longer form, such as <code>cookie</code>. Some flags take one or more
|
|
arguments. Flags are not case sensitive.</p>
|
|
|
|
</section>
|
|
|
|
<section id="flags"><title>The flags</title>
|
|
|
|
<p>Each flag has a long and short form. While it is most common to use
|
|
the short form, it is recommended that you familiarize yourself with the
|
|
long form, so that you remember what each flag is supposed to do.</p>
|
|
|
|
<p>Presented here are each of the available flags, along with an example
|
|
of how you might use them.</p>
|
|
|
|
<section id="flag_c"><title>C|chain</title>
|
|
<p>The [C] or [chain] flag indicates that the <directive
|
|
module="mod_rewrite">RewriteRule</directive> is chained to the next
|
|
rule. That is, if the rule matches, then it is processed as usual and
|
|
control moves on to the next rule. However, if it does not match, then
|
|
the next rule, and any other rules that are chained together, will be
|
|
skipped.</p>
|
|
|
|
</section>
|
|
|
|
<section id="flag_co"><title>CO|cookie</title>
|
|
<p>The [CO], or [cookie] flag, allows you to set a cookie when a
|
|
particular <directive module="mod_rewrite">RewriteRule</directive>
|
|
matches. The argument consists of three required fields and two optional
|
|
fields.</p>
|
|
<p>You must declare a name and value for the cookie to be set, and the
|
|
domain for which you wish the cookie to be valid. You may optionally set
|
|
the lifetime of the cookie, and the path for which it should be
|
|
returned.</p>
|
|
<p>By default, the lifetime of the cookie is the current browser
|
|
session.</p>
|
|
<p>By default, the path for which the cookie will be valid is "/" - that
|
|
is, the entire website.</p>
|
|
<p>Several examples are offered here:</p>
|
|
|
|
<example>
|
|
RewriteEngine On<br />
|
|
RewriteRule ^/index\.html - [CO=frontdoor:yes:.apache.org:1440:/]
|
|
</example>
|
|
|
|
<p>This rule doesn't rewrite the request (the "-" rewrite target tells
|
|
mod_rewrite to pass the request through unchanged) but sets a cookie
|
|
called 'frontdoor' to a value of 'yes'. The cookie is valid for any host
|
|
in the <code>.apache.org</code> domain. It will be set to expire in 1440
|
|
minutes (24 hours) and will be returned for all URIs.</p>
|
|
|
|
</section>
|
|
|
|
<section id="flag_e"><title>E|env</title>
|
|
<p>With the [E], or [env] flag, you can set the value of an environment
|
|
variable. Note that some environment variables may be set after the rule
|
|
is run, thus unsetting what you have set. See <a href="../env.html">the
|
|
Environment Variables document</a> for more details on how Environment
|
|
variables work.</p>
|
|
|
|
<p>The following example sets an evironment variable called 'image' to a
|
|
value of '1' if the requested URI is an image file. Then, that
|
|
environment variable is used to exclude those requests from the access
|
|
log.</p>
|
|
|
|
<example>
|
|
RewriteRule \.(png|gif|jpg) - [E=image:1]<br />
|
|
CustomLog logs/access_log combined env=!image
|
|
</example>
|
|
|
|
<p>Note that this same effect can be obtained using <directive
|
|
module="mod_setenvif">SetEnvIf</directive>. This technique is offered as
|
|
an example, not as a recommendation.</p>
|
|
</section>
|
|
|
|
<section id="flag_f"><title>F|forbidden</title>
|
|
<p>Using the [F] flag causes Apache to return a 403 Forbidden status
|
|
code to the client. While the same behavior can be accomplished using
|
|
the <directive module="mod_access">Deny</directive> directive, this
|
|
allows more flexibility in assigning a Forbidden status.</p>
|
|
|
|
<p>The following rule will forbid <code>.exe</code> files from being
|
|
downloaded from your server.</p>
|
|
|
|
<example>
|
|
RewriteRule \.exe - [F]
|
|
</example>
|
|
|
|
<p>This example uses the "-" syntax for the rewrite target, which means
|
|
that the requested URI is not modified. There's no reason to rewrite to
|
|
another URI, if you're going to forbid the request.</p>
|
|
|
|
</section>
|
|
|
|
<section id="flag_g"><title>G|gone</title>
|
|
<p>The [G] flag forces Apache to return a 410 Gone status with the
|
|
response. This indicates that a resource used to be available, but is no
|
|
longer available.</p>
|
|
|
|
<p>As with the [F] flag, you will typically use the "-" syntax for the
|
|
rewrite target when using the [G] flag:</p>
|
|
|
|
<example>
|
|
RewriteRule oldproduct - [G,NC]
|
|
</example>
|
|
</section>
|
|
|
|
<section id="flag_h"><title>H|handler</title>
|
|
<p>Forces the resulting request to be handled with the specified
|
|
handler. For example, one might use this to force all files without a
|
|
file extension to be parsed by the php handler:</p>
|
|
|
|
<example>
|
|
RewriteRule !\. - [H=application/x-httpd-php]
|
|
</example>
|
|
|
|
<p>
|
|
The regular expression above - <code>!\.</code> - will match any request
|
|
that does not contain the literal <code>.</code> character.
|
|
</p>
|
|
|
|
<p>This can be also used to force the handler based on some conditions.
|
|
For example, the following snippet used in per-server context allows
|
|
<code>.php</code> files to be <em>displayed</em> by <code>mod_php</code>
|
|
if they are requested with the <code>.phps</code> extension:</p>
|
|
|
|
<example>
|
|
RewriteRule ^(/source/.+\.php)s$ $1 [H=application/x-httpd-php-source]
|
|
</example>
|
|
|
|
<p>The regular expression above - <code>^(/source/.+\.php)s$</code> - will
|
|
match any request that starts with <code>/source/</code> followed by 1 or
|
|
n characters followed by <code>.phps</code> literally. The backreference
|
|
$1 referrers to the captured match within parenthesis of the regular
|
|
expression.</p>
|
|
</section>
|
|
|
|
<section id="flag_l"><title>L|last</title>
|
|
<p>The [L] flag causes <module>mod_rewrite</module> to stop processing
|
|
the rule set. In most contexts, this means that if the rule matches, no
|
|
further rules will be processed.</p>
|
|
|
|
<p>If you are using <directive
|
|
module="mod_rewrite">RewriteRule</directive> in either
|
|
<code>.htaccess</code> files or in
|
|
<directive type="section" module="core">Directory</directive> sections,
|
|
it is important to have some understanding of how the rules are
|
|
processed. The simplified form of this is that once the rules have been
|
|
processed, the rewritten request is handed back to the URL parsing
|
|
engine to do what it may with it. It is possible that as the rewritten
|
|
request is handled, the <code>.htaccess</code> file or
|
|
<directive type="section" module="core">Directory</directive> section
|
|
may be encountered again, and thus the ruleset may be run again from the
|
|
start. Most commonly this will happen if one of the rules causes a
|
|
redirect - either internal or external - causing the request process to
|
|
start over.</p>
|
|
|
|
<p>It is therefore important, if you are using <directive
|
|
module="mod_rewrite">RewriteRule</directive> directives in one of these
|
|
contexts, that you take explicit steps to avoid rules looping, and not
|
|
count solely on the [L] flag to terminate execution of a series of
|
|
rules, as shown below.</p>
|
|
|
|
<p>The example given here will rewrite any request to
|
|
<code>index.php</code>, giving the original request as a query string
|
|
argument to <code>index.php</code>, however, the <directive
|
|
module="mod_rewrite">RewriteCond</directive> ensures that if the request
|
|
is already for <code>index.php</code>, the <directive
|
|
module="mod_rewrite">RewriteRule</directive> will be skipped.</p>
|
|
|
|
<example>
|
|
RewriteCond %{REQUEST_URI} !=index.php<br />
|
|
RewriteRule ^(.*) index.php?req=$1 [L]
|
|
</example>
|
|
</section>
|
|
|
|
<section id="flag_n"><title>N|next</title>
|
|
<p>
|
|
The [N] flag causes the ruleset to start over again from the top. Use
|
|
with extreme caution, as it may result in loop.
|
|
</p>
|
|
<p>
|
|
The [Next] flag could be used, for example, if you wished to replace a
|
|
certain string or letter repeatedly in a request. The example shown here
|
|
will replace A with B everywhere in a request, and will continue doing
|
|
so until there are no more As to be replaced.
|
|
</p>
|
|
|
|
<example>
|
|
RewriteRule (.*)A(.*) $1B$2 [N]
|
|
</example>
|
|
|
|
<p>You can think of this as a <code>while</code> loop: While this
|
|
pattern still matches (i.e., while the URI still contains an
|
|
<code>A</code>), perform this substitution (i.e., replace the
|
|
<code>A</code> with a <code>B</code>).</p>
|
|
|
|
</section>
|
|
|
|
<section id="flag_nc"><title>NC|nocase</title>
|
|
<p>Use of the [NC] flag causes the <directive
|
|
module="mod_rewrite">RewriteRule</directive> to be matched in a
|
|
case-insensitive manner. That is, it doesn't care whether letters appear
|
|
as upper-case or lower-case in the matched URI.</p>
|
|
|
|
<p>In the example below, any request for an image file will be proxied
|
|
to your dedicated image server. The match is case-insensitive, so that
|
|
<code>.jpg</code> and <code>.JPG</code> files are both acceptable, for
|
|
example.</p>
|
|
|
|
<example>
|
|
RewriteRule (.*\.(jpg|gif|png))$ http://images.example.com$1 [P,NC]
|
|
</example>
|
|
</section>
|
|
|
|
<section id="flag_ne"><title>NE|noescape</title>
|
|
<p>By default, special characters, such as <code>&</code> and
|
|
<code>?</code>, for example, will be converted to their hexcode
|
|
equivalent. Using the [NE] flag prevents that from happening.
|
|
</p>
|
|
|
|
<example>
|
|
RewriteRule ^/anchor/(.+) /bigpage.html#$1 [NE,R]
|
|
</example>
|
|
|
|
<p>
|
|
The above example will redirect <code>/anchor/xyz</code> to
|
|
<code>/bigpage.html#xyz</code>. Omitting the [NE] will result in the #
|
|
being converted to its hexcode equivalent, <code>%23</code>, which will
|
|
then result in a 404 Not Found error condition.
|
|
</p>
|
|
|
|
</section>
|
|
|
|
<section id="flag_ns"><title>NS|nosubreq</title>
|
|
<p>Use of the [NS] flag prevents the rule from being used on
|
|
subrequests. For example, a page which is included using an SSI (Server
|
|
Side Include) is a subrequest, and you may want to avoid rewrites
|
|
happening on those subrequests.</p>
|
|
|
|
<p>
|
|
Images, javascript files, or css files, loaded as part of an HTML page,
|
|
are not subrequests - the browser requests them as separate HTTP
|
|
requests.
|
|
</p>
|
|
</section>
|
|
|
|
<section id="flag_p"><title>P|proxy</title>
|
|
<p>Use of the [P] flag causes the request to be handled by
|
|
<module>mod_proxy</module>, and handled via a proxy request. For
|
|
example, if you wanted all image requests to be handled by a back-end
|
|
image server, you might do something like the following:</p>
|
|
|
|
<example>
|
|
RewriteRule (.*)\.(jpg|gif|png) http://images.example.com$1.$2 [P]
|
|
</example>
|
|
|
|
<p>Use of the [P] flag implies [L] - that is, the request is immediatly
|
|
pushed through the proxy, and any following rules will not be
|
|
considered.</p>
|
|
|
|
</section>
|
|
|
|
<section id="flag_pt"><title>PT|passthrough</title>
|
|
|
|
<p>
|
|
The target (or substitution string) in a RewriteRule is assumed to be a
|
|
file path, by default. The use of the [PT] flag causes it to be treated
|
|
as a URI instead. That is to say, the
|
|
use of the [PT] flag causes the result of the <directive
|
|
module="mod_rewrite">RewriteRule</directive> to be passed back through
|
|
URL mapping, so that location-based mappings, such as <directive
|
|
module="mod_alias">Alias</directive>, for example, might have a chance to take
|
|
effect.
|
|
</p>
|
|
|
|
<p>
|
|
If, for example, you have an
|
|
<directive module="mod_alias">Alias</directive>
|
|
for /icons, and have a <directive
|
|
module="mod_rewrite">RewriteRule</directive> pointing there, you should
|
|
use the [PT] flag to ensure that the
|
|
<directive module="mod_alias">Alias</directive> is evaluated.
|
|
</p>
|
|
|
|
<example>
|
|
Alias /icons /usr/local/apache/icons<br />
|
|
RewriteRule /pics/(.+)\.jpg /icons/$1.gif [PT]
|
|
</example>
|
|
|
|
<p>
|
|
Omission of the [PT] flag in this case will cause the Alias to be
|
|
ignored, resulting in a 'File not found' error being returned.
|
|
</p>
|
|
|
|
</section>
|
|
|
|
<section id="flag_qsa"><title>QSA|qsappend</title>
|
|
<p>
|
|
When the replacement URI contains a query string, the default behavior
|
|
of <directive module="mod_rewrite">RewriteRule</directive> is to discard
|
|
the existing query string, and replace it with the newly generated one.
|
|
Using the [QSA] flag causes the query strings to be combined.
|
|
</p>
|
|
|
|
<p>Consider the following rule:</p>
|
|
|
|
<example>
|
|
RewriteRule /pages/(.+) /page.php?page=$1 [QSA]
|
|
</example>
|
|
|
|
<p>With the [QSA] flag, a request for <code>/pages/123?one=two</code> will be
|
|
mapped to <code>/page.php?page=123&one=two</code>. Without the [QSA]
|
|
flag, that same request will be mapped to
|
|
<code>/page.php?page=123</code> - that is, the existing query string
|
|
will be discarded.
|
|
</p>
|
|
</section>
|
|
|
|
<section id="flag_r"><title>R|redirect</title>
|
|
<p>
|
|
Use of the [R] flag causes a HTTP redirect to be issued to the browser.
|
|
If a fully-qualified URL is specified (that is, including
|
|
<code>http://servername/</code>) then a redirect will be issued to that
|
|
location. Otherwise, the current servername will be used to generate the
|
|
URL sent with the redirect.
|
|
</p>
|
|
|
|
<p>
|
|
A status code may be specified, in the range 300-399, with a 302 status
|
|
code being used by default if none is specified.
|
|
</p>
|
|
|
|
<p>
|
|
You will almost always want to use [R] in conjunction with [L] (that is,
|
|
use [R,L]) because on its own, the [R] flag prepends
|
|
<code>http://thishost[:thisport]</code> to the URI, but then passes this
|
|
on to the next rule in the ruleset, which can often result in 'Invalid
|
|
URI in request' warnings.
|
|
</p>
|
|
|
|
</section>
|
|
|
|
<section id="flag_s"><title>S|skip</title>
|
|
<p>The [S] flag is used to skip rules that you don't want to run. This
|
|
can be thought of as a <code>goto</code> statement in your rewrite
|
|
ruleset. In the following example, we only want to run the <directive
|
|
module="mod_rewrite">RewriteRule</directive> if the requested URI
|
|
doesn't correspond with an actual file.</p>
|
|
|
|
<example>
|
|
# Is the request for a non-existent file?<br />
|
|
RewriteCond %{REQUEST_FILENAME} !-f<br />
|
|
RewriteCond %{REQUEST_FILENAME} !-d<br />
|
|
# If so, skip these two RewriteRules<br />
|
|
RewriteRule .? - [S=2]<br />
|
|
<br />
|
|
RewriteRule (.*\.gif) images.php?$1<br />
|
|
RewriteRule (.*\.html) docs.php?$1
|
|
</example>
|
|
|
|
<p>This technique is useful because a <directive
|
|
module="mod_rewrite">RewriteCond</directive> only applies to the
|
|
<directive module="mod_rewrite">RewriteRule</directive> immediately
|
|
following it. Thus, if you want to make a <code>RewriteCond</code> apply
|
|
to several <code>RewriteRule</code>s, one possible technique is to
|
|
negate those conditions and use a [Skip] flag.</p>
|
|
|
|
</section>
|
|
|
|
<section id="flag_t"><title>T|type</title>
|
|
<p>Sets the MIME type with which the resulting response will be
|
|
sent. This has the same effect as the <directive
|
|
module="mod_mime">AddType</directive> directive.</p>
|
|
|
|
<p>For example, you might use the following technique to serve Perl
|
|
source code as plain text, if requested in a particular way:</p>
|
|
|
|
<example>
|
|
# Serve .pl files as plain text<br />
|
|
RewriteRule \.pl$ - [T=text/plain]
|
|
</example>
|
|
|
|
<p>Or, perhaps, if you have a camera that produces jpeg images without
|
|
file extensions, you could force those images to be served with the
|
|
correct MIME type by virtue of their file names:</p>
|
|
|
|
<example>
|
|
# Files with 'IMG' in the name are jpg images.<br />
|
|
RewriteRule IMG - [T=image/jpg]
|
|
</example>
|
|
|
|
<p>Please note that this is a trivial example, and could be better done
|
|
using <directive type="section" module="core">FilesMatch</directive>
|
|
instead. Always consider the alternate
|
|
solutions to a problem before resorting to rewrite, which will
|
|
invariably be a less efficient solution than the alternatives.</p>
|
|
</section>
|
|
|
|
</section>
|
|
</manualpage>
|
|
|