This document supplements the
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.
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.
We force a HTTP redirect to the new URL which leads to a change of the browsers and thus the users view:
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:
If a resource has moved to another server, you may wish to have URLs continue to work for a time on the old server while people update their bookmarks.
You can use
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.
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
.
How can we make URLs backward compatible (still
existing virtually) after migrating document.YYYY
to document.XXXX
, e.g. after translating a
bunch of .html
files to .php
?
We rewrite the name to its basename and test for existence of the new extension. If it exists, we take that name, else we rewrite the URL to its original state.
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
The very best way to solve this doesn't involve mod_rewrite at all,
but rather uses the
You can alternatively accomplish this using the
Or, for example, to redirect a portion of your site to HTTPS, you might do the following:
If, for whatever reason, you still want to use mod_rewrite
- if, for example, you need this to work with a larger set of RewriteRules -
you might use one of the recipes below.
For sites running on a port other than 80:
And for a site running on port 80
If you wanted to do this generically for all domain names - that is, if you want to redirect example.com to www.example.com for all possible values of example.com, you could use the following recipe:
These rulesets will work either in your main server configuration
file, or in a .htaccess
file placed in the
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.
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.
We have numerous mirrors of our website, and want to redirect people to the one that is located in the country where they are located.
Looking at the hostname of the requesting client, we determine which country they are coming from. If we can't do a lookup on their IP address, we fall back to a default server.
We'll use a
on
, which can be
a significant performance hit.The
We wish to provide different content based on the browser, or user-agent, which is requesting the content.
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.
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
.
DocumentRoot
Usually the /
".
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:
We redirect the URL /
to
/about/
:
Note that this can also be handled using the
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
As of version 2.2.16, you should use the
However, in earlier versions of Apache, or if your needs are more complicated than this, you can use a variation of the following rewrite set to accomplish the same thing:
If, on the other hand, you wish to pass the requested URI as a query string argument to index.php, you can replace that RewriteRule with:
Note that these rulesets can be used in a .htaccess
file, as well as in a <Directory> block.