<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.de.xsl"?>
<modulesynopsis metafile="mod_rewrite.xml.meta">
<name>mod_rewrite</name>
<description>Eine auf Regeln basierende Rewriting Engine zum Umschreiben
angeforderter URLs</description>
<status>Erweiterung</status>
<sourcefile>mod_rewrite.c</sourcefile>
<identifier>rewrite_module</identifier>
<compatibility>Ab Apache 1.3</compatibility>
<summary>
<blockquote>
<p>``Das Großartige an <code>mod_rewrite</code> ist,
dass das Modul so anpassungsfähig und flexibel
wie Sendmail ist. Der Nachteil an <code>mod_rewrite</code> ist,
dass das Modul so anpassungsfähig und flexibel
wie Sendmail ist..''</p>
<p class="cite">-- <cite>Brian Behlendorf</cite><br />
Apache Group</p>
</blockquote>
<blockquote>
<p>`` Despite the tons of examples und docs,
mod_rewrite is voodoo. Damned cool voodoo, but still
voodoo. ''</p>
<p class="cite">-- <cite>Brian Moore</cite><br />
[EMAIL PROTECTED]</p>
</blockquote>
<p>Herzlich willkommen zu <code>mod_rewrite</code>, dem
Allroundwerkzeug für die URL-Manipulation!</p>
<p>Dieses Modul verwendet eine auf Regeln basierende
Rewriting Engine, die mit Hilfe eines Parsers für reguläre
Ausdrücke
angeforderte URLs im Vorbeigehen umschreibt.
Es unterstützt eine unbegrenzte Anzahl von Regeln
Bedingungen für jede einzelne Regel,
um einen wirklich flexiblen und leistungsfähigen Mechanismus
für die URL-Manipulation bereitzustellen. Die URL-Manipulationen
können in Abhängigkeit von unterschiedlichen Tests
durchgeführt
werden, beispielsweise in Abhängigkeit von Servervariablen,
Umgebungsvariablen, HTTP-Headern und Zeitstempeln. Selbst die
Suchergebnisse in externen Datenbanken unterschiedlicher
Formate können für einen fein abgestimmten URL-Vergleich
herangezogen
werden.</p>
<p>Das Modul arbeitet mit den vollständigen URLs
(einschließlich
der Pfadinformationen) im Server- und Verzeichniskontext
(<code>httpd.conf</code> und <code>.htaccess</code>). Es kann
sogar Teile von Abfragezeichenfolgen
als Ergebnis liefern. Das umgeschriebene Ergebnis kann zur internen
Weiterverarbeitung, zu externen Anfrageumleitungen oder auch zu
internem Proxy-Durchsatz führen.</p>
<p>Aber all diese Funktionalität und Flexibiltät hat einen
Nachteil,
nämlich die Komplexität. Daher ist das Modul in seinem
gesamten Umfang auch nicht einfach und leicht zu verstehen.</p>
<p>Das Modul wurde im April 1996 entwickelt und im Juli 1997
von</p>
<p class="indent">
<a href="http://www.engelschall.com/";><code>Ralf S.
Engelschall</code></a><br />
<a
href="mailto:[EMAIL PROTECTED]"><code>[EMAIL PROTECTED]</code></a><br />
<a
href="http://www.engelschall.com/";><code>www.engelschall.com</code></a></p>
<p>der Apache Group exklusiv überlassen.</p>
</summary>
<section id="Internal"><title>Interne Verarbeitung</title>
<p>Die interne Verarbeitung ist sehr komplex, auf eine Erklärung kann
aber auch für den einfachen Benutzer nicht verzichtet werden, um weit
verbreitete Fehler zu vermeiden und die gesamte Funktionalität nutzen
zu können.</p>
<section id="InternalAPI"><title>API-Phasen</title>
<p>Wichtig für das Verständnis sind die Phasen der Verarbeitung
einer
HTTP-Anfrage durch den Server. Die Apache-API stellt für jede
dieser Phasen einen Hook zur Verfügung. <code>Mod_rewrite</code>
benutzt zwei dieser Hooks: Zum einen den Umwandlungs-Hook für URLs
in Dateinamen, der eingesetzt wird, nachdem die HTTP-Anfrage gelesen
aber noch bevor eine Authorisierung durchgeführt wurde. Und zum
anderen den Fixup-Hook, der nach der Authorisierungsphase und
nach dem Lesen der Verzeichnis-Konfigurationsdateien
(<code>.htaccess</code>), aber noch vor der Aktivierung des
Content-Handler, ausgelöst wird.</p>
<p>Hat der Apache nach Eingang einer Anfrage den
entsprechenden Server (oder virtuellen Server) ermittelt, beginnt
die Rewriting Engine in der Phase der Umwandlung von URL in Dateiname
mit der Verarbeitung aller <code>mod_rewrite</code>- Direktiven
aus der Serverkonfiguration. Nachdem die letzten Datenverzeichnisse
gefunden wurden, werden die <code>mod_rewrite</code>-Dirketiven
für die Verzeichniskonfiguration in der Fixup-Phase ausgelöst.
In
beiden Fällen schreibt <code>mod_rewrite</code> URLs entweder
in neue URLs oder Dateinamen um, auch wenn es für beide kein
erkennbares Unterscheidungsmerkmal gibt. Diese Verwendung der API
war ursprünglich nicht beabsichtigt, aber seit der Apache-Version
1.x
ist dies die einzige Möglichkeit, wie <code>mod_rewrite</code>
arbeiten kann. Um dies etwas zu verdeutlichen, sei an die
beiden folgenden Punkte erinnert:</p>
<ol>
<li>Obwohl <code>mod_rewrite</code> URLs in URLs, URLs in
Dateinamen und auch Dateinamen in Dateinamen umschreibt, besitzt
die API zur Zeit lediglich einen Hook für die Umwandlung von
URLs in Dateinamen. Mit Apache 2.0 werden die beiden fehlenden
Hooks hinzugefügt, um die Verarbeitung klarer zu machen. Für
den
Benutzer bringt das keine Nachteile, es sollte aber beachtet
werden, dass der Apache mit dem Hook für die Umwandlung von
URLs in Dateinamen mehr leistet, als für die API ursprünglich
vorgesehen war.</li>
<li>
Erstaunlicherweise ermöglicht <code>mod_rewrite</code>
URL-Manipulationen im Verzeichniskontext
(<code>.htaccess</code>-Dateien), obwohl dieser erst wesentlich
später nach der erfolgten Umwandlung der URLs in Dateinamen
erreicht wird. Das muss geschehen, weil
<code>.htaccess</code>-Dateien zum Dateisystem gehören, so
dass die Verarbeitung bereits diesen Stand erreicht hat. Oder anders
ausgedrückt: Entsprechend der API-Phasen ist es zu diesem
Zeitpunkt
zu spät für URL-Manipulationen. Dieses Problem wird mit
einem
Trick umgangen: Wird eine URL oder ein Dateiname im Verzeichniskontext
manipuliert, schreibt das Modul zuerst den Dateinamen wieder in die
entsprechende URL um, was normalerweise unmöglich ist. Im
Zusammenhang mit der <code>RewriteBase</code>-Direktive weiter
unten wird aber beschrieben, wie dies zu realisieren ist.
Anschließend
wird eine neue interne Unteranfrage mit der neuen URL ausgelöst.
Damit wird die Verarbeitung der API-Phasen erneut gestartet.
<p>Zwar wird versucht, diesen komplizierten Schritt für den
Benutzer völlig transparent zu machen, dabei ist aber folgendes
zu
berücksichtigen: Während URL-Manipulationen im Serverkontext
wirklich schnell und effizient sind, verläuft das Umschreiben im
Verzeichniskontext infolge des beschriebenen Problems
langsam und ineffizient. Andererseits ist dies die einzige
Möglichkeit,
wie <code>mod_rewrite</code> lokal beschränkte
URL-Manipulationen für den einfachen Benutzer anbieten kann.</p>
</li>
</ol>
<p>Berücksichtigen Sie diese beiden Punkte!</p>
</section>
<section id="InternalRuleset"><title>Verarbeitung von Regelsätzen</title>
<p>Wenn <code>mod_rewrite</code> in diesen beiden API-Phasen
in Aktion tritt, werden die vorgegebenen Regeln aus der
Konfigurationsstruktur
gelesen, die entweder beim Serverstart für den Serverkontext oder
während des Verzeichnisdurchlaufs des Apache-Kerns für den
Verzeichniskontext erzeugt wurde.Anschließend wird die
URL-Rewriting Engine mit diesem Regelsatz (eine oder mehre Regeln mit
den dazugehörigen Bedingungen) gestartet. Der Ablauf ist bei der
Rewriting Engine für beide Konfigurationszusammenhänge genau der
gleiche. Nur die Verarbeitung der Ergebnisse unterscheidet sich. </p>
<p>Die Reihenfolge der Regeln im Regelsatz ist von Bedeutung,
weil die Rewriting Engine sie in einer besonderen (nicht unmittelbar
verständlichen) Reihenfolge verarbeitet. Es gilt: Die Rewriting
Engine
geht Regel für Regel durch den Regelsatz (<directive
module="mod_rewrite">RewriteRule</directive>-Direktiven). Tritt eine
bestimmte Regel in Kraft, werden optional die entsprechenden
Bedingungen durchlaufen (<code>RewriteCond</code>-
Direktiven). Aus Gründen der Entwicklungsgeschichte stehen die
Bedingungen am Beginn, so dass die Flusskontrolle etwas langwierig
ist. Weitere Einzelheiten finden Sie in Abbildung 1.</p>
<p class="figure">
<img src="../images/mod_rewrite_fig1.gif" width="428"
height="385" alt="[Needs graphics capability to display]" /><br />
<dfn>Abbildung 1:</dfn>Die Flußkontrolle bei den Manipulationregeln
</p>
<p>Wie die Abbildung zeigt, wird die erste URL mit dem
<em>Muster</em> jeder Regel verglichen. Gibt es keine
Übereinstimmung, bricht <code>mod_rewrite</code> die Verarbeitung
dieser Regel sofort ab und fährt mit der nächsten Regel fort.
Stimmt
das <em>Muster</em> überein, sucht das Modul nach Bedingungen
für die Regel. Sind keine vorhanden, wird die URL einfach durch einen
neuen Wert ersetzt, der aus der Zeichenfolge <em>Substitution</em>
gebildet wird und durchläuft anschließend wieder die Regeln.
Sind aber
Bedingungen vorhanden, wird eine innere Schleife für ihre
Verarbeitung
in der aufgeführten Reihenfolge begonnen. Bei Bedingungen ist die
Logik
eine andere: Es wird nicht das Muster mit der aktuellen URL verglichen,
sondern mit Hilfe von Variablen, Rückverweisen, Map-Suchen usw.
die Zeichenfolge <em>TestString</em> konstruiert und mit
<em>BedMuster</em> verglichen. Stimmt das Muster nicht überein,
treffen alle Bedingungen und die dazugehörige Regel nicht zu.
Stimmt das Muster überein, wird jeweils die nächste Bedingung
verarbeitet, bis keine Bedingungen mehr vorliegen. Treffen alle
Bedingungen zu, wird mit der Ersetzung der URL durch
<em>Substitution</em> fortgefahren.</p>
</section>
<section id="quoting"><title>Sonderzeichen</title>
<p>Seit der Apache-Version 1.3.20 können Sonderzeichen in
<em>TestString</em> und <em>Substitution</em> durch
Voranstellung eines Schrägstrichs ('\') gekennzeichnet werden, wenn
sie wie normale Zeichen behandelt werden sollen. Die Zeichenfolge
<em>Substitution</em> darf also beispielsweise bei der Schreibweise
<code>\$</code> ein Dollarzeichen enthalten, ohne dass dies als
Rückverweis
gewertet wird.</p>
</section>
<section id="InternalBackRefs"><title>Rückverweise</title>
<p>Werden im <em>Muster</em> oder in einer der Variablen
<em>BedMuster</em> Klammern gesetzt, werden internRückverweise
erzeugt, die über die Zeichenfolgen <code>$N</code> und
<code>%N</code> benutzt werden können (siehe unten). Sie
stehen für die Bildung der Zeichenfolgen <em>Substitution</em> und
<em>TestString</em> zur Verfügung. Abbildung 2 zeigt, auf welche
Positionen sich die Rückverweise beziehen.</p>
<p class="figure">
<img src="../images/mod_rewrite_fig2.gif" width="381"
height="179" alt="[Needs graphics capability to display]" /><br />
<dfn>Abbildung 2:</dfn> Fluss der Rückverweise bei Regeln.
</p>
<p>Dieser kleine Crashkurs über die inneren Abläufe des Moduls
<code>mod_rewrite</code> soll das Verständnis
der folgenden Dokumentation der verfügbaren Direktiven
erleichtern.</p>
</section>
</section>
<section id="EnvVar"><title>Umgebungsvariablen</title>
<p>Das Modul zeichnet zwei zusätzliche (nicht
standardmäßige)
CGI/SSI-Umgebungsvariablen mit den Bezeichnungen
<code>SCRIPT_URL</code> und <code>SCRIPT_URI</code> auf.
Sie enthalten die <em>logische</em> Web-Sicht auf die aktuelle
Ressource, während die standardmäßigen CGI/SSI-Variablen
<code>SCRIPT_NAME</code> und <code>SCRIPT_FILENAME</code>
die <em>physische</em> Systemsicht enthalten. </p>
<p>Hinweis: Diese Variablen speichern die URI/URL <em>wie sie
ursprünglich angefordert wurde</em>, d.h. <em>bevor</em>
etwas umgeschrieben wurde. Das ist wichtig, weil der Vorgang des
Umschreibens primär dazu dient, logische URLs in physische
Pfadnamen umzuschreiben.</p>
<example><title>Beispiel</title>
<pre>
SCRIPT_NAME=/sw/lib/w3s/tree/global/u/rse/.www/index.html
SCRIPT_FILENAME=/u/rse/.www/index.html
SCRIPT_URL=/u/rse/
SCRIPT_URI=http://en1.engelschall.com/u/rse/
</pre>
</example>
</section>
<section id="Solutions"><title>Praktische Lösungen</title>
<p>Unter <a href="../misc/rewriteguide.html">Einführung in die
URL-Manipulationen</a> finden Sie eine Sammlung praktischer
Lösungen für Probleme mit URLs. Dort finden Sie auch
Regelsätze für den praktischen Einsatz sowie weiter
Informationen zum
Modul <code>mod_rewrite</code>.</p>
</section>
<directivesynopsis>
<name>RewriteEngine</name>
<description>Aktiviert oder deaktiviert die Rewriting Engine.</description>
<syntax>RewriteEngine on|off</syntax>
<default>RewriteEngine off</default>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context></contextlist>
<override>FileInfo</override>
<usage>
<p>Die <directive>RewriteEngine</directive>-Direktive aktiviert oder
deaktiviert die Rewriting Engine. Wird sie auf <code>off</code> gesetzt,
führt dieses Modul keine Verarbeitung während der Laufzeit
durch.
Auch die Umgebungsvariablen <code>SCRIPT_URx</code>
werden nicht aktualisiert.</p>
<p>Das Modul sollte mit dieser Direktive deaktiviert werden, anstatt die
<directive module="mod_rewrite">RewriteRule</directive>-Direktiven
als Kommentarzeilen zu kennzeichnen.</p>
<p>Die Rewrite-Einstellungen werden standardmäßig nicht
vererbt.
Das bedeutet, dass für jeden virtuellen Host, für die sie
wirksam werden sollen,
die <code>RewriteEngine</code>-Direktive auf <code>on</code>
gesetzt werden muss.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>RewriteOptions</name>
<description>Setzt einige spezielle Optionen für die Rewriting
Engine</description>
<syntax>RewriteOptions <var>Option</var></syntax>
<default>RewriteOptions MaxRedirects=10</default>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context></contextlist>
<override>FileInfo</override>
<compatibility><code>MaxRedirects</code> steht seit der Apache-Version
2.0.45 zur Verfügung.</compatibility>
<usage>
<p>Mit der <directive>RewriteOptions</directive>-Direktive können
spezielle Optionen für die Server oder Verzeichnisse gesetzt werden.
Als <em>Option</em> kann angegeben werden:</p>
<dl>
<dt><code>inherit</code></dt>
<dd>Die aktuelle Konfiguration erbt die übergeordnete
Konfiguration. Für den <code>VirtualHost</code>-Abschnitt bedeutet
das, dass die Maps, Bedingungen und Regeln des Hauptservers
übernommen werden. Auf der Verzeichnisebene werden die Bedingungen
und Regeln der <code>.htaccess</code>-Konfiguration des
übergeordneten
Verzeichnisses übernommen.</dd>
<dt><code>MaxRedirects=<var>Anzahl</var></code></dt>
<dd>Um Endlosschleifen durch interne Umleitungen (ausgelöst durch
<directive module="mod_rewrite">RewriteRule</directive>)
zu verhindern, bricht <module>mod_rewrite</module> die Anfrage
nach Erreichen der maximalen Anzahl von Umleitungen ab und
antwortet mit <code>500 Internal Server Error</code>. Werden
tatsächlich mehr als 10 Umleitungen pro Anfrage benötigt, kann
der Standardwert erhöht werden.</dd>
</dl>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>RewriteLog</name>
<description>Gibt den Namen der Protokolldatei für die Aktionen der
Rewriting
Engine an.</description>
<syntax>RewriteLog <em>Dateipfad</em></syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p>Die <directive>RewriteLog</directive>-Direktive gibt den Namen
der Protokolldatei an, in der der Server durchgeführte Manipulationen
protokolliert. Beginnt der Name nicht mit einem
Schrägstrich (<code>/</code>), wird er relativ zur
<em>Server Root</em> interpretiert. Die Direktive sollte nur einmal
in der Serverkonfiguration erscheinen.</p>
<note>Um die Protokollierung von Manipulationen zu deaktivieren,
sollte nicht <code>/dev/null</code> als <em>Dateiname</em> angegeben
werden, weil die Rewriting Engine dann zwar keine Ausgaben in eine
Protokolldatei schreibt, diese Ausgaben aber trotzdem intern erzeugt werden,
<strong>was zu einer überflüssigen Belastung des Servers führt
.</strong>
Stattdessen sollte die <directive>RewriteLog</directive>-Direktive entfernt,
als Kommentar gekennzeichnet oder der
<code>RewriteLogLevel</code> auf <code>0</code> gesetzt werden.
</note>
<note type="securitywarning"><title>Sicherheit</title>
Unter <a href="../misc/security_tips.html">Tipps zur Sicherheit</a>
finden Sie weitere Einzelheiten dazu, warum die Sicherheit gefährdet ist,
wenn
jemand anders als derjenige, der den Server gestartet hat, in das Verzeichnis
mit den Protokolldateien schreiben darf.
</note>
<example><title>Beispiel</title>
RewriteLog "/usr/local/var/apache/logs/rewrite.log"
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>RewriteLogLevel</name>
<description>Legt die Ausführlichkeit der Einträge der Rewriting
Engine in die Protokolldatei fest.</description>
<syntax>RewriteLogLevel <em>Level</em></syntax>
<default>RewriteLogLevel 0</default>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p>Die <directive>RewriteLogLevel</directive>-Direktive legt die
die Ebene der Ausführlichkeit für das Manipulationsprotokoll
fest. Bei der
Standardeinstellung <code>0</code> erfolgte keine Protokollierung
und bei der Einstellung <code>9</code> oder höher werden praktisch
alle Aktionen aufgezeichnet.</p>
<p>Wird für <em>Level </em> <code>0</code> angegeben, werden
keine Aktionen protokolliert.</p>
<note> Umso höher der für <em>Level</em> angegebene Wert ist, um so
stärker verlangsamt sich der Apache-Server. Ein höherer Wert als
<code>2</code>
sollte nur für die Fehlersuche benutzt werden.
</note>
<example><title>Beispiel</title>
RewriteLogLevel 3
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>RewriteLock</name>
<description>Gibt den Namen der Sperrdatei für die
<directive module="mod_rewrite">RewriteMap</directive>-
Synchronisation an.</description>
<syntax>RewriteLock <em>Dateipfad</em></syntax>
<contextlist><context>server config</context></contextlist>
<usage>
<p>Diese Direktive gibt den Dateinamen für Sperreinträge zur
Synchronisation zwischen <code>mod_rewrite</code>
und <directive
module="mod_rewrite">RewriteMap</directive>-<em>Programmen</em>
an. Bei Verwendung eines Map-Programms sollte ein lokaler Pfad
und kein eingebundens NFS-Dateisystem angegeben werden. Die
Direktive muss nur für diese Art von Map-Programmen angegeben
werden.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>RewriteMap</name>
<description>Definiert eine Mapping-Funktion für die
Schlüsselsuche.</description>
<syntax>RewriteMap <em>MapName</em> <em> MapTyp</em>:<em>MapQuelle</em>
</syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<compatibility>Die Auswahl zwischen mehreren DBM-Typen steht
seit Apache 2.0.41 zur Verfügung.</compatibility>
<usage>
<p>Die <directive>RewriteMap</directive>-Direktive definiert ein
<em>Rewriting Map</em>, das in Ersetzungszeichenfolgen für Regeln
von den Mapping-Funktionen für das Einfügen oder Ersetzen von
Feldern
über eine Schlüsselsuche benutzt werden kann. Die Suche kann in
Quellen
unterschiedlichen Typs erfolgen.</p>
<p>Über das namentlich angegebene Map wird eine Mapping-Funktion
für die Ersetzungszeichenfolgen einer Manipulationregel wie folgt
angegeben:</p>
<p class="indent">
<strong><code>${</code> <em>MapName</em> <code>:</code>
<em>Schlüssel</em> <code>}</code><br />
<code>${</code> <em>MapName</em> <code>:</code>
<em>Schlüssel</em> <code>|</code> <em>Standardwert</em>
<code>}</code></strong>
</p>
<p>Taucht so ein Konstrukt im Map auf, wird im mit <em>MapName</em>
angegebenen Map nachgesehen und der <em>Schlüssel</em> gesucht.
Wird er gefunden, wird das Konstrukt durch <em>SubstWert</em>
ersetzt. Wird der Schlüssel nicht gefunden, wird es durch den
<em>Standardwert</em> oder, falls dieser nicht angegeben wurde,
durch eine leere Zeichenfolge ersetzt.</p>
<p>Die folgenden Kombinationen für <em>MapTyp</em> und
<em>MapQuelle</em> können verwendet werden:</p>
<ul>
<li>
<strong>Text</strong><br />
<code>MapType</code>: <code>txt</code>, <code>MapQuelle</code>:
Unix-Pfad zu einer Datei
<p>Dies ist die standardmäßige Map-Umschreibung, bei der
<em>MapQuelle</em> eine ASCII-Datei mit Leerzeilen, Kommentarzeilen
mit einem <code>#</code>-Zeichen am Anfang oder Paaren wie den folgenden
(jeweils eines pro Zeile) ist:</p>
<p class="indent">
<strong><em>MatchingKey</em>
<em>SubstWert</em></strong>
</p>
<example><title>Beispiel</title>
<pre>
##
## map.txt -- Rewriting-Map
##
Ralf.S.Engelschall rse # Bastard Operator From Hell
Mr.Joe.Average joe # Mr. Average
</pre>
</example>
<example>
RewriteMap real-to-user txt:/Pfad/zu/Datei/map.txt
</example>
</li>
<li>
<strong>Random-Text</strong><br />
<code>MapType</code>: <code>rnd</code>, <code>MapQuelle</code>:
Unix-Pfad zu regulärer Datei
<p>Diese Variante ist mit der oben aufgeführten Text-Variante
identisch,
besitzt aber eine speziele Nachbearbeitungseigenschaft: Nach dem ein
Wert
gefunden wurde, wird er nach enthaltenen <code>|</code>-Zeichen
untersucht, die für "oder" stehen. Sie kennzeichnen eine Reihe
von
Alternativen, aus denen der tatsächlich zurückgegebene Wert
zufällig
ausgewählt wird. Auch wenn das nicht einleuchtend erscheinen mag,
das Verfahren wurde ursprünglich für den Lastausgleich bei
Reverse-Proxies entwickelt, wo es sich bei den gesuchten Werten
um Servernamen handelt. Beispiel:</p>
<example>
<pre>
##
## map.txt -- Rewriting-Map
##
static www1|www2|www3|www4
dynamic www5|www6
</pre>
</example>
<example>
RewriteMap servers rnd:/Pfad/zu/Datei/map.txt
</example>
</li>
<li>
<strong>Hash-Datei</strong><br /> <code>MapType</code>:
<code>dbm[=<em>type</em>]</code>, <code>MapQuelle</code>: Unix-Pfad
zu einer
regulären Datei
<p>Die Quelle ist eine binäre DBM-Datei mit dem gleichen Inhalt
wie eine <em>Textdatei</em>, der jedoch für ein sehr schnelles
Suchen
besonders aufbereitet wurde. Der <em>Typ </em> kann je nach den
Kompilereinstellungen <code>sdbm</code>, <code>gdbm</code>,
<code>ndbm</code> oder <code>db</code> sein. Wird der
<em>Typ</em> weggelassen, wird die Standardvorgabe genommen.
Eine solche Datei kann mit einem DBM-Programm oder dem folgenden
Perl-Skript erstellt werden. Nehmen Sie die entsprechenden Anpassungen
für den zu erzeugenden DBM-Typ vor. Das Beispiel erzeugt eine
NDBM-Datei.</p>
<example>
<pre>
#!/path/to/bin/perl
##
## txt2dbm -- Umwandlung txt map in dbm-Format
##
use NDBM_File;
use Fcntl;
($txtmap, $dbmmap) = @ARGV;
open(TXT, "<$txtmap") or die "Couldn't open $txtmap!\n";
tie (%DB, 'NDBM_File', $dbmmap,O_RDWR|O_TRUNC|O_CREAT, 0644)
or die "Couldn't create $dbmmap!\n";
while (<TXT>) {
next if (/^\s*#/ oder /^\s*$/);
$DB{$1} = $2 if (/^\s*(\S+)\s+(\S+)/);
}
untie %DB;
close(TXT);
</pre>
</example>
<example>
$ txt2dbm map.txt map.db
</example>
</li>
<li>
<strong>Intern</strong><br />
<code>MapType</code>: <code>int</code>, <code>MapQuelle</code>:
Interne Apache-Funktion
<p>Diesmal ist die Quelle eine interne Apache-Funktion.
Zur Zeit können keine eigenen Funktionen eingerichtet werden,
die folgenden Funktionen sind aber bereits vorhanden:</p>
<ul>
<li><strong>toupper</strong>:<br />
Wandelt den gesuchten Schlüssel in Großbuchstaben
um.</li>
<li><strong>tolower</strong>:<br />
Wandelt den gesuchten Schlüssel in Kleinbuchstaben um.</li>
<li><strong>escape</strong>:<br />
Wandelt Sonderzeichen im gesuchten Schlüssel in hexadezimale
Kodierung um.</li>
<li><strong>unescape</strong>:<br />
Wandelt hexadezimale Kodierungen wieder zurück in
Sonderzeichen.</li>
</ul>
</li>
<li>
<strong>Externes Rewriting-Programm</strong><br />
<code>MapType</code>: <code>prg</code>, <code>MapQuelle</code>
: Unix-Pfad zu einer regulären Datei
<p>In diesem Fall ist ein Programm und nicht eine Map-Datei die
Quelle.
Es kann mit einer beliebigen Programmiersprache erstellt werden, muss
aber ausführbar sein (Objektcode oder ein Skript mit dem Magic
Cookie-Trick <code>#!/Pfad/zum/Interpreter</code> als erste
Zeile).</p>
<p>Das Programm wird einmal beim Start des Apache-Servers
aufgerufen und kommuniziert dann über <code>stdin</code> und
<code>stdout</code> mit der Rewriting Engine. Bei jeder
Map-Funktionssuche erhält es über <code>stdin</code> den
Suchschlüssel als Zeichenfolge mit einem Zeilenvorschub am
Schluss.
Der gefundene Wert wird ebenfalls als Zeichenfolge mit einem
Zeilenvorschub über <code>stdout</code> zurückgegeben.
Liegt kein
Wert für den Schlüssel vor, wird <code>NULL</code>
zurückgeliefert.
Ein einfaches Programmm, das ein 1:1-Map (<code>Schlüssel==
Wert</code>) implementiert, könnte folgendermaßen
aussehen:</p>
<example>
<pre>
#!/usr/bin/perl
$| = 1;
while (<STDIN>) {
# ...hier folgen die Umwandlungen und Suchen...
print $_;
}
</pre>
</example>
<p>Vorsicht:</p>
<ol>
<li>"<em>Keep it simple, stupid</em>'' (KISS), denn ist das
Programm fehlerhaft, stürzt der Apache-Server ab, wenn die
Regel
angewendet wird.</li>
<li>Vermeiden Sie einen weit verbreiteten Fehler: Führen Sie
niemals
eine gepufferte Ein- und Ausgabe über <code>stdout</code>
durch,
weil das zu einer Endlosschleife führen kann. (Daher steht im
Beispiel
der Code <code>$|=1</code>...</li>
<li>Definieren Sie mit der<directive
module="mod_rewrite">RewriteLock</directive>-Direktive eine
Sperrdatei, mit der <code>mod_rewrite</code>die Kommunikation
mit dem Programm synchronisieren kann. Standardmäßig
wird keine Synchronisation durchgeführt.</li>
</ol>
</li>
</ul>
<p>Die <directive>RewriteMap</directive>-Direktive kann mehrfach
aufgeführt werden. Für jede Mapping-Funktion wird mit einer
<directive>RewriteMap</directive>-Direktive die Map-Datei deklariert.
Im Verzeichniskontext kann zwar kein Map <strong>deklariert</strong>
werden, das Map darf aber in diesem Kontext <strong>verwendet</strong>
werden. </p>
<note><title>Hinweis</title> Bei einfachen Textdateien und DBM-Dateien
werden die Suchschlüssel solange zwischengespeichert, bis sich
der Wert <code>mtime</code> der Map-Datei ändert oder der Server
neu gestartet wird. Auf diese Weise können Regeln Map-Funktionen
enthalten, die für <strong>jede</strong> Anfrage benutzt werden. Das
stellt kein Problem dar, denn die externe Suche wird nur einmal
durchgeführt.
</note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>RewriteBase</name>
<description>Setzt die Basis-URL für den Verzeichniskontext.</description>
<syntax>RewriteBase <em>URL-Pfad</em></syntax>
<default>Informationen hierzu folgen in der Beschreibung.</default>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>FileInfo</override>
<usage>
<p>Die <directive>RewriteBase</directive>-Direktive setzt explizit
die Basis-URL für weitere URL-Manipulationen. Wie im Beispiel noch
deutlich wird, kann
<directive module="mod_rewrite">RewriteRule</directive>
in der <code>.htaccess</code>-Datei eines Verzeichnisses
verwendet werden. Dort wirkt sie lokal, <em>d.h.</em> der lokale
Verzeichnispräfix wird in dieser Phase der Verarbeitung abgetrennt
und die Rewriting-Regeln wirken sich nur auf den verbleibenden Rest aus.
Am Schluss wird er automatisch wieder hinzugefügt. Die
Standardeinstellung ist <directive>RewriteBase</directive>
<em> physischer Verzeichnispfad</em>.</p>
<p>Kommt es zu einer Ersetzung für eine neue URL, muss dieses Modul
diese URL wieder in die Verarbeitung einbinden. Hierfür muss es
den entsprechenden URL-Präfix oder die URL-Basis kennen.
Standardmäßig entspricht dieser Präfix dem Dateipfad.
<strong>Bei den meisten Websites stehen URLs aber NICHT in direkter
Beziehung zum tatsächlichen Dateipfad, so dass dies normalerweise
nicht zutrifft.</strong> Daher muss der korrekte URL-Präfix mit der
<code>RewriteBase</code>-Direktive angegeben werden.</p>
<note> Stehen die URLs des Webservers <strong>nicht</strong> in direkter
Beziehung zu tatsächlichen Dateipfaden, dann müssen Sie in jeder
<code>.htaccess</code>-Datei, in der
<directive module="mod_rewrite">RewriteRule</directive>-Direktiven
verwendet werden sollen, die <directive>RewriteBase</directive>-Direktive
benutzen.
</note>
<p> Ein Beispiel:</p>
<example>
<pre>
#
# /abc/def/.htaccess -- Konfigurationsdatei für das Verz. /abc/def
# Achtung: /abc/def ist der tatsächliche Pfad für /xyz,
<em>d.h.</em>, der Server
# erhält eine 'Alias /xyz /abc/def'-Direktive
#
RewriteEngine On
# Dem Server wird mitgeteilt, dass das Ziel über /xyz und nicht
# über den Präfix mit dem tatsächlichen Pfad /abc/def
# erreicht wird.
RewriteBase /xyz
# Rewriting-Regeln:
RewriteRule ^oldstuff\.html$ newstuff.html
</pre>
</example>
<p>In diesem Beispiel wird ein Anfrage nach
<code>/xyz/oldstuff.html</code> korrekt für den tatsächlichen
Pfad zu
<code>/abc/def/newstuff.html</code> umgeschrieben.</p>
<note><title>Für Apache-Hacker</title>
<p>Die folgende Liste führt die internen Verarbeitungsschritte detailliert
auf:</p>
<pre>
Anfrage:
/xyz/oldstuff.html
Interne Verarbeitung:
/xyz/oldstuff.html -> /abc/def/oldstuff.html (per-server Alias)
/abc/def/oldstuff.html -> /abc/def/newstuff.html (per-dir RewriteRule)
/abc/def/newstuff.html -> /xyz/newstuff.html (per-dir RewriteBase)
/xyz/newstuff.html -> /abc/def/newstuff.html (per-server Alias)
Ergebnis:
/abc/def/newstuff.html
</pre>
<p>Das erscheint sehr kompliziert, entspricht aber der korrekten internen
Verarbeitung des Apache, weil die Manipilation auf Verzeichnisebene
zu spät im Prozess erfolgt. Daher muss die (umgeschriebene) Anfrage
wieder in den Apache-Kern zurückgestellt werden. ABER: Auch wenn das Ganze
wie ein übermäßiger Aufwand erscheint, trifft dies dennoch
nicht zu, da die
Rückstellung vollständig intern erfolgt und das gleiche Verfahren von
vielen
anderen Operationen innerhalb des Servers genutzt wird. Daher sind Design und
Implementierung völlig korrekt.</p>
</note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>RewriteCond</name>
<description>Definiert eine Bedingung, der unter eine Umschreibung stattfindet.
</description>
<syntax> RewriteCond
<em>TestString</em> <em> BedMuster</em></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context></contextlist>
<override>FileInfo</override>
<usage>
<p>Die <directive>RewriteCond</directive>-Direktive definiert eine
Bedingung für eine Regel. Einer <directive
module="mod_rewrite">RewriteRule</directive>-Direktive werden eine
oder mehrere <directive>RewriteCond</directive>-Direktiven vorangestellt.
Die darauf folgende Manipulationregel tritt nur in Kraft, wenn das Muster
mit
dem aktuellen Zustand der URL übereinstimmt <strong>und</strong>
wenn diese zusätzlichen Bedingungen gleichfalls erfüllt
sind.</p>
<p><em>TestString</em> ist eine Zeichenfolge die neben einfachem Text
folgende Elemente enthält:</p>
<ul>
<li>
<strong>RewriteRule-Rückverweise</strong>: Dies sind
Rückverweise in der Form:
<p class="indent">
<strong><code>$N</code></strong>
</p>
(.
</li>
<li>
<strong>RewriteCond-Rückverweise</strong>: Dies sind
Rückverweise in der Form:
<p class="indent">
<strong><code>%N</code></strong>
</p>
(1 <= N <= 9) gewährt von der letzten verglichenen
<code>RewriteCond</code>-Direktive der aktuell verglichenen
Bedingungen aus Zugriff auf die gruppierten
Teile des Musters (Klammerausdrücke)
</li>
<li>
<strong>RewriteMap-Expansionen</strong>: Dies sind Expansionen der
Form:
<p class="indent">
<strong><code>${MapName:Schlüssel|Voreinstellung}</code></strong>
</p>
Unter <a href="#mapfunc"><code>RewriteMap</code></a> finden Sie
weitere
Einzelheiten hierzu.
</li>
<li>
<strong>Server-Variablen</strong>: Dies sind Variablen der Form:
<p class="indent">
<strong><code>%{</code> <em>NAME_DER_VARIABLEN</em>
<code>}</code></strong>
</p>
Der <em>NAME_DER_VARIABLEN</em> kann eine Zeichenfolge aus
der nachstehenden Liste sein:
<table>
<tr>
<th>HTTP-Header:</th> <th>Verbindung & Anfrage:</th> <th></th>
</tr>
<tr>
<td>
HTTP_USER_AGENT<br />
HTTP_REFERER<br />
HTTP_COOKIE<br />
HTTP_FORWARDED<br />
HTTP_HOST<br />
HTTP_PROXY_CONNECTION<br />
HTTP_ACCEPT<br />
</td>
<td>
REMOTE_ADDR<br />
REMOTE_HOST<br />
REMOTE_USER<br />
REMOTE_IDENT<br />
REQUEST_METHOD<br />
SCRIPT_FILENAME<br />
PATH_INFO<br />
QUERY_STRING<br />
AUTH_TYPE<br />
</td>
<td></td>
</tr>
<tr>
<th>Server-Interna:</th> <th>System:</th> <th>Speziell:</th>
</tr>
<tr>
<td>
DOCUMENT_ROOT<br />
SERVER_ADMIN<br />
SERVER_NAME<br />
SERVER_ADDR<br />
SERVER_PORT<br />
SERVER_PROTOCOL<br />
SERVER_SOFTWARE<br />
</td>
<td>
TIME_YEAR<br />
TIME_MON<br />
TIME_DAY<br />
TIME_HOUR<br />
TIME_MIN<br />
TIME_SEC<br />
TIME_WDAY<br />
TIME<br />
</td>
<td>
API_VERSION<br />
THE_REQUEST<br />
REQUEST_URI<br />
REQUEST_FILENAME<br />
IS_SUBREQ<br />
</td>
</tr>
</table>
<note>
<p>Diese Varaiblen entsprechen alle ähnlich bezeichneten HTTP MIME-Headern,
C-Variablen des Apache-Servers oder <code>struct tm</code>-Feldern des
Unix-Systems. Die meisten von ihnen werden an anderer Stelle oder in der
CGI-Spezifikation beschrieben. Spezielle Variablen für
<code>mod_rewrite</code> sind:</p>
<dl>
<dt><code>IS_SUBREQ</code></dt>
<dd>Enthält den Wert <code>true</code>, wenn die gerade
verarbeitete Anfrage eine Unteranfrage ist, sonst
enthält sie den Wert
<code>false</code>. Unteranfragen können von Modulen
erzeugt
werden, die für ihre Aufgaben weitere URLs auflösen
müssen.</dd>
<dt><code>API_VERSION</code></dt>
<dd>Die Version der Apache Modul-API (die interne
Schnittstelle zwischen Server und Modul) des aktuellen
httpd-Build, wie er in <code>include/ap_mmn.h</code> definiert
ist. Die API-Version entspricht der verwendeten Apache-Version
(für die Apache-Version 1.3.14 ist es beispielsweise
19990320:10),
was jedoch hauptsächlich für Modulentwickler von
Interesse ist.</dd>
<dt><code>THE_REQUEST</code></dt>
<dd>Die vollständige Zeile der HTTP-Anfrage, die vom
Browser an
den Server gesendet wird (z.B. <code>GET
/index.html HTTP/1.1</code>). Sie enthält keine weiteren
vom
Browser gesendeten Header.</dd>
<dt><code>REQUEST_URI</code></dt>
<dd>Die in der HTTP-Anfragezeile angeforderte Ressource. (Im
Beispiel oben wäre das <code>/index.html</code>.)</dd>
<dt><code>REQUEST_FILENAME</code></dt>
<dd>Der vollständige Pfad zur Datei oder dem Skript im
lokalen
Dateisystem.</dd>
</dl>
</note>
</li>
</ul>
<p>Spezielle Hinweise:</p>
<ol>
<li>Die Variablen SCRIPT_FILENAME und REQUEST_FILENAME
enthalten den gleichen Wert, nämlich den Wert des Feldes
<code>filename</code> der internen
<code>request_rec</code>-Struktur des Apache-Servers. Der erste Name
ist der bekannte CGI-Variablename während der zweite die
konsistente
Entsprechung für REQUEST_URI (mit dem Wert des
<code>uri</code>-Felds von <code>request_rec</code>) angibt.</li>
<li>Beim speziellen Format <code>%{ENV:Variable}</code> kann die
<em>Variable</em> eine beliebige Umgebungsvariable sein. Sie wird in
internen Apache-Strukturen oder falls sie dort nicht gefunden wird,
mit <code>getenv()</code> über den Apache-Serverprozess
gesucht.</li>
<li>Beim speziellen Format <code>%{HTTP:header}</code> kann der
<em>header</em> ein beliebiger HTTP-MIME-Header sein. Er wird in der
HTTP-Anfrage gesucht. Zum Beispiel:
<code>%{HTTP:Proxy-Connection}</code> ist der Wert des
HTTP-Headers <code>Proxy-Connection:</code>.</li>
<li>Beim speziellen Format <code>%{LA-U:Variable}</code> steht
<code>LA</code> für "Look-Ahead" und veranlasst (auf URL-Basis)
eine
interne Unterabfrage, um den endgültigen Wert der
<em>Variablen</em>
zu bestimmen. Es wird verwendet, wenn eine Variable, die erst
später in
einer API-Phase gesetzt wird, für Manipulationen benutzt werden
soll und
daher zum aktuellen Zeitpunkt nicht zur Verfügung steht. Wenn Sie
beispielsweise entsprechend der <code>REMOTE_USER</code>-Variablen
aus dem Serverkontext (<code>httpd.conf</code>-Datei) umschreiben
möchten, dann müssen Sie <code>%{LA-U:REMOTE_USER}</code>
benutzen, weil diese Variable während der Authorisierungsphase
gesetzt wird,
die <em>nach</em> der URL-Umwandlungsphase folgt, in der
<code>mod_rewrite</code> operiert. Da <code>mod_rewrite</code>
aber seinen Verzeichniskontext (<code>.htaccess</code>-Datei) über
die Fixup-Phase der API implementiert und weil die Authorisierungsphase
<em>vor</em> dieser Phase liegt, kann hier einfach
<code>%{REMOTE_USER}</code> benutzt werden.</li>
<li>Das spezielle Format <code>%{LA-F:Variable}</code> führt eine
interne Unterabfrage (auf Basis des Dateinamens) durch, um den
endgültigen Wert der <em>Variablen</em> zu ermitteln. Meist ist das
Ergebnis das gleiche wie bei <code>%{LA-U:Variable}</code>.</li>
</ol>
<p>Das Bedingungsmuster <em>BedMuster</em> ist ein regulärer
Ausdruck, der auf die aktuelle Instanz des <em>TestString</em> angewendet
wird, <em>d.h.</em> der <em>TestString</em> wird ausgewertet und
dann mit <em>BedMuster</em> verglichen.</p>
<p><strong>Beachten Sie:</strong> <em> BedMuster</em> ist mit
einigen Ergänzungen ein
<em>Perl-kompatibler regulärer Ausdruck</em>:</p>
<ol>
<li>Der Musterzeichenfolge kann ein <code>!</code>-Zeichen
vorangestellt werden, um ein <em>nicht</em> übereinstimmendes
Muster anzugeben.</li>
<li>
Für die Bedingungsmuster gibt es einige spezielle Varianten.
Anstelle
tatsächlicher regulärer Ausdrücke sind auch folgende
Formulierungen möglich:
<ul>
<li>'<strong><CondPattern</strong>' ist lexikografisch
kleiner)<br />
Behandelt <em>BedMuster</em> wie eine einfache Zeichenfolge
und vergleicht sie lexikografisch mit <em>TestString</em>. Ist
<em>TestString</em> lexikografisch kleiner als <em>BedMuster</em>,
ist die Bedingung erfüllt.</li>
<li>'<strong>>CondPattern</strong>' (ist lexikografisch
größer)<br />
Behandelt <em>BedMuster</em> wie eine einfache Zeichenfolge
und vergleicht sie lexikografisch mit <em>TestString</em>. Ist
<em>TestString</em> lexikografisch größer als
<em>BedMuster</em>,
ist die Bedingung erfüllt.</li>
<li>'<strong>=CondPattern</strong>' (ist lexikografisch gleich)<br
/>
Behandelt <em>BedMuster</em> wie eine einfache Zeichenfolge
und vergleicht sie lexikografisch mit <em>TestString</em>. Ist
<em>TestString</em> lexikografisch gleich <em>BedMuster</em>,
ist die Bedingung erfüllt, d.h. die beiden Zeichenfolgen sind
exakt
(Zeichen für Zeichen) gleich. Enthält <em>BedMuster</em>
nur zwei
Anführungszeichen (<code>""</code>), wird <em>TestString</em>
mit der leeren Zeichenfolge verglichen.</li>
<li>'<strong>-d</strong>' (ist ein Verzeichnis:
<strong>d</strong>irectory)<br />
Behandelt <em>TestString</em> als Pfadangabe und prüft, ob es
vorhanden und ein Verzeichnis ist.</li>
<li>'<strong>-f</strong>' (ist eine Datei:
<strong>f</strong>ile)<br />
Behandelt <em>TestString</em> als Dateiangabe und prüft, ob
sie
vorhanden und eine Datei ist.</li>
<li>'<strong>-s</strong>' (ist eine Datei mit der Größe
<strong>s</strong> für Size)<br />
Behandelt <em>TestString</em> als Pfadangabe und prüft, ob die
Datei mit einer Größe größer als null
vorhanden ist.</li>
<li>'<strong>-l</strong>' (ist ein symbolischer
<strong>L</strong>ink)<br />
Behandelt <em>TestString</em> als Pfadangabe und prüft, ob er
vorhanden und ein symbolischer Link ist.</li>
<li>'<strong>-F</strong>' (ist eine Datei über
Unteranfrage)<br />
Prüft, ob <em>TestString</em> eine gültige Datei ist, die
über alle
zur Zeit für den Server konfigurierten Zugriffsberechtigungen
für
diesen Pfad zugreifbar ist. Hierfür wird eine interne
Unterabfrage
verwendet, so dass Vorsicht geboten ist, da der Server hierdurch
belastet wird.</li>
<li>'<strong>-U</strong>' (ist eine vorhandene URL über
Unteranfrage)<br />
Prüft, ob <em>TestString</em> eine gültige URL ist und ob
der
Zugriff über alle zur Zeit für den Server konfigurierten
Zugriffsrechte
zugänglich ist. Hierfür wird eine interne Unterabfrage
verwendet, so dass Vorsicht geboten ist, da der Server hierdurch
belastet wird.</li>
</ul>
<note><title>Hinweis</title>
Bei allen Tests kann ein Ausrufezeichen <code>!</code>
vorangestellt werden, um die Bedingung zu negieren.
</note>
</li>
</ol>
<p>Darüberhinaus können für <em>BedMuster</em>
bestimmte</p>
<p class="indent">
<strong><code>[</code><em>Flags</em><code>]</code></strong>
</p>
<p>gesetzt werden, die der <code>RewriteCond</code>-Direktive
als drittes Argument übergeben werden. Folgende <em>Flags</em>
können
mit einer durch Kommata getrennten Liste übergeben werden:</p>
<ul>
<li>'<strong><code>nocase|NC</code></strong>'
(<strong>n</strong>o <strong>c</strong>ase)<br />
Beim Test werden Groß- und Kleinschreibung nicht unterschieden,
<em>d.h.</em> zwischen 'A-Z' und 'a-z' gibt es weder im expandierten
<em>TestString</em> noch im <em>BedMuster</em> einen
Unterschied. Dieses Flag hat nur auf die Vergleiche zwischen
<em>TestString</em> und <em>BedMuster</em> eine Auswirkung, nicht
jedoch bei Überprüfungen des Dateisystems und bei
Unteranfragen.</li>
<li>
'<strong><code>ornext|OR</code></strong>'
(<strong>oder</strong> next condition)<br />
Kombiniert Regelbedingungen mit einem lokalen ODER anstelle eines
impliziten UND. Ein typisches Beispiel:
<example>
<pre>
RewriteCond %{REMOTE_HOST} ^host1.* [OR]
RewriteCond %{REMOTE_HOST} ^host2.* [OR]
RewriteCond %{REMOTE_HOST} ^host3.*
RewriteRule ...speziele Anweisungen für die Hosts...
</pre>
</example>
Ohne dieses Flag müssten die Anweisungen dreimal geschrieben
werden.
</li>
</ul>
<p><strong>Beispiel:</strong></p>
<p>Die Homepage einer Site kann entsprechend dem
<code>User-Agent:</code>-Header der Anfrage wie folgt umgeschrieben
werden: </p>
<example>
<pre>
RewriteCond %{HTTP_USER_AGENT} ^Mozilla.*
RewriteRule ^/$ /homepage.max.html [L]
RewriteCond %{HTTP_USER_AGENT} ^Lynx.*
RewriteRule ^/$ /homepage.min.html [L]
RewriteRule ^/$ /homepage.std.html [L]
</pre>
</example>
<p>Interpretation: Dient der Netscape Navigator als Browser (der sich
als 'Mozilla' identifiziert), wird die max-Homepage mit Frames, <em>usw.</em>
gesendet. An den Lynx Browser (auf Terminalbasis) wird die min-Homepage
ohne Bilder, Tabellen <em>usw.</em> gesendet. Jeder andere Browser
erhält die Standard-Homepage.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>RewriteRule</name>
<description>Definiert Regeln für die Rewriting Engine.</description>
<syntax>RewriteRule
<em>Muster</em> <em>Substitution</em></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context></contextlist>
<override>FileInfo</override>
<compatibility>Das Cookie-Flag steht seit der Apache-Version 2.0.40
zur Verfügung.</compatibility>
<usage>
<p>Die <directive>RewriteRule</directive>-Direktive spielt die zentrale
Rolle beim Umschreiben. Wird sie mehrfach aufgeführt, definiert jede
Direktive eine Manipulationregel. Die <strong>Reihenfolge</strong>
bei der Definition der Regel ist von Bedeutung, weil sie der Anwendung
der Regel während der Ausführung zugrunde liegt.</p>
<p><a id="patterns" name="patterns">Das <em>Muster</em></a> ist
ein Perl-kompatibler <a id="regexp" name="regexp">regulärer
Ausdruck</a>, der für die aktuelle URL angewendet wird. "Aktuell"
bedeutet
hier die URL zum Zeitpunkt der Regelanwendung. Das muss nicht die
ursprünglich angeforderte URL sein, weil möglicherweise bereits
andere Regeln
angewendet und Manipulationen vorgenommen wurden.</p>
<p>Einige Hinweise zur Syntax regulärer Ausdrücke:</p>
<note><pre>
<strong>Text:</strong>
<strong><code>.</code></strong> Ein beliebiges einzelnes Zeichen
<strong><code>[</code></strong>chars<strong><code>]</code></strong>
Zeichenklasse: Eins aus chars
<strong><code>[^</code></strong>chars<strong><code>]</code></strong>
Zeichenklasse: Keins aus chars
text1<strong><code>|</code></strong>text2 Alternativ: text1 oder text2
<strong>Quantifizerer:</strong>
<strong><code>?</code></strong> 0 oder 1 aus dem vorhergehenden Text
<strong><code>*</code></strong> 0 oder N aus dem vorhergehenden
Text (N > 0)
<strong><code>+</code></strong> 1 oder N aus dem vorhergehenden
Text (N > 1)
<strong>Gruppierung:</strong>
<strong><code>(</code></strong>Text<strong><code>)</code></strong>
Gruppierung von Text
(entweder um die Grenzen einer Alternative zu setzen oder
für Rückverweise wobei die <strong>N</strong>te Gruppe
für den RHS
einer Manipulationregel <code>$</code><strong>N</strong>
genutzt werden kann.)
<strong>Anker:</strong>
<strong><code>^</code></strong> Start der Ankerlinie
<strong><code>$</code></strong> Ende der Ankerlinie
<strong>Übergehen:</strong>
<strong><code>\</code></strong>char Übergehe das Zeichen char
(zum Beispiel für die Zeichen "<code>.[]()</code>"
<em>usw.</em>)
</pre></note>
<p>Weitere Informationen zu den regulären Ausdrücken finden Sie
in der
("<a href="http://www.perldoc.com/perl5.6.1/pod/perlre.html";>
Perl-Dokumentation</a>"). Weitere interessante Details zu regulären
Ausdrücken und ihren Varianten (POSIX regex <em>usw.</em>) finden Sie
unter diesem Thema in folgenden Büchern:</p>
<p class="indent">
<em>Mastering Regular Expressions</em><br />
Jeffrey E.F. Friedl<br />
Nutshell Handbook Series<br />
O'Reilly & Associates, Inc. 1997<br />
ISBN 1-56592-257-3<br />
</p>
<p>In Verbindung mit <code>mod_rewrite</code> darf das NICHT-Zeichen
(<code>!</code>) als Präfix benutzt werden, um ein Muster zu
negieren.
Ein Beispiel: "<em>Wenn die aktuelle URL <strong>NICHT</strong> mit
diesem Muster übereinstimmt</em>''. Diese Möglichkeit kann in
Ausnahmefällen gewählt werden, wo ein negativer Vergleich
einfacher ist
oder für eine abschließende Standardregel.</p>
<note><title>Hinweis</title>
Bei Verwendung des NICHT-Zeichens für die Negation eines Musters darf
das Muster keine gruppierten Teile mit Jokerzeichen enthalten. Das ist nicht
zulässig, denn trifft das Muster NICHT zu, dann haben die Gruppen keine
Inhalte. Dementsprechend kann bei Verwendung negierter Muster auch nicht
<code>$N</code> in der Ersetzungszeichenfolge stehen.
</note>
<p><a id="rhs" name="rhs"><em>Substitution</em></a> ist die
Zeichenfolge, die für die ursprüngliche URL eingesetzt wird,
für die
das <em>Muster</em> übereinstimmt. Neben einfachem Text sind
folgende Angaben möglich:</p>
<ol>
<li>Rückverweise <code>$N</code> auf das <code>RewriteRule
</code>-Muster</li>
<li>Rückverweise <code>%N</code> auf das letzte verglichene
<code>RewriteCond</code>-Muster</li>
<li>Server-Variablen wie Zeichenfolgen für Regelbedingungen
(<code>%{VARNAME}</code>)</li>
<li><a href="#mapfunc">Mapping-Funktion</a>saufrufe
(<code>${mapname:key|default}</code>)</li>
</ol>
<p>Rückverweise sind <code>$</code><strong>N</strong>
(<strong>N</strong>=0..9)-Bezeichner, die durch den Inhalt der
<strong>N</strong>-ten Gruppe des verglichenen <em>Musters</em>
ersetzt werden. Die Server-Variablen sind die gleichen wie für den
<em>TestString</em> einer <code>RewriteCond</code>-Direktive.
Die Mapping-Funktionen stammen von der
<code>RewriteMap</code>-Direktive und werden dort erklärt.
Diese drei Arten von Variablen werden in der oben aufgeführten
Reihenfolge expandiert. </p>
<p>Wie bereits erwähnt wurde, werden alle Manipulationregeln
für die <em>Substitution</em> angewendet (in der Reihenfolge
ihrer Definition in der Konfigurationdatei). Die URL wird
<strong>vollständig</strong> durch die <em>Substitution</em>
ersetzt und die Manipulationen werden fortgesetzt, bis keine Regeln
mehr anzuwenden sind, es sei denn, sie werden explizit durch ein
<code><strong>L</strong></code>-Flag beendet (siehe unten).</p>
<p>Das spezielle Substitutionelement <code>-</code> bedeutet, dass
<strong>KEINE Substitution</strong> erfolgt. Das mag seltsam erscheinen,
ist aber sinnvoll, um Manipulationsregeln bereitstellen zu können,
die URLs
<strong>nur</strong> vergleichen, ohne eine Ersetzung vorzunehmen.
Das bedeutet, dass in Verbindung mit dem <strong>C</strong>-Flag
mehr als nur ein Muster vor der Ersetzung angewendet werden kann.</p>
<p>Es ist sogar möglich, URLs in der Ersetzungszeichenfolge zu
erzeugen, die einen Abfrageteil enthalten. Ein Fragezeichen in der
Ersetzungszeichenfolge zeigt an, dass das, was folgt, in den
QUERY_STRING eingefügt werden soll. Soll eine vorhandene
Abfragezeichenfolge entfernt werden, wird die Ersetzungszeichenfolge
einfach mit einem Fragezeichen beendet.</p>
<note><title>Hinweis</title>
Es gibt eine Besonderheit: Wenn ein Substitutionsfeld den Präfix
<code>http://</code><em>DieserHost</em>[<em>:DieserPort</em>]
erhält, schneidet <strong>mod_rewrite</strong> ihn automatisch ab.
Diese automatische Verkürzung bei impliziten externen Umleitungen ist eine
nützliche und wichtige Möglichkeit, wenn sie in Verbindung mit einer
Mapping-Funktion eingesetzt wird, die den Hostnamen generiert. Beachten Sie
hierzu das erste der weiter unten folgenden Beispiel.
</note>
<note><title>Hinweis</title>
Eine bedingungslose externe Umleitung zum eigenen Server funktioniert mit dem
Präfix <code>http://DieserHost</code> nicht. Eine solche Selbstumleitung
kann
mit dem Flag <strong>R</strong> erreicht werden (siehe unten).
</note>
<p>Weitere spezielle Substitutionsanweisungen können mit</p>
<p class="indent">
<strong><code>[</code><em>Flags</em><code>]</code></strong>
</p>
<p>
als drittem Argument an die <code>RewriteRule</code>-Direktive
angehängt
werden. Mit einer durch Kommata getrennten Liste können folgende
<em>Flags</em> angegeben werden: </p>
<ul>
<li>
'<strong><code>redirect|R</code>
[=<em>Code</em>]</strong>' (verlangt eine Umleitung)<br />
Das Feld <em>Substitution</em> erhält den Präfix
<code>http://DieserHost[:DieserPort]/</code> (was die neue URL zur
URI macht), um eine externe Umleitung zu erzwingen. Wird kein
<em>Code</em> angegeben, wird die HTTP-Antwort <code>302 (MOVED
TEMPORARILY)</code> gesendet. Sollen andere Codes aus dem Bereich
300-400 gesendet werden, wird einfach deren Nummer oder einer der
folgenden symbolischen Namen angegeben:<code>temp</code>
(Standardeinstellung), <code>permanent</code> oder <code>seeother</code>.
Verwenden Sie diese Möglichkeit für permanente URL-Umleitungen, bei
denen
<code>/~</code> in <code>/u/</code> umgewandelt oder immer ein
Schrägstrich an <code>/u/</code><em>user</em> usw. angehängt wird.<br
/>
<p><strong>Achtung:</strong> Wenn dieses Flag verwendet wird, muss das
Substitutionsfeld eine gültige URL entalten. Ist dies nicht der Fall, wird
an eine
unzulässige Position umgeleitet. Ferner ist zu beachten, dass dieses Flag
selbst
die URL nur mit dem Präfix <code>http://DieserHost[:DieserPort]/</code>
versieht, die Manipulation aber fortgesetzt wird. Normalerweise soll abgebrochen
und die Umleitung unmittelbar erfolgen. Damit die URL-Manipulation ebenfalls
abgebrochen wird, muss das Flag <code>L</code> angegeben werden.</p>
</li>
<li>'<strong><code>forbidden|F</code></strong>' (die URL
wird verboten)<br />
Die aktuelle URL wird verboten, <em>d.h.</em> es wird sofort die HTTP-Antwort
<code>403 (FORBIDDEN)</code>gesendet. Dieses Flag kann in Verbindung
mit entsprechenden <code>RewriteCond</code>-Bedingungen URLs
blockieren.</li>
<li>'<strong><code>gone|G</code></strong>' (URL gelöscht)<br />
Die aktuelle URL wird als gelöscht gekennzeichnet, <em>d.h.</em> es wird
sofort
die HTTP-Antwort <code>410 (GONE)</code> gesendet. Mit diesem Flag
werden Seiten gekennzeichnet, die nicht mehr vorhanden sind.</li>
<li>
'<strong><code>proxy|P</code></strong>' (Proxy-Anfrage erzwingen)
<br />
Dieses Flag erzwingt, dass der Substitutionsteil intern zur Proxy-Anfrage wird
und sofort vom <a href="mod_proxy.html">Proxy-Modul</a> verarbeitet
wird (die URL-Manipulation wird an dieser Stelle abgebrochen). Es muss
sichergestellt werden, dass die Substitutionszeichenfolge eine gültige URI
enthält (die normalerweise mit <code>http://</code><em>Hostname</em>
beginnt), die vom Proxy-Modul verarbeitet werden kann. Ist dies nicht der Fall,
kann das Proxy-Modul einen Fehler melden. Dieses Flag ermöglicht eine
leistungsfähigere Implementierung der <a href="mod_proxy.html#proxypass">
ProxyPass</a>-Direktive für das Einblenden von Daten anderer Websrever
in den lokalen Server.
<p>Hinweis: Um diese Funktionalität nutzen zu können, muss das
Proxy-Modul
beim Kompilieren in den Apache-Server mit eingebunden werden. Falls Sie nicht
wissen, ob das der Fall ist, überprüfen Sie, ob
<code>mod_proxy.c</code>
in der Ausgabe von <code>httpd -l</code> erscheint. Trifft dies zu, steht die
Funktionalität für <code>mod_rewrite</code> zur Verfügung.
Andernfalls
müssen Sie das Modul in das Hauptprogramm <code>httpd</code>
einbinden.</p>
</li>
<li>'<strong><code>last|L</code></strong>'
(Letzte Regel)<br />
Stoppt die URL-Manipulation an dieser Stelle, weiteren Regeln werden nicht mehr
angewendet. Dieses Flag entspricht dem Perl-Befehl <code>last</code> oder
dem <code>break</code>-Befehl der Programmiersprache C. Mit diesem Flag kann
verhindert werden, dass die gereade umgeschriebene URL von
nachfolgenden Regeln überschrieben wird. Auf diese Weise kann zum Beispiel
die Root-URL <code>/</code> in die richtige URL <code>/e/www/</code>
umgeschrieben werden.
</li>
<li>'<strong><code>next|N</code></strong>'
(Nächster Durchgang)<br />
Der Manipulationsvorgang wird noch einmal wiederholt (beginnend mit der ersten
Regel). Die zu vergleichende URL ist nicht die ursprüngliche URL sondern
die
nach der letzten Manipulation. Dies entspricht dem Perl-Befehl
<code>next</code> oder dem C-Befehl <code>continue</code>. Mit diesem
Flag wird der Manipulationsprozess erneut gestartet und sofort an den
Ausgangspunkt zurückgekehrt.<br />
<strong>Achten Sie darauf, Endlosschleifen zu vermeiden!</strong>
</li>
<li>'<strong><code>chain|C</code></strong>'
(Verkettung mit der nächsten Regel)<br />
Mit diesem Flag wird die aktuelle mit der folgenden Regel verkettet (die
ihrerseits wieder mit der nächsten Regel verkettet sein kann usw.). Das hat
folgende Auswirkung: Trifft eine Regel zu, wird die Verarbeitung normal
fortgesetzt (das Flag hat keine Auswirkungen). Trifft die Regel
<strong>nicht</strong> zu, werden alle verketteten Regeln ausgelassen. So
kann beispielsweise der <code>.www</code>-Teil aus einem Regelsatz für die
Verzeichnisebene entfernt werden, wenn eine externe Umleitung durchgeführt
wird,
bei der der <code>.www</code>-Teil nicht vorhanden sein sollte.
</li>
<li>
'<strong><code>type|T</code></strong>=<em>MIME-Typ</em>'
(MIME- <strong>T</strong>yp)<br />
Erzwingt den MIME-Typ der Zieldatei. Hiermit kann beispielsweise die
<code>mod_alias</code>-Direktive <code>ScriptAlias</code>
simuliert werden, die intern erzwingt, dass alle Dateien im zugeordneten
Verzeichnis den MIME-Typ <code>application/x-httpd-cgi</code> haben.</li>
<li>
'<strong><code>nosubreq|NS</code></strong>' (Wird nur benutzt,
wenn keine interne Unteranfrage vorliegt)<br />
Dieses Flag veranlasst die Rewriting Engine eine Regel zu überspringen,
wenn
es sich bei der aktuellen Anfrage um eine interne Unteranfrage handelt. Zu
internen Unteranfragen kommt es beim Apache beispielsweise, wenn
<code>mod_include</code> Informationen über mögliche
Standardverzeichnisdateien sucht (<code>index.xxx</code>). Bei Unterabfragen
ist es nicht immer sinnvoll und führt manchmal sogar zu Fehlern, wenn der
vollständige Regelsatz angewendet wird. Mit diesem Flag können
bestimmte Regeln ausgeschlossen werden.<br />
<p>Folgende Regel sollte berücksichtigt werden: Immer wenn URLs
ein CGI-Skripte als Präfix erhalten, damit sie von diesem verarbeitet
werden,
ist die Wahrscheinlichkeit groß, dass es zu Problemen (oder zu Overhead)
bei Unteranfragen kommt. In diesen Fällen sollte dieses Flag benutzt
werden.</p>
</li>
<li>'<strong><code>nocase|NC</code></strong>'
(Keine Unterscheidung von Groß- und Kleinschreibung)<br />
Beim <em>Muster</em> werden Groß- und Kleinschreibung nicht unterschieden,
so dass es beim Vergleich der aktuellen URL mit dem <em>Muster</em>
keinen Unterschied zwischen 'A-Z' und 'a-z' gibt.
</li>
<li>'<strong><code>qsappend|QSA</code></strong>'
(Eine Abfragezeichenfolge anhängen)<br />
Dieses Flag zwingt die Rewriting Engine eine Abfragezeichenfolge an die
in der Substitutionszeichenfolge vorhandene anzuhängen, anstatt sie zu
ersetzen.
Damit können über eine Manipulationsregel der Abfragezeichenfolge
mehr Daten
hinzugefügt werden.</li>
<li>
'<strong><code>noescape|NE</code></strong>'
(Sonderzeichen werden nicht in URL-Escape-Werte umgewandelt)<br />
Dieses Flag verhindert, dass <code>mod_rewrite</code> die üblichen
Umwandlungen nach den URI_Escape-Regeln durchführt. Normalerweise werden
Sonderzeichen wie <code>%</code>, <code>$</code>, <code>,</code> usw. in ihre
hexadezimalen Äquivalente umgewandelt (<code>%25</code>, <code>
524</code> und <code>%3B</code>), was dieses Flag verhindert. Das
ermöglicht, dass Prozentzeichen in der Ausgabe erscheinen können:
<example>
RewriteRule /foo/(.*) /bar?arg=P1\%3d$1 [R,NE]
</example>
<code>/foo/zed</code> wird in eine sicher Anfrage nach
<code>/bar?arg=P1=zed</code> umgewandelt.
</li>
<li>
'<strong><code>passthrough|PT</code></strong>'
(Das Ergebnis wird an ein anderes Modul weitergereicht.)<br />
Dieses Flag veranlasst die Rewriting Engine das <code>uri</code>-Feld der
internen <code>request_rec</code>-Struktur auf den Wert des Feldes
<code>filename</code> zu setzen. Dieses Flag bietet die Möglichkeit
die Ausgabe von <code>RewriteRule</code>-Direktiven von den Direktiven
<code>Alias</code>, <code>ScriptAlias</code>, <code>Redirect</code>
usw. anderer URI-/Dateiname-Umwandlungen nachbearbeiten zu lassen. Das
folgende einfache Beispiel soll die Semantik veranschaulichen. <code>/abc</code>
soll mit Hilfe der Rewriting Engine von <code>mod_rewrite
</code> zu <code>/def</code> und anschließend
<code>/def</code> mit<code>mod_alias</code> in <code>/ghi</code> umgeschrieben
werden:
<example>
RewriteRule ^/abc(.*) /def$1 [PT]<br />
Alias /def /ghi
</example>
Wird das Flag <code>PT</code> weggelassen, überschreibt
<code>mod_rewrite</code> wie erwartet <code>uri=/abc/...</code> mit
<code>Dateiname=/def/...</code>, wie dies bei einer API-konformen
Umwandlung von URI in Dateiname der Fall sein soll. Versucht anschließend
<code>mod_alias</code> eine Umwandlung von URI in einen Dateinamen,
dann funktioniert das nicht mehr.
<p>Hinweis: <strong>Dieses Flag muss verwendet werden, wenn
Direktiven unterschiedlicher Module mit Umwandlungen von URL in Dateinamen
vermischt werden sollen</strong>. Ein typisches Beispiel ist die Verwendung
von <code>mod_alias</code> und <code>mod_rewrite</code>.</p>
</li>
<li>'<strong><code>skip|S</code></strong>=<em>num</em>'
(Nächste Regel(n) auslassen)<br />
Bei Angabe dieses Flag überspringt die Rewriting Engine die nächsten
<em>num</em> Regeln der Sequenz, wenn die aktuelle Regel zutrifft. Das
ermöglicht ein Pseudokonstrukt der <code>if/then/else</code>-Bedingung:
Die letzte Regel der <code>then</code>-Klausel lautet <code>skip=N</code>,
wobei <code>num</code> der Anzahl der Regeln in der
<code>else</code>-Klausel entspricht. (Das ist <strong>nicht</strong> das
Gleiche wie das <code>chain|C</code>-Flag!)</li>
<li>
'<strong><code>env|E=</code></strong><em>VAR</em>:<em>WERT</em>'
(Setzt eine Umgebungsvariable)<br />
Die Umgebungsvariable <em>VAR</em> wird auf einen <em>WERT</em>
gesetzt, wobei der <em>WERT</em> die Rückverweise <code>$N</code>
und <code>%N</code> enthalten kann, die expandiert werden. Dieses Flag
kann mehrmals verwendet werden, um mehrere Variablen zu setzen. Die
Variablen können später in vielen Situationen dereferenziert werden,
was aber
normalerweise in XSSI (über <code><!--#echo var="VAR"--></code>)
oder CGI (<code>$ENV{'VAR'}</code>) geschieht. Ferner kann die
Dereferenzierung in einem folgenden <code>RewriteCond</code>-Muster
mit <code>%{ENV:VAR}</code> erfolgen. Auf diese Weise werden Informationen aus
URLs gestrichen, ohne sie zu löschen.</li>
<li>
'<strong><code>cookie|CO=</code></strong><em>NAME</em>:<em>WERT</em>:<em>Domäne</em>[:<em>Lebensdauer</em>[:<em>Pfad</em>]]'
(Setzt ein Cookie)<br />
Mit diesem Flag wird ein Cookie für den Client-Browser gesetzt.
<em>NAME</em> gibt den Cookie-Namen und <em>WERT</em> seinen
Wert an. Das Feld <em>Domäne</em> gibt die Domäne des Cookie an, zum
Beispiel <code>apache.org</code>. Optional kann die <em>Lebennsdauer</em>
des Cookie in Minuten und der <em>Pfad</em> angegeben werden.</li>
</ul>
<note><title>Hinweis</title> Beachten Sie, dass das <em>Muster</em> in
einer Serverkonfigurationsdatei für die vollständige URL angewendet
wird.
<strong>In einer Verzeichnis-Konfigurationsdateien wird der
Verzeichnispräfix
für das übereinstimmende Muster (der für ein bestimmtes
Verzeichnis immer
der gleiche ist!) automatisch <em>entfernt</em> und nach der Substitution
automatisch <em>hinzugefügt</em>.</strong> Diese Möglichkeit ist
für viele
Formen der Ersetzung unerlässlich, denn ohne diese Präfixentfernung
müsste
das übergeordnete Verzeichnis verglichen werden, was nicht immer
möglich ist.
<p>Eine Ausnahme muss beachtet werden: Wenn eine Substitutionszeichenfolge
mit <code>http://</code> beginnt, wird der Verzeichnispräfix
<strong>nicht</strong> hinzugefügt sondern eine externe Umleitung oder eine
Proxy-Anfrage erzwungen (wenn das Flag <strong>P</strong> benutzt
wird)!</p>
</note>
<note><title>Hinweis</title>
Um die Rewriting Enginefür Verzeichnis-Konfigurationsdateien zu
aktivieren,
muss <code>RewriteEngine</code> in diesen Dateien auf
<code>On</code> gesetzt <strong>und</strong> <code>Options
FollowSymLinks</code> aktiviert werden. Hat der Administrator das
Überschreiben von <code>FollowSymLinks</code> für ein
Benutzerverzeichnis
deaktiviert, dann kann die Rewriting Engine nicht benutzt werden. Diese
Einschränkung ist aus Sicherheitsgründen erforderlich.
</note>
<p>Im folgenden werden alle möglichen Substitutionskombinationen und
ihre Bedeutungen aufgeführt:</p>
<p><strong>Innerhalb der Serverkonfiguration
(<code>httpd.conf</code>)<br />
für die Anfrage <code>GET /EinPfad/Pfadinfo</code>':</strong><br />
</p>
<note><pre>
<strong>Regel</strong> <strong>Ersetzung</strong>
----------------------------------------------
----------------------------------
^/EinPfad(.*) AndererPfad$1 nicht unterstützt, da
ungültig!
^/EinPfad(.*) AndererPfad$1 [R] nicht unterstützt, da
ungültig!
^/EinPfad(.*) AndererPfad$1 [P] nicht unterstützt, da
ungültig!
----------------------------------------------
----------------------------------
^/EinPfad(.*) /AndererPfad$1 /AndererPfad/Pfadinfo
^/EinPfad(.*) /AndererPfad$1 [R]
http://DieserHost/AndererPfad/Pfadinfo
über externe Umleitung
^/EinPfad(.*) /AndererPfad$1 [P] nicht unterstützt, da
unsinnig!
----------------------------------------------
----------------------------------
^/EinPfad(.*) http://DieserHost/AndererPfad$1 /AndererPfad/Pfadinfo
^/EinPfad(.*) http://DieserHost/AndererPfad$1 [R]
http://DieserHost/AndererPfad/Pfadinfo
über externe Umleitung
^/EinPfad(.*) http://DieserHost/AndererPfad$1 [P] nicht unterstützt, da
unsinnig!
----------------------------------------------
----------------------------------
^/EinPfad(.*) http://AndererHost/AndererPfad$1
http://AndererHost/AndererPfad/Pfadinfo
über externe Umleitung
^/EinPfad(.*) http://AndererHost/AndererPfad$1 [R]
http://AndererHost/AndererPfad/Pfadinfo
über externe Umleitung
(das [R]-Flag ist redundant)
^/EinPfad(.*) http://AndererHost/AndererPfad$1 [P]
http://AndererHost/AndererPfad/Pfadinfo
über internen Proxy
</pre></note>
<p><strong>In der Verzeichniskonfiguration
<code>/EinPfad</code><br />
(<em>d.h.</em>, die Datei <code>.htaccess</code> in
<code>/physischer/Pfad/zu/EinPfad</code> mit
<code>RewriteBase /EinPfad</code>)<br />
für <code>GET
/EinPfad/LokalerPfad/Pfadinfo</code>':</strong><br />
</p>
<note><pre>
<strong>Regel</strong>
<strong>Ersetzung</strong>
----------------------------------------------
----------------------------------
^LokalerPfad(.*) AndererPfad$1
/EinPfad/AndererPfad/Pfadinfo
^LokalerPfad(.*) AndererPfad$1 [R]
http://DieserHost/EinPfad/AndererPfad/Pfadinfo
über externe Umleitung
^LokalerPfad(.*) AndererPfad$1 [P] nicht unterstützt, da
unsinnig!
----------------------------------------------
----------------------------------
^LokalerPfad(.*) /AndererPfad$1 /AndererPfad/Pfadinfo
^LokalerPfad(.*) /AndererPfad$1 [R]
http://DieserHost/AndererPfad/Pfadinfo
über externe Umleitung
^LokalerPfad(.*) /AndererPfad$1 [P] nicht unterstützt, da
unsinnig!
----------------------------------------------
----------------------------------
^LokalerPfad(.*) http://DieserHost/AndererPfad$1 /AndererPfad/Pfadinfo
^LokalerPfad(.*) http://DieserHost/AndererPfad$1 [R]
http://DieserHost/AndererPfad/Pfadinfo
über externe Umleitung
^LokalerPfad(.*) http://DieserHost/AndererPfad$1 [P] nicht unterstützt,
da unsinnig!
----------------------------------------------
----------------------------------
^LokalerPfad(.*) http://AndererHost/AndererPfad$1
http://AndererHost/AndererPfad/Pfadinfo
über externe Umleitung
^LokalerPfad(.*) http://AndererHost/AndererPfad$1 [R]
http://AndererHost/AndererPfad/Pfadinfo
über externe Umleitung
(the [R] flag is redundant)
^LokalerPfad(.*) http://AndererHost/AndererPfad$1 [P]
http://AndererHost/AndererPfad/Pfadinfo
über internen Proxy
</pre></note>
<p><strong>Beispiel:</strong></p>
<p>URLs der Form </p>
<p class="indent">
<code>/</code> <em>Language</em> <code>/~</code>
<em>Realname</em> <code>/.../</code> <em>File</em>
</p>
<p>sollen wie folgt umgeschrieben werden:</p>
<p class="indent">
<code>/u/</code> <em>Username</em> <code>/.../</code>
<em>File</em> <code>.</code> <em>Language</em>
</p>
<p>Die obige Rewrite-Map-Datei wird unter
<code>/Pfad/zu/Datei/map.txt</code> gespeichert. Der
Serverkonfiguration müssen lediglich folgende Zeilen
hinzugefügt werden:</p>
<example>
<pre>
RewriteLog /Pfad/zu/Datei/rewrite.log
RewriteMap real-to-user txt:/Pfad/zu/Datei/map.txt
RewriteRule ^/([^/]+)/~([^/]+)/(.*)$ /u/${real-to-user:$2|nobody}/$3.$1
</pre>
</example>
</usage>
</directivesynopsis>
</modulesynopsis>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
