advanced.xml revision 2bb0656f94af82b1ff5e3e77a99b4427c52e4953
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "/style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="/style/manual.en.xsl"?>
<!-- $LastChangedRevision: 832069 $ -->
<!--
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="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/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>
<seealso><a href="remapping.html">Redirection and remapping</a></seealso>
<seealso><a href="access.html">Controlling access</a></seealso>
<!-- <seealso><a href="advanced.html">Advanced techniques and tricks</a></seealso> -->
<seealso><a href="avoid.html">When not to use mod_rewrite</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>
http://physical_host_of_user1/u/user/anypath
</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>