<?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="avoid.xml.meta">

<parentdocument href="./">Rewrite</parentdocument>

<title>When not to use mod_rewrite</title>

<summary>

<p>This document supplements the <module>mod_rewrite</module>

<a href="/mod_rewrite.html">reference documentation</a>. It provides

a few advanced techniques and tricks using mod_rewrite.</p>

<note type="warning">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.</note>

</summary>

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

<seealso><a href="intro.html">mod_rewrite introduction</a></seealso>

<section id="sharding">

<title>URL-based sharding accross multiple backends</title>

<dl>

<dt>Description:</dt>

<dd>

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

</dd>

<dt>Solution:</dt>

<dd>

<p>A mapping is maintained, from users to target servers, in

external map files. They look like:</p>

<example><pre>

user1 physical_host_of_user1

user2 physical_host_of_user2

: :

</pre></example>

<p>We put this into a <code>map.users-to-hosts</code> file. The

aim is to map;</p>

<example><pre>

/u/user1/anypath

</pre></example>

<p>to</p>

<example><pre>

</pre></example>

<p>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):</p>

<example><pre>

RewriteEngine on

RewriteMap users-to-hosts txt:/path/to/map.users-to-hosts

RewriteRule ^/u/<strong>([^/]+)</strong>/?(.*) http://<strong>${users-to-hosts:$1|server0}</strong>/u/$1/$2

</pre></example>

</dd>

</dl>

</section>

<section id="on-the-fly-content">

<title>On-the-fly Content-Regeneration</title>

<dl>

<dt>Description:</dt>

<dd>

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

</dd>

<dt>Solution:</dt>

<dd>

This is done via the following ruleset:

<example><pre>

# This example is valid in per-directory context only

RewriteCond %{REQUEST_FILENAME} <strong>!-s</strong>

RewriteRule ^page\.<strong>html</strong>$ page.<strong>cgi</strong> [T=application/x-httpd-cgi,L]

</pre></example>

<p>Here a request for <code>page.html</code> leads to an

internal run of a corresponding <code>page.cgi</code> if

<code>page.html</code> is missing or has filesize

null. The trick here is that <code>page.cgi</code> is a

CGI script which (additionally to its <code>STDOUT</code>)

writes its output to the file <code>page.html</code>.

Once it has completed, the server sends out

<code>page.html</code>. When the webmaster wants to force

a refresh of the contents, he just removes

<code>page.html</code> (typically from <code>cron</code>).</p>

</dd>

</dl>

</section>

</manualpage>