Advanced Techniques with mod_rewrite

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.

A common technique for distributing the burden of
server load or storage space is called "sharding".
When using this method, a front-end server will use the
url to consistently "shard" users or objects to separate
backend servers.

Solution:

A mapping is maintained, from users to target servers, in
external map files. They look like:

user1 physical_host_of_user1
user2 physical_host_of_user2
: :

We put this into a map.users-to-hosts file. The
aim is to map;

/u/user1/anypath

to

http://physical_host_of_user1/u/user/anypath

thus every URL path need not be valid on every backend physical
host. The following ruleset does this for us with the help of the map
files assuming that server0 is a default server which will be used if
a user has no entry in the map:

We wish to dynamically generate content, but store it
statically once it is generated. This rule will check for the
existence of the static file, and if it's not there, generate
it. The static files can be removed periodically, if desired (say,
via cron) and will be regenerated on demand.

The -U operator determines whether the test string
(in this case, REQUEST_URI) is a valid URL. It does
this via a subrequest. In the event that this subrequest fails -
that is, the requested resource doesn't exist - this rule invokes
the CGI program /regenerate_page.cgi, which generates
the requested resource and saves it into the document directory, so
that the next time it is requested, a static copy can be served.

In this way, documents that are infrequently updated can be served in
static form. if documents need to be refreshed, they can be deleted
from the document directory, and they will then be regenerated the
next time they are requested.

Wouldn't it be nice, while creating a complex web page, if
the web browser would automatically refresh the page every
time we save a new version from within our editor?
Impossible?

Solution:

No! We just combine the MIME multipart feature, the
web server NPH feature, and the URL manipulation power of
mod_rewrite. First, we establish a new
URL feature: Adding just :refresh to any
URL causes the 'page' to be refreshed every time it is
updated on the filesystem.

Some sites with thousands of users use a
structured homedir layout, i.e. each homedir is in a
subdirectory which begins (for instance) with the first
character of the username. So, /~larry/anypath
is /home/l/larry/public_html/anypath
while /~waldo/anypath is
/home/w/waldo/public_html/anypath.

Solution:

We use the following ruleset to expand the tilde URLs
into the above layout.

This provides the content of foo.day.html
under the URL foo.html from
07:01-18:59 and at the remaining time the
contents of foo.night.html.

mod_cache, intermediate proxies
and browsers may each cache responses and cause the either page to be
shown outside of the time-window configured.
mod_expires may be used to control this
effect. You are, of course, much better off simply serving the
content dynamically, and customizing it based on the time of day.

At time, we want to maintain some kind of status when we
perform a rewrite. For example, you want to make a note that
you've done that rewrite, so that you can check later to see if a
request can via that rewrite. One way to do this is by setting an
environment variable.

Solution:

Use the [E] flag to set an environment variable.

RewriteEngine on
RewriteRule ^/horse/(.*) /pony/$1 [E=rewritten:1]

Later in your ruleset you might check for this environment
variable using a RewriteCond:

RewriteCond %{ENV:rewritten} =1

Note that environment variables do not survive an external
redirect. You might consider using the [CO] flag to set a
cookie.

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.