Zum Inhalt springen

Apache2.4/08/1 Aliase und Weiterleitungen

Aus Foxwiki

1 Aliase und Weiterleitungen

Beschreibung

Für eine Website ist es oft wichtig, die mit einer Anfrage gesendete URL zu manipulieren. Es gibt grundsätzlich zwei verschiedene Verfahren dafür:

  • Alias Die URL-Änderung findet automatisch hinter den Kulissen statt, ohne dass der Client davon unterrichtet wird. Dies ist beispielsweise nützlich, um Dateien und Verzeichnisse, die sich aus Sicherheits- oder Organisationsgründen außerhalb der DocumentRoot befinden, einer URL zuzuordnen.
  • Weiterleitung (Redirect)

Der Client erhält eine Nachricht mit einem 3xx-Statuscode. In einem Location-Header wird die neue URL des Dokuments mitgeteilt. Dieses Verfahren sollten Sie z. B. immer dann wählen, wenn eine Datei sich nicht mehr an ihrem früheren Ort befindet.

Apache implementiert beide Methoden durch zwei unterschiedliche Module: den Klassiker mod_alias und das modernere, auf einer leistungsfähigen RegExp-Engine basierende Modul mod_rewrite. Beide werden in diesem Abschnitt vorgestellt. Einen Sonderfall von Aliasen haben Sie bereits in Kapitel 6, »Grundkonfiguration«, kennengelernt: das Einbinden der Benutzerverzeichnisse durch mod_userdir.

8.1.1 mod_alias

Dieses Modul enthält eine Reihe von Direktiven für die namensgebenden Aliase, aber auch für die Weiterleitung: Alias und AliasMatch dienen der URL-Änderung hinter den Kulissen, während die diversen Redirect*-Direktiven für Weiterleitungen zuständig sind.

Alias Verzeichnis im Dateisystem einer URL zuordnen

Modul mod_alias

Kontext Server, <VirtualHost> Syntax Alias URL-Pfad Dateipfad|Verzeichnispfad Standardwert nicht gesetzt

Die Direktive Alias ordnet eine Datei oder ein Verzeichnis, das außerhalb der DocumentRoot liegt, einer URL zu. Das erste Argument ist die gewünschte URL (genauer gesagt der URL-Pfad), das zweite ist der Pfad der Datei oder des Verzeichnisses im lokalen Dateisystem. Beispiel: 

Alias /extern /usr/local/mydocs

Fordert ein User nach der Definition dieses Aliases die URL photo.jpg an, dann wird die Datei /usr/local/mydocs/ photo.jpg geliefert.

Wenn der URL-Pfad mit einem Slash endet, muss dies auch für den Verzeichnispfad gelten. Beispiel: 

Alias /images/ /usr/local/mydocs/images/

In diesem Fall wird allerdings eine Anfrage nach www.mynet.de/images (ohne abschließenden Slash) nicht, wie sonst üblich, durch eine automatische Weiterleitung auf die echte Verzeichnis-URL www.mynet.de/images/ beantwortet, sondern mit 404 Not Found.

Wenn Sie die in Kapitel Grundkonfiguration, beschriebene restriktive Voreinstellung für das Wurzelverzeichnis vorgenommen haben, müssen Sie das Ziel des Aliases explizit freischalten – die Einstellungen für die DocumentRoot gelten in diesem Fall nicht. Hier ein Beispiel: 

Alias /test/ /usr/local/mydocs/test/
<Directory /usr/local/mydocs/test>
Options Indexes FollowSymLinks AllowOverride All Order allow,deny Allow from all
</Directory>

AliasMatch RegExp-Verzeichnismuster einem URL-Muster zuordnen
Modul mod_alias

Kontext Server, <VirtualHost> Syntax AliasMatch RegExp Dateipfad|Verzeichnispfad Standardwert nicht gesetzt

AliasMatch

funktioniert im Prinzip genau wie Alias. Der Unterschied besteht darin, dass als URL-Pfad ein regulärer Ausdruck verwendet wird. Geklammerte Teilausdrücke können im Datei- oder Verzeichnispfad durch $1 bis $9 wiedergegeben werden. Das folgende Beispiel bildet das Verzeichnis /usr/local/ mydocs/ images/ auf die URI /images ab: 

AliasMatch ^/images/(.*) /usr/local/mydocs/images/$1

Dieses Beispiel nutzt die Fähigkeiten von AliasMatch aus und ordnet die Verzeichnisse /usr/local/mydocs/text0 bis /usr/local/mydocs/text9 den URIs / text0 bis /text9 zu: 

AliasMatch ^/text([0-9])/(.*) /usr/local/mydocs/text$1/$2

Die Optionen der mittels AliasMatch eingebundenen Verzeichnisse lassen sich mithilfe von <DirectoryMatch>- oder <LocationMatch>-Containern festlegen.

Hinweis

Beachten Sie bitte, dass zwei weitere Alias-Direktiven nicht hier, sondern in Kapitel 14, »CGI«, behandelt werden: ScriptAlias und ScriptAliasMatch. Sie funktionieren im Prinzip genau wie die Konfigurationsanweisungen Alias beziehungsweise AliasMatch, mit dem Unterschied, dass zusätzlich alle Dateien in den eingebundenen Verzeichnissen als CGI-Skripte betrachtet werden.

Redirect

Sendet dem Client eine Umleitungsmitteilung

Modul mod_alias

Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files>, .htaccess (FileInfo) Syntax Redirect [Status] URL-Pfad URL Standardwert nicht gesetzt

Redirect

ändert die angeforderte URL nicht serverseitig, sondern sendet dem Client eine Mitteilung über den geänderten Aufenthaltsort der angeforderten Ressource. Pflichtangaben sind der URL-Pfad, der in der Anfrage gefunden werden soll, und die URL, zu der die Umleitung erfolgen soll. Diese URL muss absolut sein, das heißt, sie muss mit http:// und einem Hostnamen beginnen. Sie können daher nicht nur Weiterleitungen innerhalb Ihrer eigenen Site, sondern auch auf andere Websites durchführen.

Das folgende Beispiel leitet Anfragen für Dateien und Unterverzeichnisse unter /test an die URL http://www.mynet.de/woanders weiter: 

Redirect /test http://www.mynet.de/woanders

Das bedeutet, dass alles, was in der angeforderten URL hinter /test stand, an http://www.mynet.de/woanders angehängt wird. Eine Anforderung des Bildes /test/logo.gif würde mit folgender Weiterleitung auf http://www. mynet.de/woanders/logo.gif beantwortet: 

 HTTP/1.1 302 Found Date: Tue, 26 Aug 2008 11:31:03 GMT Server: Apache/2.2.9 (Unix)
 Location: http://www.mynet.de/woanders/logo.gif Content-Length: 221
 Content-Type: text/html; charset=iso-8859-1
 
 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
 <html><head>
 <title>302 Found</title>
 </head><body>
 <h1>Found</h1>
 <p>The document has moved <a href="http://www.mynet.de/woanders/
 logo.gif">here</a>.</p>
 </body></html>

Der wichtigste Teil der Antwort ist der Location-Header, der dem Client den geänderten Aufenthaltsort der angeforderten Ressource mitteilt. Für Clients, die nicht in der Lage sind, Weiterleitungen automatisch zu folgen, enthält der Body zusätzlich einen entsprechenden Hyperlink.

Ein optionales Argument für Redirect ist der HTTP-Statuscode, mit dem die Weiterleitungsmitteilung an den Client versendet wird. Für die folgenden vier Statuscodes existiert eine spezielle Bezeichnung:

  • permanent

Die Mitteilung wird als dauerhafte Weiterleitung mit dem Statuscode 301 Moved Permanently versendet. Das folgende Beispiel leitet Anfragen für /old dauerhaft nach http://www.newaddress.org/new um: 

Redirect permanent /old http://www.newaddress.org/new

Dies ist z. B. nützlich, wenn sich Ihr Haupt-Domain-Name aus irgendeinem Grund geändert haben sollte. Angenommen, Sie haben Ihr Studium beendet und ziehen mit Ihrer Website von www.uni-abc.de/~meinname auf die neu reservierte Domain www.meinname.de um. In einer .htaccess-Datei in Ihrem Webverzeichnis könnten Sie die folgende Umleitung unterbringen: 

Redirect permanent /~meinname http://www.meinname.de

Wie Sie sehen, muss der umzuleitende URL-Pfad auch dann mit einem / beginnen und den Beginn der URL bis zum aktuellen Verzeichnis wiedergeben, wenn die Direktive in einer .htaccess-Datei oder in einem Container-Kontext steht.

  • temp Wie Sie am ersten Beispiel weiter oben sehen konnten, ist dies der Standardwert; Sie können ihn auch weglassen. Er erzeugt eine vorübergehende Weiterleitung – aus Kompatibilitätsgründen mit dem älteren Statuscode 302 Found, nicht mit 307 Temporary Redirect.
  • seeother Die Meldung erhält den Statuscode 303 See Other.
  • gone Dies erzeugt den Status 410 Gone, der anzeigt, dass die angeforderte Ressource nicht mehr existiert. Für diesen Statuscode ergibt eine URL keinen Sinn; deshalb darf sie auch nicht angegeben werden.

Andere Statuscodes als diese vier können Sie numerisch angeben. Beachten Sie, dass alle 3xx-Codes eine Umleitungs-URL für den Location-Header benötigen. Alle anderen Fehlercodes erhalten dagegen keine URL. Das folgende Beispiel sendet für alle URIs unter /nichtda mutwillig ein 404 Not Found: 

Redirect 404 /nichtda
Vorsicht Falle!

Bei Redirect können Sie in die hier beschriebene Falle tappen:

Eine Weiterleitung in ein Unterverzeichnis des aktuellen Verzeichnisses funktioniert nicht ohne Weiteres. Schauen Sie sich die folgende Redirect-Anweisung an, die zunächst völlig harmlos aussieht: 

Redirect /info http://www.mynet.de/info/neu

Nehmen Sie zur Verdeutlichung an, der Server erhält eine Anfrage mit der URL www.mynet.de/info/muster.gif. Laut Redirect-Direktive sollen alle URIs, die mit /info beginnen, auf http://www.mynet.de/info/neu weitergeleitet werden. Die Weiterleitung erzeugt also eine neue Anfrage mit folgender Adresse: muster.gif. Da der Redirect-Befehl jedoch auch auf diese Anfrage zutrifft, wird erneut eine Weiterleitungsmitteilung gesendet – diesmal mit der URL muster.gif! Das geht so lange weiter, bis der Client oder der Server aufgibt oder bis die maximale URL-Länge erreicht ist. Wenn Sie diese Art der Weiterleitung tatsächlich benötigen, funktioniert sie entweder über einen Alias – der eben keine neue Anfrage erzeugt – oder aber mithilfe der komplexen Regeln von mod_rewrite.

RedirectMatch

Sendet dem Client eine Umleitungsmitteilung, wenn die URL einem RegExp entspricht

Modul mod_alias

Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files>, .htaccess (FileInfo) Syntax RedirectMatch [Status] RegExp URL Standardwert nicht gesetzt

RedirectMatch funktioniert genau wie Redirect. Allerdings können Sie als URLPfad einen regulären Ausdruck verwenden. Das folgende Beispiel leitet Anfragen nach URIs unter den Verzeichnissen /images00 bis /images99 permanent an die Verzeichnisse /00 bis /99 auf dem Host bilder.mynet.de weiter: 

RedirectMatch permanent ^/images([0-9]{2})/(.*) \
http://bilder.mynet.de/$1/$2

Die Anfrage nach www.mynet.de/images5/photo7.jpg wird also beispielsweise mit einer Weiterleitung auf bilder.mynet.de/5/photo7.jpg beantwortet.

Anders als bei einem einfachen Redirect kann das Weiterleitungsziel von RedirectMatch auch etwas anderes sein als ein geändertes Präfix mit demselben Pfad. Das liegt daran, dass dieser Pfad bei RedirectMatch nicht automatisch angehängt wird. Deshalb könnten Sie beispielsweise alle Anfragen, die mit einem bestimmten URL-Pfad beginnen, auf eine einzige Datei umleiten. Beispiel: 

RedirectMatch temp ^/news http://www.mynet.de/newsinfo.html

Diese Zeile könnten Sie z. B. einsetzen, falls sich der gesamte Inhalt des Unterverzeichnisses /news gerade in einer Überarbeitung befinden sollte. Für jede Anfrage, deren URI mit /news beginnt, würde daraufhin die Datei /newsinfo.html angezeigt.

Hier noch ein Beispiel, das auf den ersten Blick etwas seltsam erscheint: 

RedirectMatch ^/search/(.*) http://www.google.de/search?q=$1

Wie Sie sehen, werden sämtliche Anfragen, deren URL-Pfad mit /search/ beginnt, an die Suchmaschine Google weitergeleitet, genauer gesagt als Wert des QueryFeldes q für die URI /search – dies ist der Suchbegriff. Mit anderen Worten: Google sucht nach dem Begriff, den Sie an www.mynet.de/search/ angehängt haben. Das Prinzip ist also nicht weiter kompliziert.

Die weitaus interessantere Frage ist, wozu man so etwas überhaupt benötigt. Es könnte Sie beispielsweise ärgern, dass es keine Spuren in Ihren Log-Dateien (siehe auch Logging) hinterlässt, wenn ein User einen externen Hyperlink anklickt. Besonders bedauerlich ist das, wenn Sie so etwas wie einen Amazon-Partner-Shop betreiben – Sie wissen nie, ob sich jemand für Ihre Angebote interessiert. Dies können Sie auf eine ähnliche Weise ändern. Zunächst einmal benötigen Sie eine RedirectMatch-Direktive wie diese: 

RedirectMatch ^/elsewhere/(.*) http://$1

Anschließend müssen Sie die URLs der externen Hyperlinks in Ihren HTMLDokumenten, für die Sie Log-Einträge benötigen, nach folgendem Schema ändern: Aus http://andere-site.com/pfad/usw wird /elsewhere/anderesite.com/pfad/usw.

Ein Amazon.de-Partner-Link auf das vorliegende Buch hat beispielsweise folgende Original-URL: 

http://www.amazon.de/dp/3836213257/my-partner-id

Wenn die genannte Direktive in Kraft ist, müssen Sie sie in HTML-Dateien durch folgende Link-URL ersetzen: 

/elsewhere/www.amazon.de/dp/3836213257/my-partner-id

Sobald jemand den entsprechenden Link anklickt, enthält Ihre AccessLog-Datei einen Eintrag wie diesen: 

217.63.82.109 – - [29/Aug/2008:13:11:07 +0100] "GET /elsewhere/ www.amazon.de/dp/3836213257/my-partner-id HTTP/1.1" 302 249 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0; .NET CLR1.0.3705)"

In Logging werden einige nützliche Perl-Skripte und Hilfsprogramme vorgestellt, mit denen sich Log-Dateien nach solchen Informationen filtern lassen. Beachten Sie die 302 in der Log-Zeile – sie weist darauf hin, dass der Browser des Besuchers keine lokale Datei erhalten hat, sondern eine Weiterleitungsmitteilung (302 Found).

RedirectPermanent

Sendet dem Client eine Mitteilung über eine permanente Umleitung

Modul mod_alias

Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files>, .htaccess (FileInfo) Syntax RedirectPermanent URL-Pfad URL Standardwert nicht gesetzt

Dies ist lediglich eine spezielle Schreibweise für Redirect permanent, die aus Kompatibilitätsgründen beibehalten wurde.

RedirectTemp

Sendet dem Client eine Mitteilung über eine vorübergehende Umleitung

Modul mod_alias

Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files>, .htaccess (FileInfo) Syntax RedirectTemp URL-Pfad URL Standardwert nicht gesetzt

Diese Direktive ist nichts weiter als eine veraltete Alternative zu Redirect temp.

8.1.2 mod_rewrite

Wie Sie gesehen haben, ist mod_alias zwar nützlich, stößt aber in puncto Flexibilität relativ schnell an seine Grenzen. Hier hat das Modul mod_rewrite erheblich mehr zu bieten. Es wurde 1996 von Ralf S. Engelschall geschrieben und gehört seit 1997 zur Apache-Distribution. In der Apache-Dokumentation wird es zu Recht als »Swiss Army-Knife of URL manipulation« bezeichnet. Es kann die volle Funktionalität von mod_alias übernehmen, bietet aber noch unzählige weitere Optionen.

Der Kern des Moduls ist eine leistungsfähige Engine für mit Perl kompatible reguläre Ausdrücke.1 Technisch gesehen werden die Funktionen des Moduls an zwei Stellen während der Verarbeitung einer Anfrage aufgerufen: Rewrite-Direktiven, die in der Hauptkonfigurationsdatei stehen, werden während der Umwandlung der angeforderten URL in einen Dateipfad ausgeführt. Stehen dagegen Rewrite-Anweisungen in .htaccess-Dateien, werden diese erst in der sogenannten Fixup-Phase befolgt: Da .htaccess-Dateien unterhalb der DocumentRoot liegen, können sie erst nach der eigentlichen URL-Umwandlung gelesen werden. Da es an dieser Stelle also eigentlich bereits zu spät für URL-Modifikationen ist, erzeugt eine hier befindliche Rewrite-Regel intern eine Art neue Anfrage.

In diesem Abschnitt werden nun zunächst die Direktiven von mod_rewrite beschrieben. Anschließend werden einige ausführliche Beispiele behandelt. Beides ist lediglich eine Einführung, denn: »Despite the tons of examples and docs, mod_rewrite is voodoo. Damned cool voodoo, but still voodoo.« (Brian Moore; zitiert in der mod_rewrite-Dokumentation).

Um erfolgreich mit mod_rewrite arbeiten zu können, benötigen Sie Kenntnisse über reguläre Ausdrücke. Eine Übersicht über die wichtigsten Konstrukte finden Sie in Anhang G. Eine sehr ausführliche Anleitung bietet [FRIED2007]. Relativ gründlich können Sie sich auch von der POD-Dokumentation der Sprache Perl informieren lassen, wenn diese auf Ihrem System installiert ist. Geben Sie dazu auf der Konsole Folgendes ein: 

$ perldoc perlre
RewriteEngine

Rewrite-Funktionalität ein-/ausschalten

Seit Version 1.3

Modul mod_rewrite

Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files>, .htaccess (FileInfo) Syntax RewriteEngine on|off Standardwert off

Bevor Sie die Funktionalität von mod_rewrite nutzen können, müssen Sie sie mithilfe dieser Direktive einschalten:

1 Beachten Sie, dass die Bibliothek PCRE (Perl-Compatible Regular Expressions), die nicht nur in Apache, sondern in vielen verschiedenen Programmen und Sprachen eingesetzt wird, nicht ganz denselben Leistungsumfang besitzt wie das Pattern Matching in Perl selbst.

RewriteEngine On

Anders als zahlreiche andere Konfigurationseinstellungen wird diese Aktivierung von RewriteEngine nicht an Subkontexte vererbt: Wenn Sie die RewriteEngine beispielsweise im Server-Kontext einschalten, gilt dies nicht für <VirtualHost>-, <Directory>- oder sonstige Container. Die Funktion muss deshalb in jedem gewünschten Kontext explizit aktiviert werden. Insofern hat das ausdrückliche Ausschalten mittels RewriteEngine Off in der Praxis keine besonders große Bedeutung.

RewriteRule Definiert Rewrite-Regeln

Seit Version 1.3; cookie-Flag seit 2.0.40 Modul mod_rewrite Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files>, .htaccess (FileInfo) Syntax RewriteRule [!]RegExp Ersatztext [Flag, ...] Standardwert nicht gesetzt

Dies ist die wichtigste Direktive von mod_rewrite. Sie kann unabhängig von anderen Direktiven dieses Moduls aufgerufen werden und funktioniert dann ähnlich wie AliasMatch oder RedirectMatch. Standardmäßig werden allerdings alle untereinanderstehenden RewriteRule-Anweisungen nacheinander ausgeführt. Dabei wird die URL unter Umständen mehrfach umgeschrieben.

Das erste Argument ist ein beliebiger Perl-kompatibler regulärer Ausdruck. Die Rewrite-Regel wird angewendet, wenn das angegebene Muster im URL-Pfad der Client-Anfrage gefunden wird. Optional können Sie dem regulären Ausdruck ein Ausrufezeichen voranstellen. In diesem Fall wird die RewriteRule nur beachtet, wenn er nicht zutrifft.

Der Ersatztext ist ein beliebiger String. Darin können Sie eine Reihe besonderer Elemente verwenden:

  • $1 bis $9: Diese Platzhalter entsprechen den im regulären Ausdruck gefundenen Teilausdrücken, die Sie in Klammern setzen. Die Nummerierung erfolgt von links nach rechts, bei verschachtelten Klammern von außen nach innen.
  • %1 bis %9: Mithilfe dieser Platzhalter können Sie Bezug auf geklammerte Ausdrücke aus RewriteCond-Direktiven nehmen.
  • %{VAR}: Dies ermöglicht das Einbinden der angegebenen Server-Variablen. An dieser Stelle sind die folgenden Variablen zulässig:
  • Einige HTTP-Anfrage-Header. Ihr Name wird komplett in Großbuchstaben gesetzt; Bindestriche werden durch Unterstriche ersetzt. Die zulässigen Header sind HTTP_USER_AGENT, HTTP_REFERER, HTTP_COOKIE, HTTP_

FORWARDED, HTTP_HOST, HTTP_PROXY_CONNECTION und HTTP_ACCEPT (ihre Bedeutung können Sie in Kapitel 2, »Funktionsweise von Webservern«, nachlesen).

  • Informationen über Anfrage und Verbindung: REMOTE_ADDR, REMOTE_HOST, REMOTE_USER, REMOTE_IDENT, REQUEST_METHOD, SCRIPT_FILENAME, PATH_

INFO, QUERY_STRING und AUTH_TYPE. Näheres über die meisten dieser Variablen steht in Kapitel 14, »CGI«.

  • Informationen über den Server selbst: DOCUMENT_ROOT, SERVER_ADMIN, SERVER_NAME, SERVER_ADDR, SERVER_PORT, SERVER_PROTOCOL und SERVER_

SOFTWARE. Viele dieser Variablen dürften Ihnen bekannt vorkommen, weil es ähnlich lautende Konfigurationsdirektiven gibt (siehe Kapitel 6, »Grundkonfiguration«). Ansonsten werden auch diese Variablen in Kapitel 14, »CGI«, erläutert.

  • Datum und Uhrzeit: TIME_YEAR, TIME_MON, TIME_DAY, TIME_HOUR, TIME_MIN, TIME_SEC, TIME_WDAY und TIME. Die Namen dieser Variablen dürften selbsterklärend sein.
  • API_VERSION: Diese Nummer entspricht der in Kapitel 5, »Apache in Betrieb nehmen«, angesprochenen Module Magic Number; sie gibt unter anderem Auskunft darüber, welche Versionen kompilierter DSO-Module mit der aktuellen Server-Version kompatibel sind. Beispielwert:

20051115:15 (Apache 2.2.9).

  • THE_REQUEST: Dies ist die vollständige Startzeile der HTTP-Client-Anfrage.

Beispiel: GET /dir/file HTTP/1.1

  • REQUEST_URI: die angeforderte Ressource
  • REQUEST_FILENAME: der lokale Pfad- und Dateiname der angeforderten Ressource
  • IS_SUBREQ: Diese Variable besitzt den Wert true, wenn es sich bei der aktuellen HTTP-Anfrage nicht um eine Client-Anfrage, sondern um eine interne Unteranfrage handelt.

Abgesehen davon gibt es noch einige Sonderformen:

  • %{ENV:Variable} liefert die angegebene Umgebungsvariable. Variablen ohne das Präfix ENV sind keine Umgebungsvariablen, sondern spezielle mod_rewrite-Server-Variablen – selbst dann, wenn sie denselben Namen tragen (und in aller Regel natürlich denselben Wert liefern).
  • %{HTTP:Header} liefert den Wert des angegebenen HTTP-Anfrage-Headers

– beispielsweise erhalten Sie über %{HTTP:User-Agent} den Namen des anfragenden Client-Programms. Hier stehen auch Header zur Verfügung, für die nicht eine Standardform wie %{HTTP_REFERER} definiert ist.

  • %{LA-U:Variable} führt eine URL-basierte interne Unteranfrage durch, um den Wert der angegebenen Variablen zu ermitteln. Dieser Mechanismus wird für einige Variablen benötigt, deren Wert erst nach der URLUmwandlung (die Phase, während der mod_rewrite im Server-Kontext arbeitet) feststeht. Ein gutes Beispiel ist der Benutzername des entfernten Benutzers, %{LA-U:Remote-User} – Authentifizierungsinformationen stehen erst später in der Anfrageverarbeitung zur Verfügung.2
  • %{LA-F:Variable} ist eine dateinamenbasierte Unterabfrage. In der Regel besteht kein Unterschied zur URL-basierten Form %{LA-U:Variable}.
  • ${Map-Name:Schlüssel[|Standardwert]}: Mithilfe von RewriteMap können Sie eine externe Datei definieren, in der sich Schlüssel-Wert-Paare befinden.

Diese Formulierung ermöglicht es Ihnen, auf die durch Map-Name bezeichnete RewriteMap zuzugreifen und daraus den Wert auszulesen, der für Schlüssel definiert ist. Optional können Sie einen Standardwert angeben, der verwendet wird, wenn der Schlüssel in der Map nicht gefunden wird.

Als drittes Argument können optional zahlreiche Flags angegeben werden. Diese werden durch Kommas voneinander getrennt und stehen in eckigen Klammern. Folgende Flags sind definiert:

  • redirect|R[=Statuscode]: Normalerweise sorgt RewriteRule für eine einfache interne URI-Änderung. Wenn Sie eine Weiterleitung durchführen möchten, müssen Sie die Ersatz-URL mit http:// beginnen. Mithilfe dieses Flags können Sie zusätzlich einen bestimmten Statuscode setzen: temp (302 Found –

Standard), permanent (301 Moved Permanently), seeother (303 See Other) beziehungsweise einen numerischen Wert aus dem 3xx- oder 4xx-Bereich.

  • forbidden|F: Dies setzt den Statuscode 403 Forbidden: Wenn der Mustervergleich zutrifft, wird dem Client der Zugriff auf die angeforderte Ressource ausdrücklich verboten.
  • gone|G: Durch den Statuscode 410 Gone wird dem Client mitgeteilt, dass die angeforderte Ressource dauerhaft entfernt worden ist.
  • proxy|P: Dieses Flag beendet das Rewriting – nachfolgende RewriteRuleAnweisungen werden nicht mehr beachtet. Die Ziel-URL wird an mod_proxy

2 Das ist nicht der Fall, wenn Sie RewriteRule in einem Verzeichniskontext einsetzen – hier können Sie einfach %{REMOTE_USER} verwenden.

weitergereicht und erzeugt eine Proxy-Anfrage. Beachten Sie, dass der Ersatztext eine vollständige URL sein muss, die mit http:// beginnt.

  • last|L: Mit diesem Flag können Sie dafür sorgen, dass das Rewriting sofort beendet wird; weitere RewriteRules werden nicht mehr beachtet.
  • END (seit Version 2.3): Wirkt wie L, verhindert aber zusätzlich die Ausführung eventueller RewriteRules in .htaccess-Dateien.
  • next|N: Dies sorgt dafür, dass das komplette Rewriting erneut durchgeführt wird, beginnend bei der ersten RewriteRule in der Reihe. Dies ist beispielsweise für das mehrfache Suchen und Ersetzen eines Musters nützlich. Die Bedingung beziehungsweise das Suchmuster muss allerdings so beschaffen sein, dass irgendwann ein Abbruch stattfindet – andernfalls kommt es zu einer Endlosschleife. Ein [L]-Flag in einer weiter oben stehenden Regel kann das Problem natürlich ebenfalls lösen.
  • chain|C: Dieses Flag ermöglicht eine Art logisches Und mit Short-Circuit-Verfahren: Die nächste RewriteRule wird nur dann überhaupt geprüft, wenn die aktuelle zutrifft. Andernfalls werden alle mittels [C]-Flags verketteten Regeln übersprungen.
  • type|T=MIME-Type: Dies sorgt dafür, dass der Zieldatei der angegebene MIMEType für den Content-Type-Header zugewiesen wird.
  • nosubreq|NS: Die Regel soll nur angewendet werden, wenn die aktuell verarbeitete Anfrage eine echte Client-Abfrage und keine interne Unterabfrage ist.
  • nocase|NC: Beim Suchmuster wird nicht zwischen Groß- und Kleinschreibung unterschieden.
  • qsappend|QSA: Wenn der Ersatztext ein Fragezeichen enthält und auf diese Weise einen Query-String bildet, sollen die entsprechenden Daten den bereits vorhandenen Query-String nicht ersetzen, sondern an diesen angehängt werden.
  • qsdiscard|QSD (seit Version 2.4): Falls die ursprüngliche URL einen Query-String enthält, wird dieser nicht wie üblich beibehalten, sondern entfernt. QSD hat dabei Vorrang vor QSA.
  • noescape|NE: Im Ersatztext soll kein URL-Escaping durchgeführt werden. Dies ist z. B. nützlich, wenn %-Zeichen nicht codiert werden, sondern manuelles Escaping bewirken sollen.
  • passthrough|PT: Das Ergebnis der RewriteRule wird so aufbereitet, dass der nächste Handler, der sich um die Umsetzung der Anforderungs-URL in einen Dateinamen kümmert, damit zurechtkommt. Intern wird das Feld request_req>uri wieder auf den Wert von filename gesetzt. Dieses Flag ist beispielsweise erforderlich, wenn mod_rewrite und mod_alias gemeinsam verwendet werden.
  • skip|S=n: Die nächsten n RewriteRules sollen übersprungen werden. Dieses Flag ist für if/else-artige Fallentscheidungen geeignet.
  • env|E=VAR:VAL: Setzt die angegebene Umgebungsvariable (VAR) auf den genannten Wert (VAL).
  • cookie|CO=Name:Wert[:Lifetime[:Pfad]]: Dies sorgt dafür, dass ein Cookie gesetzt wird. Name und Wert sind obligatorisch, während Lifetime (Gültigkeitsdauer) und Pfad (Geltungsbereich) des Cookies optional sind. Cookies ohne Gültigkeitsdauer sind sogenannte Session-Cookies, die am Ende der Client-Sitzung automatisch gelöscht werden.
Beachten Sie zu guter Letzt Folgendes

Wenn Sie RewriteRule in Verzeichniskontexten einsetzen, wird der Pfad bis zum entsprechenden Verzeichnis vor dem Rewriting aus der URL entfernt und erst danach wieder hinzugefügt. Eine Ausnahme tritt ein, wenn der Ersatzstring mit http:// beginnt.

RewriteCond Bedingung, unter der Rewrite durchgeführt wird

Seit Version 1.3 Modul mod_rewrite Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files>, .htaccess (FileInfo) Syntax RewriteCond Teststring RegExp Standardwert nicht gesetzt

Diese Direktive formuliert gewissermaßen eine Vorbedingung für nachfolgende RewriteRule-Anweisungen, die zusätzlich zu dem RegExp-Match zutreffen muss. Wenn Sie mehrere RewriteCond-Direktiven untereinanderschreiben, müssen sie standardmäßig alle zutreffen, damit die RewriteRule-Anweisungen beachtet werden.

Das erste Argument, der Teststring, ist einfacher Text, der zusätzlich folgende Konstrukte enthalten kann:

  • $1 bis $9: Referenz auf einen geklammerten Teilausdruck aus dem regulären Ausdruck der nachfolgenden RewriteRule-Direktive
  • %1 bis %9: Referenz auf einen geklammerten Teilausdruck im regulären Ausdruck der vorigen RewriteCond
  • ${Map-Name:Schlüssel[|Standardwert]}: Referenz auf den angegebenen Schlüssel in der durch Map-Name bezeichneten RewriteMap
  • %{VAR}: Zugriff auf die benannte Server-Variable (Näheres weiter oben in der Beschreibung der Direktive RewriteRule und in Kapitel 14, »CGI«)

Das zweite Argument von RewriteCond ist ein mit Perl kompatibler regulärer Ausdruck, mit dem das erste Argument verglichen wird. Diesem können Sie optional ein Ausrufezeichen voranstellen – die RewriteCond gilt dann nur als zutreffend, wenn der Ausdruck nicht passt. Alternativ können Sie statt eines regulären Ausdrucks auch folgende Spezialformulierungen verwenden:

  • <String: Trifft zu, wenn das erste Argument im Alphabet (genauer gesagt in der Zeichensatzreihenfolge) vor dem hier angegebenen String steht.
  • >String: Wahr, wenn das erste Argument in der Zeichensatzreihenfolge nach diesem Text folgt.
  • =String: Zutreffend, wenn das erste Argument genau mit dem Teststring identisch ist. Dies ist eine praktische Kurzfassung für den regulären Ausdruck

^String$.

  • -d: Wahr, wenn das erste Argument ein Verzeichnis (Directory) ist.
  • -f: Ist zutreffend, wenn das erste Argument eine normale Datei (File) ist.
  • -s: Zutreffend, wenn das erste Argument eine Datei mit Inhalt ist – erkennbar an einer Dateigröße (Size) von über 0 Byte.
  • -l: Wahr, wenn das erste Argument ein symbolischer Link ist.
  • -F: Dieses Argument führt eine Unterabfrage durch, um zu überprüfen, ob es sich beim ersten Argument um eine tatsächlich verfügbare Datei handelt.
  • -U: Führt ebenfalls eine Unterabfrage durch und prüft, ob das erste Argument eine verfügbare URL ist.

Alle diese Sonderargumente können Sie ebenfalls mit einem vorangestellten Anführungszeichen verneinen.

Das optionale dritte Argument sind auch hier Flags, die durch Kommata getrennt werden und in eckigen Klammern stehen. Die folgenden beiden Flags sind hier definiert:

  • NC|nocase Im regulären Ausdruck des zweiten Arguments soll nicht zwischen Groß- und Kleinschreibung unterschieden werden.
  • OR|ornext Zwischen der aktuellen und der nächsten RewriteCond-Anweisung wird ein logisches Oder gesetzt – es genügt, wenn eine von ihnen zutrifft. Der Normalfall ist dagegen ein logisches Und: Alle aufeinanderfolgenden RewriteCondDirektiven müssen zutreffen, damit die nachfolgenden RewriteRule-Anweisungen beachtet werden.
RewriteBase

Basis-URL für Rewrite-Verzeichnisse

Seit Version 1.3 Modul mod_rewrite Kontext <Directory>, <Location>, <Files>, .htaccess (FileInfo) Syntax RewriteBase URL-Pfad Standardwert aktuelles Verzeichnis (Näheres siehe Text)

Diese Direktive gibt den Basis-Verzeichnispfad für Rewrite-Operationen an. Dies kann für RewriteRule-Operationen in <Directory>-Containern verwendet werden.

Der Standardwert ist der tatsächliche Verzeichnispfad im Dateisystem. Wie bereits erwähnt, wird bei RewriteRule-Direktiven in untergeordneten Kontexten zunächst der URL-Pfad dieser Kontexte entfernt; nach erfolgtem Rewrite wird er wieder hinzugefügt.

In der Regel ist die Voreinstellung in Ordnung. Geändert werden muss sie nur, wenn der URL-Pfad des Containers nicht dem Verzeichnispfad entspricht – dies ist z. B. bei Verzeichnissen der Fall, die durch Alias-Anweisungen eingebunden wurden.

Betrachten Sie dazu folgendes Beispiel:

  1. Einbinden des Verzeichnisses /woanders unter der URL /test Alias /test /woanders
  2. Einstellungen für das Verzeichnis /woanders
<Directory /woanders>
# URL-Pfad für Rewrites muss auf /test gesetzt werden RewriteBase /test RewriteRule ...
</Directory>
RewriteMap

Schlägt einen Rewrite-Schlüssel in einer Map-Datei nach

Seit Version 1.3; DBM-Auswahl seit 2.0.41 Modul mod_rewrite Kontext Server, <VirtualHost> Syntax RewriteMap Map-Name Map-Typ:Map-Datei Standardwert nicht gesetzt

Diese Direktive bindet eine Datei mit Schlüssel-Wert-Paaren für das Nachschlagen von Rewrite-Regeln ein. Solche RewriteMap-Dateien sind praktisch, wenn Sie in RewriteRule-Ersatztexten oder RewriteCond-Teststrings häufiger bestimmte Textbausteine benötigen: Sie können den Schlüssel angeben, und der entsprechende Wert wird automatisch eingesetzt.

In einer RewriteRule- oder RewriteCond-Direktive erfolgt der Zugriff auf die RewriteMap nach folgendem Schema: 

${Map-Name:Schlüssel}

Aus Sicherheitsgründen ist es besser, zusätzlich einen Standardwert anzugeben. Dieser wird eingesetzt, wenn der Schlüssel nicht gefunden wird. Die Schreibweise sieht so aus: 

${Map-Name:Schlüssel|Standardwert}

Der Map-Name entspricht dem ersten Argument von RewriteMap. Es handelt sich um einen beliebigen String, den Sie sich aussuchen können. Das zweite Argument ist die durch Doppelpunkt getrennte Kombination aus dem Typ der RewriteMap und dem entsprechenden Dateinamen. Folgende Typen sind definiert:

  • txt: einfache Textdatei Dies ist die einfachste Art einer Map-Datei. Jede Zeile enthält ein durch Leerzeichen getrenntes Schlüssel-Wert-Paar. Leerzeilen und Kommentare (Text nach einer #) werden ignoriert. Sollten Sie einen Schlüssel mehrfach definieren, gilt das erste Vorkommen. Hier ein Beispiel für eine solche Definition:
RewriteMap mailmap txt:/Pfad/von/mailmap.txt

Die Datei könnte beispielsweise folgendermaßen aussehen:

  1. mailmap.txt – E-Mail-Adressen von Mitarbeitern ps peterschmitz@mynet.de # Peter Schmitz, Vertrieb bm bertmueller@mynet.de # Bert Müller, Technik ab antonbecker@mynet.de # Anton Becker, IT

Wenn Sie nun in einer URL – z. B. in einem Query-String – eine der E-MailAdressen benötigen, funktioniert der Zugriff in etwa so: 

${mailmap:ps|info@mynet.de}

Damit nicht die Gefahr entsteht, gar keine E-Mail-Adresse zu erhalten, wird die Hauptfirmenadresse info@mynet.de als Standardwert verwendet.

  • rnd: Textdatei mit Werten zur zufälligen Auswahl Auch dieser Map-Typ ist eine gewöhnliche Textdatei. Die Besonderheit besteht darin, dass Sie für jeden Schlüssel mehrere, durch Pipe-Zeichen (|) getrennte Werte angeben können. Bei jedem Zugriff auf den Schlüssel wählt Apache einen der Werte zufällig aus. Interessant ist dieses Verfahren für vielfältige Zwecke: Naheliegend wäre die zufällige Auswahl eines Bildes, eines Zitats oder einer URL aus einer Linkliste. Selbst für einfaches Load-Balancing taugt das Verfahren: Aus einer Liste von Host-Namensbestandteilen wie www1 bis www9 könnte bei jeder Anfrage ein anderer ausgewählt werden. Näheres dazu finden Sie in Kapitel 12, »Skalierung und Performance-Tuning«.

Das folgende Beispiel ermöglicht die Auswahl eines Bildes und einer Link-URL aus Alternativenlisten: 

RewriteMap linkmap rnd:/Pfad/von/linkmap.txt

Die zugehörige Datei sieht möglicherweise so aus: 

# linkmap.txt – zufällige Bild- und Link-URLs bild photo.jpg|grafik.gif|bild.png|beispiel.jpg link /info/index.html|/news/index.html|/catalog/index.html

Die folgende RewriteRule wandelt einen Aufruf von /images/zbild in ein zufällig ausgewähltes Bild um: 

RewriteRule ^/images/zbild /images/${linkmap:bild|default.gif}
  • dbm: DBM-Datei anstelle der einfachen Textdatei Wenn Sie eine RewriteMap mit sehr vielen Zuordnungen benötigen, kann es sich günstig auf die Performance auswirken, statt der einfachen Textdateien datenbankartige DBM-Dateien zu verwenden. Der Inhalt einer solchen Datei ist mit der Textdatei identisch, wird aber binär gespeichert und mit einem Index versehen.

Je nach Plattform stehen nicht alle Formen von DBM-Dateien (SDBM, GDBM, NDBM usw.) zur Verfügung. Recht empfehlenswert sind SDBM-Dateien: Zwar sind einige andere DBM-Typen noch schneller, aber dafür wird SDBM auf vielen Plattformen unterstützt und ist sowohl in Apache als auch beispielsweise in Perl automatisch eingebaut. Andere DBM-Typen müssen Sie mithilfe der in Kapitel 4, »Apache kompilieren und installieren«, vorgestellten configureEinstellungen wie --with-gdbm bei der Kompilierung hinzufügen. Es ist wichtig, dass Sie folgende Beschränkung von SDBM-Dateien beachten: Ein Schlüssel und sein Wert dürfen zusammen nicht länger als 1.000 Byte sein. Natürlich ist es unwahrscheinlich, dass Sie in URLs jemals eine solche

Textmenge benötigen – aber bei der per Rewrite gesteuerten Erzeugung von Query-Strings könnte es immerhin vorkommen. Sie können beispielsweise das folgende kleine Skript verwenden, um eine solche Datei aus Benutzereingaben zu erzeugen (es befindet sich zusätzlich auf der beiliegenden DVD-ROM): 

#!/usr/bin/perl -w use strict;
use Fcntl;
use SDBM_File;

# Name der MAP-Datei aus Kommandozeilenargument / Standard my $mapfile = $ARGV[0] || 'map';

# Hash %map mit tie() an $mapfile binden tie(my %map, 'SDBM_File', $mapfile, O_RDWR|O_CREAT, 0666)
|| die "Kein Zugriff auf $mapfile: $!\n";

# Bisherige Einträge anzeigen print "Vorhandene Werte in $mapfile:\n";
foreach my $key (keys %map) {
my $entry = $map{$key};
print "$key\t$entry\n";
}

# Eingabe neuer Einträge print "Bitte 'Name Wert'-Paare eingeben.\n"
print "[Einfaches ENTER zum Beenden.]\n";
while (my $line = <>) {
chomp $line;
last if ($line eq );
if ($line !~ /^[^\s]+\s+[^\s]+/) {
print "Falsches Format: $line\n";
next;
}
my ($key, $val) = split (/\s+/, $line);
$map{$key} = $val;
}

Wenn Sie das Programm ausführen, werden zunächst die vorhandenen Werte angezeigt. Anschließend können Sie so lange neue eingeben, bis Sie einfach (¢) drücken. In der Ausführung sieht das etwa so aus: 

$ chmod a+x sdbmedit.pl
$ ./sdbmedit.pl mymap

Vorhandene Werte in mymap: 

logo /images/common/logo.gif photo /images/photos/photo1.jpg Bitte 'Name Wert'-Paare eingeben.

[Einfaches ENTER zum Beenden.] 

head /images/common/headline.gif bullet /images/common/bullet.gif logo /images/common/neulogo.gif

Wenn Sie den Namen eines bereits vorhandenen Schlüssels eingeben (hier z. B. logo), wird dessen bisheriger Wert überschrieben. Die praktische Funktion tie()bindet eine Variable an ein Package beziehungsweise eine Klasse. Im vorliegenden Beispiel führen Änderungen der Variablen dazu, dass auch die SDBM-Datei automatisch geändert wird. Bei SDBM_File werden folgende Argumente für tie() benötigt:

  • Name der Hash-Variablen
  • der Klassenname SDBM_File
  • der Dateiname für die SDBM-Datei. Sie sollten einen Namen ohne Endung verwenden, weil automatisch die beiden Dateien NAME.pag und NAME.

dir erzeugt werden.

  • open-Konstanten für Lesen, Schreiben usw. Die symbolischen Konstanten werden durch Fcntl bereitgestellt. O_RDWR öffnet die Datei zum Lesen und Schreiben; O_CREAT erzeugt sie neu, falls sie noch nicht existieren sollte.
  • Berechtigungen für die Datei. 0666 bedeutet, dass zunächst einmal jeder die Datei lesen und hineinschreiben darf. Diese Berechtigungen werden durch die umask des aktuellen Benutzers modifiziert.

Wenn eine Eingabe nicht mindestens ein Zeichen für den Schlüssel, ein Leerzeichen und ein Zeichen für den Wert enthält, wird sie mit einer Fehlermeldung zurückgewiesen; next() überspringt den Rest des Schleifenrumpfes und beginnt sofort den nächsten Schleifendurchlauf. Alternativ steht seit Apache 2.1-beta das neue Hilfsprogramm httxt2dbm zur Verfügung, das textbasierte Map-Dateien automatisch in DBM-Dateien umwandelt. Das Syntaxschema dieses Programms sieht wie folgt aus: 

httxt2dbm [-v] [-f DBM-Typ] –i Eingabedatei –o Ausgabedatei

Die Kommandozeilenparameter haben die nachfolgende Bedeutung:

  • -v (verbose) sorgt für eine ausführlichere Ausgabe.
  • -f ermöglicht Ihnen die Angabe des DBM-Typs (GDBM, SDBM, DB oder NDBM). Wenn Sie keinen Typ angeben, wird der APR-Standardwert gewählt.
  • -i gibt die Textdatei an, aus der die Eingabedaten stammen sollen. Das Format muss den Angaben entsprechen, die weiter oben für den Map-Typ txt gemacht wurden.
  • -o dient der Angabe eines Namens für die Ausgabedatei.

Das folgende Beispiel wandelt die Datei mymap.txt in die SDBM-Datei mymap um: 

# httxt2dbm –f SDBM –i mymap.txt –o mymap

Die fertige SDBM-Datei können Sie folgendermaßen als Map-Datei definieren:

RewriteMap mymap dbm:/Pfad/von/mymap

  • int: Interne Funktion verwenden Statt einer richtigen map soll eine der folgenden internen Funktionen verwendet werden:
  • toupper: Der bisherige Wert des »Schlüssels« wird komplett in Großbuchstaben konvertiert. NurEinTest würde zu NUREINTEST.
  • tolower: Der Wert wird in Kleinbuchstaben umgewandelt. Aus NurEinTest wird in diesem Fall nureintest.
  • escape: Sonderzeichen im Text werden URL-codiert. Günther Möller wird z. B. durch G%FCnther+M%F6ller ersetzt.
  • unescape: Eventuelle URL-codierte Sonderzeichen werden in ihre normale Form umgewandelt. Das vorige Beispiel könnte in diesem Fall umgekehrt ausgeführt werden.

Die Einbindung einer solchen Funktion als Map funktioniert z. B. so:

RewriteMap klein int:tolower

  • prg: eigenes Programm ausführen Der letzte Map-Typ ist der komplizierteste, aber auch der vielseitigste: Es wird ein externes Programm aufgerufen, das beliebige Manipulationen am URLInhalt durchführen kann. Für ein solches Programm gelten folgende Voraussetzungen:
  • Der zu ändernde Text (der jeweilige »Schlüssel«) wird automatisch über STDIN eingegeben. Das Ergebnis muss auf STDOUT geschrieben werden. Da das Programm nur einmal beim Start von Apache aktiviert wird, benötigt es eine Eingabeschleife, die die verschiedenen Anforderungen nacheinander entgegennimmt.
  • Es darf keine gepufferte Ausgabe stattfinden. Da bei einer solchen Änderung so gut wie nie genügend Text zusammenkommt, um den Ausgabepuffer zu füllen, bleibt das Programm – und damit die Anfrage – hängen. In Perl können Sie für STDOUT den Autoflush-Modus aktivieren, um dies zu verhindern. Fügen Sie dazu am Anfang Ihres Skripts folgende Zeilen ein:

select (STDOUT); $| = 1;

  • Um verschiedene Zugriffe auf Ihr Map-Programm zu serialisieren, müssen Sie mit der gleichnamigen Direktive eine RewriteLock-Datei definieren.

Hier ein recht nützliches Beispiel: Das folgende Perl-Skript liefert für den Schlüssel now (und als Standardwert für nicht gefundene Schlüssel) das aktuelle Datum im Format 2008-08-26. yesterday bringt das ebenso formatierte Datum des Vortags; Schlüsselnamen wie minus3 oder minus7 gehen die entsprechende Anzahl von Tagen zurück. Wenn Sie jeden Tag eine bestimmte Datei erzeugen, in deren Namen für spätere Archivzwecke das aktuelle Datum vorkommt, ist es praktischer, sie über eine solche Rewrite-Option zu verlinken, als später umzubenennen. Hier der Code für das Beispiel:

  1. !/usr/bin/perl -w
  2. datemap.pl – Datum für URL-Umwandlung ermitteln use strict;

select (STDOUT); $| = 1; # Autoflush-Modus my $daysec = 24 * 60 * 60; # 1 Tag in Sekunden

  1. Monatsnamen aus scalar(localtime) in Nummern umwandeln:

my %months = (Jan => '01', Feb => '02', Mar => '03', Apr => '04', May => '05', Jun => '06', Jul => '07', Aug => '08', Sep => '09', Oct => '10', Nov => '11', Dec => '12');

  1. "Schlüssel" von STDIN lesen while (my $key = <STDIN>) {

chomp $key; my $now = time(); # Aktuelles Datum/Uhrzeit if ($key eq 'yesterday') { $now -= $daysec; # 1 Tag abziehen } elsif ($key =~ /^minus(\d+)/) { $now -= $daysec * $1; # n Tage abziehen }

  1. Datum umwandeln –
  2. liefert z. B. "Thu Aug 28 12:06:22 2008"

my $timestr = scalar (localtime ($now));

  1. Ergebnis in Einzelteile zerlegen

my ($wd, $month, $day, $t, $year) = split (/\s+/, $timestr);

  1. Monatsnummer ermitteln my $monthnr = $months{$month};
  2. '0' vor dem Tagesdatum, falls < 10

$day = ($day < 10) ? "0$day" : $day;

  1. Komplettes Datum zusammensetzen – z. B. 2008-08-19

my $output = "${year}-${monthnr}-${day}";

  1. Ausgabe auf STDOUT print $output;

}

Verwenden können Sie dieses Skript z. B. folgendermaßen: 

RewriteMap dates prg:/Pfad/von/datemap.pl
  1. Zugriffe auf /news/now in /news/JJJJ-MM-DD umwandeln RewriteRule ^/news/now/(.*) /news/${dates:now}/$1
  2. Zugriffe auf /news/yesterday umwandeln RewriteRule ^/news/yesterday/(.*) /news/${dates:yesterday}/$1

Noch effizienter wird es, wenn der Teil des Verzeichnispfades hinter /news/ direkt an die Map durchgereicht wird: 

RewriteRule ^/news/([^/]+)/(.*) /news/${dates:$1}/$2

Unter Windows müssen Sie eine wichtige Änderung durchführen, damit ein solches Map-Skript ausgeführt werden kann: Da ein Perl-Skript formal kein ausführbares Programm ist, können Sie als Quelle Ihres Programms nicht einfach so etwas wie C:/Verzeichnis/skript.pl verwenden, sondern müssen den Pfad des Perl-Interpreters angeben. Hier sieht die RewriteMap-Anweisung z. B. so aus: 

RewriteMap dates \
"prg:C:/Perl/bin/perl.exe C:/Apache2/conf/datemap.pl"

Aber auch mit dieser Option ist auf Windows-Systemen von Map-Programmen abzuraten. Besonders die Inkompatibilität mit Zeilenumbrüchen sorgt dafür, dass sie auf dieser Plattform oft hängen bleiben. 

RewriteLock Lock-Datei zur RewriteMap-Synchronisation

Version 1.3 bis 2.2 Modul mod_rewrite Kontext Server

Syntax RewriteLock Dateipfad Standardwert nicht gesetzt

Wenn Sie selbst geschriebene Programme als RewriteMap verwenden, benötigen Sie eine mithilfe dieser Direktive definierte Lock-Datei. Diese sorgt dafür, dass nicht mehrere Anfragen gleichzeitig auf das Programm zugreifen. Beispiel: 

RewriteLock /var/run/apache2/rewrite.lck

Ab Apache 2.3.4 wird der allgemeine Wert der Direktive Mutex (siehe Kapitel 6, »Grundkonfiguration«) für das Rewrite-Locking verwendet.

RewriteOptions

Zusätzliche Rewrite-Optionen

Seit Version 1.3; MaxRedirects seit 2.0.45 und nicht mehr ab 2.1-beta Modul mod_rewrite Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files>, .htaccess (FileInfo) Syntax RewriteOptions Option [Option ...] Standardwert MaxRedirects=10

Diese Direktive ermöglicht es, zusätzliche Rewrite-Optionen zu setzen. Folgende zwei Optionen sind möglich:

  • inherit Sämtliche Rewrite-Einstellungen wie RewriteRule, RewriteMap usw. werden aus dem übergeordneten Kontext übernommen.
  • MaxRedirects=Anzahl Beschränkt die Verarbeitung auf eine maximale Anzahl interner Weiterleitungen, um der Gefahr einer Endlosschleife zu entgehen. Wenn die angegebene Anzahl überschritten wird, wird eine Meldung mit dem Status 500 Internal Script Error geliefert. Die Voreinstellung ist 10; in den allermeisten Fällen sollte sie ausreichen. Seit Apache 2.2 ist diese Option nicht mehr verfügbar.

Rewrite-Beispiele Wie Sie gesehen haben, wurden in den Beschreibungen der einzelnen RewriteDirektiven noch keine ausführlichen Beispiele gezeigt. Da die Direktiven äußerst komplex sind und vielfältige Optionen besitzen, war es ratsam, sie zunächst im Überblick zu beschreiben.

Dafür finden Sie hier eine kleine Sammlung von Beispielen. In den späteren Kapiteln dieses Buches wird noch des Öfteren auf mod_rewrite zurückgegriffen, da es praktische Lösungen für zahlreiche Situationen bietet. Ein etwas umfangreicheres »Rewrite-Kochbuch« finden Sie in der Apache-Online-Konfiguration: Der »URL Rewriting Guide« von Ralf S. Engelschall, Autor des Moduls, befindet sich unter der URL http://httpd.apache.org/docs2.2/misc/rewriteguide.html.

  • Einfacher Alias Selbstverständlich beherrscht mod_rewrite alle Fähigkeiten von Alias. Das folgende Beispiel bindet das Verzeichnis /usr/local/apache2/mydocs unter dem URL-Pfad /text ein:
RewriteEngine On RewriteRule ^/text(.*) /usr/local/apache2/mydocs$1

Auch die erweiterten Funktionen von AliasMatch sind natürlich in RewriteRule enthalten – schließlich ist der Vergleichstext ohnehin ein regulärer Ausdruck. Dieses Beispiel leitet alle Anfragen nach Dokumenten mit der Endung .htm oder .html auf entsprechende .php-Dateien um (eine nette Spielerei, die die verwendete Technologie für Server-Anwendungen zumindest vordergründig versteckt): 

RewriteEngine On RewriteRule ^(.*)\.html?$ $1.php
  • Einfache Weiterleitung Auch Weiterleitungen im Stil von Redirect und RedirectMatch sind mit RewriteRule natürlich überhaupt kein Problem. Dazu muss die Direktive mit dem Flag [R] aufgerufen werden. Das folgende Beispiel leitet alle Anfragen auf die Site www.ersatz-server.de weiter; Sie könnten so etwas brauchen, wenn Sie unaufschiebbare Wartungsarbeiten an Ihrem Server durchführen müssen:
RewriteEngine On 
RewriteRule .* http://www.ersatz-server.de [R]

Das nächste Beispiel leitet dagegen Anfragen, die mit dem Verzeichnis /sales beginnen, an den Server sales.mynet.de weiter – so etwas ist ideal, wenn ein ehemaliges Unterverzeichnis auf einen virtuellen Host oder gar einen eigenen Server-Rechner ausgelagert wird: 

RewriteEngine On 
RewriteRule ^/sales(.*) http://sales.mynet.de$1 [R]
  • Serverseitige Browser-Weiche Wenn Sie schon einmal in JavaScript programmiert haben, kennen Sie sicherlich die berüchtigten Browser-Weichen, die je nach Browser-Modell und -Version unterschiedliche Teile eines Skripts ausführen. Wenn Sie für bestimmte Browser völlig separate Seiten anbieten möchten, können Sie das Ganze auch serverseitig erledigen. Beispielsweise werden mit den beiden folgenden Konfigurationsanweisungen sämtliche Anfragen von Usern, die den Internet Explorer verwenden, mit ansonsten gleichen Pfad- und Dateiangaben in das Unterverzeichnis /msie umgeleitet:
RewriteEngine On RewriteCond %{HTTP_USER_AGENT} msie [NC]
RewriteRule ^/(.*) /msie/$1

Die Server-Variable HTTP_USER_AGENT, die den Wert des Anfrage-Headers UserAgent enthält, wird mit dem regulären Ausdruck msie verglichen – vorsichtshalber mit dem Flag [NC], damit die Groß- und Kleinschreibung nicht beachtet wird.

  • Happy Hour Angenommen, ein E-Commerce-Shop möchte seinen Kunden je nach Uhrzeit spezielle Sonderangebote machen, sofern diese sofort bestellt werden.

Die folgende Kombination aus RewriteCond und RewriteRule leitet Anfragen für das Dokument /angebot.html auf /happyhour.html um, wenn die Stunde den Wert 19 hat (wenn es also zwischen 19:00 und 19:59 Uhr ist): 

RewriteEngine On RewriteCond %{TIME_HOUR} =19
RewriteRule ^/angebot.html$ /happyhour.html

Zu allen anderen Uhrzeiten wird die RewriteRule-Direktive übergangen, weil die Bedingung in der RewriteCond-Anweisung nicht zutrifft.

  • »Microsoft-Free Friday«

Unter zahlreichen Adressen im Web können Sie ein Apache-Modul herunterladen, das freitags alle User aussperrt, die den Microsoft Internet Explorer verwenden (suchen Sie mit einer Suchmaschine Ihrer Wahl nach »Microsoft-Free Friday«). Das ist zwar ein nettes Beispiel für die Modulprogrammierung, aber eigentlich überhaupt nicht nötig – mit zwei RewriteCond- und einer RewriteRule-Direktive lässt sich nämlich dasselbe erreichen: 

RewriteEngine On RewriteCond %{TIME_WDAY} =5
RewriteCond %{HTTP_USER_AGENT} msie [NC]
RewriteRule .* /no-ms.html
  • Session-Tracking Sicher haben Sie schon einmal eine URL wie diese gesehen: http://

www.mynet.de/6FC9387432BA02E4/info.html. Die lange Hexadezimalzahl dürfte hier in aller Regel kein echtes Verzeichnis sein, sondern eine SessionID. Sie dient dazu, aufeinanderfolgende Anfragen desselben Users verfolgen zu können – dies ist z. B. wichtig, um Bestellinformationen über mehrere Seiten hinweg gespeichert zu halten. Es ist praktischer, Session-IDs in den URLPfad zu integrieren, als sie im Query-String zu transportieren. Auch das Logging jeder einzelnen Session wird auf diese Weise erleichtert. Die folgende Lösung generiert beim ersten Zugriff auf eine beliebige URL der Website eine neue Session-ID und leitet anschließend jede Anfrage mit Session-ID auf das eigentliche Dokument um, das diese ID natürlich nicht hat. Das erste Hilfsmittel ist eine RewriteMap in Form eines kleinen Perl-Skripts, das auf Anfrage eine 16-stellige hexadezimale Zufallszahl produziert. Dieses Skript heißt session.pl und sieht so aus: 

#!/usr/bin/perl -w use strict;
# Autoflush select (STDOUT);
$| = 1;
# Liste mit Hex-Ziffern für die Session-ID my @hexnums = qw (0 1 2 3 4 5 6 7 8 9 A B C D E F);
# Hauptschleife while (<STDIN>) {
# Der Wert des Schlüssels ist egal # es wird auf jeden Fall eine Session-ID erzeugt my $id = ;
for (my $i = 0; $i < 16; $i++) {
$id .= $hexnums [int (rand (16))];
}
# Neue Session-ID ausgeben print "$id\n";
}

Dieses Map-Skript muss nun als RewriteMap registriert werden. Dies funktioniert folgendermaßen: 

RewriteMap session prg:/usr/local/apache2/mytools/session.pl

Den Pfad müssen Sie natürlich anpassen. Bei der Beschreibung von RewriteMap wurde bereits erwähnt, dass unter Windows auch der Pfad des Interpreters angegeben werden muss, beispielsweise so: 

RewriteMap session "prg:C:/Perl/bin/perl.exe \
C:/Apache2/mytools/session.pl"

Allerdings ist die Wahrscheinlichkeit dennoch groß, dass es auf Windows-Systemen trotz alledem nicht funktioniert. Als Nächstes müssen Sie dafür sorgen, dass alle Anfrage-URLs, die noch keine Session-ID enthalten, sich eine solche aus dieser RewriteMap besorgen. Dazu dient folgende RewriteRule: 

RewriteRule !^/[A-Z0-9]{16}/(.*) /${session:id}/$1 [L]

Zu guter Letzt müssen alle Anfragen mit Session-ID auf die entsprechende Ressource ohne ID umgelenkt werden: 

RewriteRule ^/[A-Z0-9]{16}/(.*) /$1

8.1.3 Benutzerverzeichnisse

Auf Multiuser-Systemen können Sie es den einzelnen Benutzern ermöglichen, ihre privaten Webseiten unter einer URL nach dem Schema http://hostname/ ~username zu veröffentlichen. Dies ist vor allen Dingen bei Universitätsrechenzentren der Fall; Millionen von Studenten auf der ganzen Welt betreiben Websites mit einer solchen Adresse. Apache stellt diese Funktionalität über das Modul mod_userdir bereit. Es sorgt dafür, dass ein bestimmtes Verzeichnis im HomeVerzeichnis des jeweiligen Benutzers automatisch auf diese URL abgebildet wird. Der Name dieses Verzeichnisses wird über die Direktive UserDir festgelegt.

Beachten Sie, dass der Begriff »Home-Verzeichnis« nicht auf jeder Plattform so eindeutig definiert ist wie unter UNIX. Im Einzelnen ist damit Folgendes gemeint:

  • Unter allen UNIX-Systemen außer Mac OS X befindet sich das Home-Verzeichnis eines normalen Benutzers unter /home/username. Das Home-Verzeichnis von root – das in aller Regel nicht ins Web gehört – ist dagegen normalerweise

/root.

  • Mac OS X verwendet statt /home das Verzeichnis /Users; das Home-Verzeichnis eines Benutzers ist also /Users/username.
  • Unter Windows 7 und Vista liegen die Benutzerverzeichnisse unter %HOMEDRIVE%\Users\username (die Umgebungsvariable HOMEDRIVE steht für den Laufwerksbuchstaben der Festplatte, auf der sich Windows befindet). In der deutschen Version wird das Verzeichnis Users durch den Aliasnamen Benutzer maskiert. Die persönlichen Dokumente eines Benutzers liegen dort im Unterverzeichnis Documents. Deshalb ist es ratsam, als UserDir ein Verzeichnis unterhalb davon anzugeben, also beispielsweise Documents/public_html.
  • Bei einer deutschen Version von Windows 2000 und XP befinden sich die Verzeichnisse mit den Daten der einzelnen Benutzer unter %HOMEDRIVE%\

Dokumente und Einstellungen\username; die Dokumente eines Benutzers finden Sie im Unterverzeichnis Eigene Dateien. Ein guter Platz für das UserDir wäre also etwa Eigene Dateien/public_html. Für eine englischsprachige Windows-Version gelten diese Angaben sinngemäß, allerdings lautet der vollständige Pfadname des persönlichen Verzeichnisses (»Eigene Dateien«) hier %HOMEDRIVE%\Documents and Settings\username\My Documents.

  • Unter Windows NT 4.0 befanden sich die persönlichen Dokumente ebenfalls im Verzeichnis Eigene Dateien beziehungsweise My Documents, allerdings war das eigentliche Benutzerverzeichnis hier %SystemRoot%\Profiles\username

(SystemRoot ist übrigens in allen Windows-Versionen das Systemverzeichnis, z. B. C:\WinNT). 

UserDir Verzeichnisname der User-Webverzeichnisse

Modul mod_userdir Kontext Server, <VirtualHost> Syntax UserDir Verzeichnis | enabled [user ...] | disabled [user ...] Standardwert public_html (seit 2.1.4 standardmäßig deaktiviert)

Je nach Plattform sind unterschiedliche Verzeichnisnamen ratsam. Gemäß den obigen Ausführungen über die Home-Verzeichnisse auf den unterschiedlichen Plattformen können Sie unter UNIX beispielsweise Folgendes einstellen: 

UserDir mysite

Damit wird z. B. das Verzeichnis /home/winnetou/mysite als http://www.mynet.de/ ~winnetou veröffentlicht.

Auf einem Windows-XP-Rechner sollten Sie dagegen eine Einstellung wie diese vornehmen: 

UserDir "Eigene Dateien/mysite"

Auf diese Weise würde das Verzeichnis C:\Dokumente und Einstellungen\winnetou\Eigene Dateien\mysite als http://www.mynet.de/~winnetou bereitgestellt.

Um den Zugriff auf die User-Verzeichnisse zu steuern, benötigen Sie anschließend einen Konfigurationsabschnitt wie diesen: 

<Directory /home/*/mysite>
Options Indexes SymLinksIfOwnerMatch AllowOverride AuthConfig Limit FileInfo
<LimitExcept GET POST>
Order Deny,Allow Deny from all
</LimitExcept>
<Limit GET POST>
Order Allow,Deny Allow from all
</Limit>
</Directory>

Dies beschränkt die Optionen und AllowOverride-Einstellungen auf ein relativ sicheres Minimum. Der <LimitExcept>-Container sperrt sämtliche Zugriffe durch HTTP-Methoden außer GET und POST, während der <Limit>-Abschnitt umgekehrt alle GET- und POST-Anfragen gestattet.

Die Verzeichnisangabe im <Directory>-Container muss natürlich je nach Plattform angepasst werden:

  • Mac OS X:

<Directory /Users/*/mysite> ... </Directory>

  • Windows 7/Vista:

<Directory "C:/Users/*/Documents/mysite"> ... </Directory>

  • Windows 2000/XP:

<Directory "C:/Dokumente und Einstellungen/*/Eigene Dateien/mysite"> ... </Directory>

  • Windows NT 4.0:

<Directory "C:/WinNT/Profiles/*/Eigene Dateien/mysite"> ... </Directory>

Um gezielt zu steuern, welche Benutzer ein Webverzeichnis veröffentlichen dürfen, können Sie die speziellen Werte enabled und/oder disabled verwenden, optional gefolgt von einem oder mehreren Benutzernamen.

  • disabled ohne Angabe von Benutzernamen deaktiviert das Feature ganz:

UserDir disabled

  • disabled ohne Benutzernamen und ein anschließendes enabled mit einigen Namen erlaubt nur den ausdrücklich angegebenen Benutzern die Veröffentlichung ihres Webverzeichnisses:

UserDir disabled UserDir enabled hans klaus peter

  • Die umgekehrte Abfolge erlaubt die UserDir-Funktionalität im Allgemeinen und verbietet sie speziellen Benutzern:

UserDir enabled UserDir disabled dieter thomas udo

8.1.4 Fehlerbehandlung

Eine spezielle Form der Weiterleitung stellt der Umgang mit diversen Fehlern dar, die bei der Verarbeitung von Client-Anfragen auftreten können: Schließlich meldet Apache im Fehlerfall nicht nur den entsprechenden Statuscode (z. B. 404 Not Found), sondern liefert auch ein Dokument aus, das den Fehler näher beschreibt. Welches Dokument dies für den jeweiligen Fehler sein soll, wird durch die Core-Direktive ErrorDocument festgelegt.

ErrorDocument Dokument, das bei einem bestimmten Fehler gesendet werden soll

Modul core Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files>, .htaccess (FileInfo) Syntax ErrorDocument Fehlercode URL|Pfad|Meldungstext Standardwert Einfache Textmeldung für jeden Fehler

Mit dieser Direktive können Sie einstellen, welche Fehlermeldung Apache für einen bestimmten Fehlercode an den Client senden soll. Dies betrifft sowohl Anfragefehler (4xx-Statuscodes) als auch Server-Fehler (5xx-Statuscodes). Wenn Sie ErrorDocument für einen bestimmten Fehler nicht setzen, wird eine vorgegebene Textmeldung gesendet.

Sie können für jeden Fehler eine von drei möglichen Meldungsquellen festlegen:

  • Eigene Textmeldung Geben Sie dazu einen beliebigen String in Anführungszeichen an (die alte 1.3Syntax, bei der die Meldung lediglich mit einem Anführungszeichen beginnen musste, gilt nicht mehr). Beispiel:
ErrorDocument 404 "Nae, esu jet hammer aevver nit!"3
  • Interne Weiterleitung Der Wert ist ein beliebiger URL-Pfad, der relativ zur DocumentRoot ausgewertet wird. Beispiel:
ErrorDocument 500 /cgi-bin/debug.pl

Dies ist die beliebteste Verwendung von ErrorDocument – mit ihrer Hilfe können Sie die Fehlermeldungen dem Layout Ihrer Website anpassen. Beachten Sie in diesem Zusammenhang, dass der Microsoft Internet Explorer solche Dokumente nur dann anzeigt (und nicht durch seine eigenen Fehlermeldungen ersetzt), wenn sie eine bestimmte Mindestlänge haben – in der Regel liegt diese bei 512 Byte.

  • Externe Weiterleitung Als Wert wird eine externe URL angegeben, die mit http:// beginnt. Beachten Sie, dass Sie diesen Typ nicht für den Status 401 Authorization Required verwenden können, weil Browser über Domain-Grenzen hinweg keine Anmeldeinformationen anfordern. Beispiel:
ErrorDocument 403 http://im.parkverbot.de

Das Dokument für die interne Weiterleitung kann eine Type-Map sein (Header und MIME-Einstellungen). Dies ermöglicht internationalisierte Fehlermeldungsseiten. Entsprechende Dokumente, bei denen die Body-Abschnitte für die unterschiedlichen Sprachen bereits enthalten sind, werden mit Apache 2 geliefert. Sie befinden sich im Verzeichnis error unter der ServerRoot und heißen HTTP_<Fehler>.html.var, also beispielsweise HTTP_NOT_FOUND. html.var für Fehler 404. Die Standard-Konfigurationsdatei enthält bereits einige Zeilen, um sie zu aktivieren – bei Bedarf können Sie einfach das Kommentarzeichen # entfernen.

8.1.5 URL-Korrektur

mod_speling

Eine etwas abenteuerliche Form der automatischen Weiterleitung steht Ihnen zur Verfügung, wenn Sie das Modul mod_speling (der »Fehler« im Namen ist Absicht) aktivieren: Wenn unter einer angeforderten URL kein Dokument zu finden ist, 3 Hochdeutsch: »Nein, so etwas haben wir aber nicht!« versucht es, ein Dokument mit einem ähnlichen Namen zu liefern und auf diese Weise Rechtschreibfehler in URLs zu korrigieren.

Das Modul ignoriert in einem ersten Schritt die Groß- und Kleinschreibung der angeforderten URL und akzeptiert im zweiten Schritt alle Varianten, die höchstens einen weiteren Fehler aus folgenden Kategorien enthalten:

  • Zusätzliches Zeichen Angefordert wurde info.html; vorhanden ist nur infos.html.
  • Fehlendes Zeichen Die angeforderte URL war books.html, aber nur book.html ist vorhanden.
  • Falsches Zeichen Die Anfrage enthielt den Dateinamen test.html; lieferbar ist text.html.
  • Dreher Der Client fragte irrtümlich nach speil.html; der Server kann spiel.html liefern.
  • Andere Dateiendungen Der Client fordert index.html an; gefunden wird index.php.

Wenn nach einer entsprechenden Überprüfung des Verzeichnisses keine Variante gefunden wird, erhält der Client genau wie im Fall ohne mod_speling die Antwort 404 Not Found. Findet Apache genau ein passendes Dokument, liefert er es ohne weitere Nachfrage aus. Bei mehreren gleichwertigen Treffern wird dagegen eine Liste mit dem Status 300 Multiple Choices geliefert.

CheckSpelling
  • Korrektur von URL-Schreibfehlern aktivieren
  • Seit Version 1.3 (vor 1.3.2 nur im Server- und VHost-Kontext)
  • Modul mod_speling Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files>, .htaccess (Options)
  • Syntax CheckSpelling On|Off Standardwert Off

Die Funktionalität von mod_speling wird im entsprechenden Kontext und in seinen Unterkontexten nur dann aktiviert, wenn Sie sie mit dieser Direktive explizit einschalten: 

CheckSpelling On

Bei Bedarf können Sie sie in einem untergeordneten Kontext wieder ausschalten, indem Sie dort folgende Anweisung einsetzen: 

CheckSpelling Off
CheckCaseOnly

Nur Änderung der Groß- und Kleinschreibung

Seit Version 2.2.0 Modul mod_speling Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files>, .htaccess (Options) Syntax CheckCaseOnly On|Off Standardwert Off

Wenn Sie diese Direktive zusätzlich zu CheckSpelling On ebenfalls auf On setzen, wird die Funktionalität von mod_speling eingeschränkt: Es werden nur noch Änderungen in der Groß- und Kleinschreibung vorgenommen; alle anderen Optionen werden ausgeschaltet.

8.1.6 Status- und Konfigurationsinformationen

über den Server Apache 2 wird mit zwei sehr praktischen Modulen geliefert, die im weitesten Sinne auch mit Weiterleitung zu tun haben, da ähnlich wie bei Alias-Direktiven externe Daten in den URL-Bereich des Servers eingebunden werden: mod_info liefert die Konfigurationsdaten des laufenden Apache-Servers als HTML-Dokument; mod_status stellt dagegen Statusinformationen zur Verfügung. Beide sind ideal zur (Fern-)Diagnose des Servers geeignet. Mit den Informationen von mod_ info können Sie beispielsweise schnell überprüfen, ob irgendein Server-Problem mit der Konfiguration zu tun hat. mod_status erlaubt Ihnen z. B. die Analyse von Performance-Engpässen.

Wenn Sie die Informationen von mod_info einbinden möchten, müssen Sie dafür eine <Location> verwenden, die keinem existierenden Verzeichnis entspricht – weder unterhalb der DocumentRoot noch per Alias eingebunden. Damit unter dieser URL Server-Informationen geliefert werden, muss der Handler serverinfo gesetzt werden. Abgesehen davon sollte die URL vor Zugriffen durch Unbefugte geschützt werden. Zusätzlich zu der hier gezeigten Beschränkung auf das lokale Netzwerk sollten Sie auch noch eine Benutzeranmeldung verlangen (siehe Kapitel 9, »Authentifizierung«). Das folgende Beispiel stellt die Konfigurationsinformationen unter dem URL-Pfad /_info zur Verfügung: 

<Location /_info>
SetHandler server-info Order deny,allow Deny from all Allow from 192.168.0

# Hier Benutzeranmeldung hinzufügen!
</Location>

Als berechtigter User können Sie nun einen beliebigen Browser öffnen und erhalten die Konfigurationsdaten unter der URL http://www.mynet.de/_info.

Seit Version 2.1-beta können Sie einen Query-String an die URL anhängen, um einen der folgenden Befehle zur Steuerung der Ausgabe auszuwählen:

  • ?Modulname – gibt nur Informationen über das angegebene Modul aus.
  • ?config – gibt die Konfigurationsinformationen allein, nicht nach Modulen sortiert, aus.
  • ?hooks – zeigt nur die Hooks an, mit denen die einzelnen Module verknüpft sind (Näheres über Hooks erfahren Sie in Kapitel 17, »Apache erweitern«).
  • ?list – gibt nur eine einfache Liste der aktivierten Module aus.
  • ?server – zeigt nur die Grundinformationen über den Server an.

Die Funktionalität des Moduls mod_status wird auf ähnliche Weise eingeschaltet; hier ist lediglich der Handler server-status zuständig. Hier ein Beispiel, das die Statusinformationen unter dem URL-Pfad /_status (im Browser also unter einer URL wie http://www.mynet.de/_status) zugänglich macht:

<Location /_status> SetHandler server-status Order deny,allow Deny from all Allow from 192.168.0

  1. Hier Benutzeranmeldung hinzufügen!

</Location>

Der optionale Query-String-Parameter ?refresh=N aktualisiert die Seite alle N Sekunden. Sie können z. B. die URL http://www.mynet.de/_status?refresh=10 angeben, um die Informationen alle zehn Sekunden neu zu laden.

AddModuleInfo Zusätzliche HTML-Information über ein Modul in der Server-Info

Seit Version 1.3 Modul mod_info Kontext Server, <VirtualHost> Syntax AddModuleInfo Modulname String Standardwert nicht gesetzt

Dies ist die einzige Konfigurationsdirektive des Moduls mod_info; seine Grundfunktion stellt es wie erwähnt durch den Handler server_info bereit. Die Direktive AddModuleInfo gibt den als zweiten Parameter angegebenen HTML-String aus, wenn das entsprechende Modul (erstes Argument) aktiv ist. Den Modulnamen müssen Sie genau wie bei <IfModule>-Containern (siehe Kapitel 6, »Grundkonfiguration«) in Form der Quelltextdatei des Moduls angeben, da nur dieser bei fest einkompilierten Modulen und bei DSO-Modulen identisch ist. Das folgende Beispiel verweist auf die Online-Dokumentation von mod_rewrite, wenn dieses Modul vorhanden ist:

AddModuleInfo mod_rewrite.c \ 'Näheres zu mod_rewrite <a \ href="http://httpd.apache.org/docs-2.2/mod/mod_rewrite.html">\ hier</a>'

ExtendedStatus Statusinformationen für jede einzelne Anfrage

Seit Version 1.3.2 Modul mod_status; ab 2.3 core Kontext Server Syntax ExtendedStatus On|Off Standardwert Off

Wenn Sie die Direktive ExtendedStatus explizit auf On setzen, erhalten Sie nicht nur eine Statistik über alle Anfragen, sondern zusätzlich auch Informationen über jede einzelne Anfrage. Beachten Sie, dass dies die Performance Ihres Webservers beeinträchtigen kann; Sie sollten diese Option nur vorübergehend bei aktuellem Debug-Bedarf einschalten.

SeeRequestTail Das Ende statt des Beginns jeder Anfrage anzeigen

Seit Version 2.2.7 Modul mod_status; ab 2.3 core Kontext Server Syntax SeeRequestTail On|Off Standardwert Off

Wenn Sie ExtendedStatus einschalten, werden standardmäßig die ersten 63 Zeichen jeder Anfrage gespeichert und angezeigt. SeeRequestTail On sorgt dafür, dass stattdessen die letzten 63 Zeichen gewählt werden.

Angenommen, eine Anfrage lautet wie folgt: 

GET /data/media/images/photographs/fruit-and-vegetables/papaya.png HTTP/1.1

Dann würde standardmäßig der folgende Teilstring angezeigt: 

GET /data/media/images/photographs/fruit-and-vegetables/p

SeeRequestTail On würde dagegen folgenden Teil der Anfrage verwenden: 

images/photographs/fruit-and-vegetables/papaya.png HTTP/1.1
Abgerufen von „https://wiki.foxtom.de/index.php?title=Apache2.4/08/1_Aliase_und_Weiterleitungen&oldid=126443“