<?xml version='1.0' encoding='UTF-8' ?>

<!DOCTYPE manualpage SYSTEM "/style/manualpage.dtd">

<?xml-stylesheet type="text/xsl" href="/style/manual.en.xsl"?>

<manualpage metafile="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.</p>

</summary>

<seealso><a href="/mod/mod_rewrite.html">Module documentation</a></seealso>

<seealso><a href="tech.html">Technical details</a></seealso>

<section id="introduction"><title>Introduction</title>

<p>A <directive module="mod_rewrite">RewriteRule</directive> can have

its 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>

<p>Each flag (with a few exceptions)

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>

<section id="flag_b"><title>B (escape backreferences)</title>

<p>The [B] flag instructs <directive

module="mod_rewrite">RewriteRule</directive> to escape non-alphanumeric

characters before applying the transformation.

</p>

<p>Apache has to unescape URLs before mapping them,

so backreferences will be unescaped at the time they are applied.

Using the B flag, non-alphanumeric characters in backreferences

will be escaped. For example, consider the rule:</p>

<example>

RewriteRule ^(/.*)$ /index.php?show=$1

</example>

<p>This will map <code>/C++</code> to

<code>/index.php?show=/C++</code>. But it will also map

<code>/C%2b%2b</code> to <code>/index.php?show=/C++</code>, because

the <code>%2b</code> has been unescaped. With the B flag, it will

instead map to <code>/index.php?show=/C%2b%2b</code>.</p>

<p>This escaping is particularly necessary in a proxy situation,

when the backend may break if presented with an unescaped URL.</p>

</section>

<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 five optional

fields.</p>

<p>The full syntax for the flag, including all attributes, is as

follows:</p>

<example>

[CO=NAME:VALUE:domain:lifetime:path:secure:httponly]

</example>

<p>You must declare a name and value for the cookie to be set.</p>

<p>You may optionally also set the following values:</p>

<dl>

<dt>Domain</dt>

<dd>The domain for which you want the cookie to be valid. This may be a

hostname, such as <code>www.example.com</code>, or it may be a domain,

such as <code>.example.com</code>. It must be at least two parts

separated by a dot. That is, it may not be merely <code>.com</code> or

<code>.net</code>. Cookies of that kind are forbidden by the cookie

security model.</dd>

<dd>The default value for the domain is the current domain.</dd>

<dt>Lifetime</dt>

<dd>The time for which the cookie will persist, in minutes.</dd>

<dd>A value of 0 indicates that the cookie will persist only for the

current browser session. This is the default value if none is

specified.</dd>

<dt>Path</dt>

<dd>The path, on the current website, for which the cookie is valid,

such as <code>/customers/</code> or <code>/files/download/</code>.</dd>

<dd>By default, this is set to <code>/</code> - that is, the entire

website.</dd>

<dt>Secure</dt>

<dd>If set to <code>secure</code>, <code>true</code>, or <code>1</code>,

the cookie will only be permitted to be translated via secure (https)

connections.</dd>

<dt>httponly</dt>

<dd>If set to <code>HttpOnly</code>, <code>true</code>, or

<code>1</code>, the cookie will have the <code>HttpOnly</code> flag set,

which means that the cookie will be inaccessible to JavaScript code on

browsers that support this feature.</dd>

</dl>

<p>Several examples are offered here:</p>

<example>

RewriteEngine On<br />

RewriteRule ^/index\.html - [CO=frontdoor:yes:.apache.org:1440:/]

</example>

<p>In the example give, the rule doesn't rewrite the request.

The "-" rewrite target tells mod_rewrite to pass the request

through unchanged. Instead, it 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_dpi"><title>DPI|discardpathinfo</title>

<p>The DPI flag causes the PATH_INFO portion of the rewritten URI to be

discarded.</p>

<p>This flag is available from 2.2.12</p>

<p>In per-directory context, the URI each <directive>RewriteRule</directive>

compares against is the concatenation of the current values of the URI

and PATH_INFO.</p>

<p>The current URI can be the initial URI as requested by the client, the

result of a previous round of mod_rewrite processing, or the result of

a prior rule in the current round of mod_rewrite processing.</p>

<p>In contrast, the PATH_INFO that is appended to the URI before each

rule reflects only the value of PATH_INFO before this round of

mod_rewrite processing. As a consequence, if large portions

of the URI are matched and copied into a substitution in multiple

<directive>RewriteRule</directive> directives, without regard for

which parts of the URI came from the current PATH_INFO, the final

URI may have multiple copies of PATH_INFO appended to it.</p>

<p>Use this flag on any substitution where the PATH_INFO that resulted

from the previous mapping of this request to the filesystem is not of

interest. This flag permanently forgets the PATH_INFO established

before this round of mod_rewrite processing began. PATH_INFO will

not be recalculated until the current round of mod_rewrite processing

completes. Subsequent rules during this round of processing will see

only the direct result of substitutions, without any PATH_INFO

appended.</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 syntax for this flag is:</p>

<example>

[E:VAR=VAL]

</example>

<p><code>VAL</code> may contain backreferences (<code>$N</code> or

<code>%N</code>) which will be expanded.</p>

<p>These environment variables can then be used in a variety of

contexts, including CGI programs, other RewriteRule directives, or

CustomLog directives.</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>&amp;</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&amp;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_qsd"><title>QSD|qsdiscard</title>

<p>

When the requested URI contains a query string, and the target URI does

not, the default behavior of <directive

module="mod_rewrite">RewriteRule</directive> is to copy that query

string to the target URI. Using the [QSD] flag causes the query string

to be discarded.

</p>

<p>

Using [QSD] and [QSA] together will result in [QSD] taking preference.

</p>

<p>

If the target URI has a query string, the default behavior will be

observed - that is, the original query string will be discarded and

replaced with the query string in the <code>RewriteRule</code> target

URI.

</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>

<em>Any</em> status code may be specified, that is a valid HTTP Response,

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>

</manualpage>