Redirecting and Remapping with mod_rewrite

This document supplements the mod_rewritereference documentation. It describes
how you can use mod_rewrite to redirect and remap
request. This includes many examples of common uses of mod_rewrite,
including detailed descriptions of how each works.

Note that many of these examples won't work unchanged in your
particular server configuration, so it's important that you understand
them, rather than merely cutting and pasting the examples into your
configuration.

See also

Assume we have recently renamed the page
foo.html to bar.html and now want
to provide the old URL for backward compatibility. However,
we want that users of the old URL even not recognize that
the pages was renamed - that is, we don't want the address to
change in their browser.

Solution:

We rewrite the old URL to the new one internally via the
following rule:

Assume again that we have recently renamed the page
foo.html to bar.html and now want
to provide the old URL for backward compatibility. But this
time we want that the users of the old URL get hinted to
the new one, i.e. their browsers Location field should
change, too.

Solution:

We force a HTTP redirect to the new URL which leads to a
change of the browsers and thus the users view:

RewriteEngine on
RewriteRule ^/foo\.html$ bar.html [R]

Discussion

In this example, as contrasted to the internal example above, we can simply
use the Redirect directive. mod_rewrite was used in that earlier
example in order to hide the redirect from the client:

How can we transform a static page
foo.html into a dynamic variant
foo.cgi in a seamless way, i.e. without notice
by the browser/user.

Solution:

We just rewrite the URL to the CGI-script and force the
handler to be cgi-script so that it is
executed as a CGI program.
This way a request to /~quux/foo.html
internally leads to the invocation of
/~quux/foo.cgi.

This example uses an often-overlooked feature of mod_rewrite,
by taking advantage of the order of execution of the ruleset. In
particular, mod_rewrite evaluates the left-hand-side of the
RewriteRule before it evaluates the RewriteCond directives.
Consequently, $1 is already defined by the time the RewriteCond
directives are evaluated. This allows us to test for the existence
of the original (document.html) and target
(document.php) files using the same base filename.

This ruleset is designed to use in a per-directory context (In a
<Directory> block or in a .htaccess file), so that the
-f checks are looking at the correct directory path.
You may need to set a RewriteBase directive to specify the
directory base that you're working in.

The goal of this rule is to force the use of a particular
hostname, in preference to other hostnames which may be used to
reach the same site. For example, if you wish to force the use
of www.example.com instead of
example.com, you might use a variant of the
following recipe.

Solution:

The very best way to solve this doesn't involve mod_rewrite at all,
but rather uses the Redirect
directive placed in a virtual host for the non-canonical
hostname(s).

A particular resource might exist in one of several places, and
we want to look in those places for the resource when it is
requested. Perhaps we've recently rearranged our directory
structure, dividing content into several locations.

Solution:

The following ruleset searches in two directories to find the
resource, and, if not finding it in either place, will attempt to
just serve it out of the location requested.

RewriteEngine on
# first try to find it in dir1/...
# ...and if found stop and be happy:
RewriteCond %{DOCUMENT_ROOT}/dir1/%{REQUEST_URI} -f
RewriteRule ^(.+) %{DOCUMENT_ROOT}/dir1/$1 [L]
# second try to find it in dir2/...
# ...and if found stop and be happy:
RewriteCond %{DOCUMENT_ROOT}/dir2/%{REQUEST_URI} -f
RewriteRule ^(.+) %{DOCUMENT_ROOT}/dir2/$1 [L]
# else go on for other Alias or ScriptAlias directives,
# etc.
RewriteRule ^ - [PT]

This ruleset relies on
HostNameLookups
being set on, which can be
a significant performance hit.

The RewriteCond
directive captures the last portion of the hostname of the
requesting client - the country code - and the following RewriteRule
uses that value to look up the appropriate mirror host in the map
file.

We wish to provide different content based on the browser, or
user-agent, which is requesting the content.

Solution:

We have to decide, based on the HTTP header "User-Agent",
which content to serve. The following config
does the following: If the HTTP header "User-Agent"
contains "Mozilla/3", the page foo.html
is rewritten to foo.NS.html and the
rewriting stops. If the browser is "Lynx" or "Mozilla" of
version 1 or 2, the URL becomes foo.20.html.
All other browsers receive page foo.32.html.
This is done with the following ruleset:

On some webservers there is more than one URL for a
resource. Usually there are canonical URLs (which are be
actually used and distributed) and those which are just
shortcuts, internal ones, and so on. Independent of which URL the
user supplied with the request, they should finally see the
canonical one in their browser address bar.

Solution:

We do an external HTTP redirect for all non-canonical
URLs to fix them in the location view of the Browser and
for all subsequent requests. In the example ruleset below
we replace /puppies and /canines
by the canonical /dogs.

RewriteRule ^/(puppies|canines)/(.*) /dogs/$2 [R]

Discussion:

This should really be accomplished with Redirect or RedirectMatch
directives:

Usually the DocumentRoot
of the webserver directly relates to the URL "/".
But often this data is not really of top-level priority. For example,
you may wish for visitors, on first entering a site, to go to a
particular subdirectory /about/. This may be accomplished
using the following ruleset:

Note also that the example rewrites only the root URL. That is, it
rewrites a request for http://example.com/, but not a
request for http://example.com/page.html. If you have in
fact changed your document root - that is, if all of
your content is in fact in that subdirectory, it is greatly preferable
to simply change your DocumentRoot
directive, or move all of the content up one directory,
rather than rewriting URLs.

You want a single resource (say, a certain file, like index.php) to
handle all requests that come to a particular directory, except those
that should go to an existing resource such as an image, or a css file.

Notice:This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.