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