Nachsendeantrag
Web-Server, die URLs je nach Bedarf manipulieren können, bieten mehr Möglichkeiten zur Strukturierung der angebotenen Information. Allerdings konnte selbst der frei verfügbare Apache, der seit Monaten der meistgenutzte Web-Server im Internet ist, in dieser Hinsicht bisher wenig bieten. Mehr Flexibilität bringt das Zusatzmodul mod_rewrite , das ab der Apache-Version 1.2 offizieller Bestandteil des Web-Servers ist.<br />
Alle wichtigen Anforderungen zur flexiblen Manipulation des Uniform Resource Locator (URL) erfüllt das Modul mod_rewrite, das mit dem HTTP-Daemon Apache ab Version 1.1 eingesetzt werden kann. Ab der Release 1.2 des Web-Servers gehört es zur Distribution. mod_rewrite implementiert eine auf regulären Ausdrücken basierende Rewriting Engine. Sechs Anwendungsfälle sollen hier demonstrieren, in welch unterschiedlichen Konstellationen das Modul sich als nützlich erweisen kann. Die geschilderten Einsatzmöglichkeiten reichen vom einfachen Umbenennen einer Seite, die gleichzeitig noch eine Weile unter der alten Adresse erreichbar sein soll, bis zum Zusammenfassen mehrere Web-Server zu einem Cluster.
Grundidee des Apache-Zusatzmoduls ist es, die physikalische Sicht auf das Dateisystem des Web-Servers von der logischen Adressierung über URLs zu trennen, indem es konsistent und intuitiv formulierte URL-Adressen auf die richtigen Pfadnamen abbildet. Solche Umschreibungen sollen zum einen unhandliche URLs, die einen langen Pfadnamen des Dateiverzeichnisses wiedergeben, vermeiden. Zum anderen lassen sich dadurch die Nachteile umgehen, die sich durch absolute Referenzen ergeben. Zum Beispiel hat man in Softwarearchiven zur Anzeige von Inhaltsverzeichnissen oft komplexe Referenzen der Form <a href="/cgi-bin/targz?/~quux/foo/arc/bar.tar.gz">bar.tar.gz</a> Wenn sich nun - etwa durch Umstrukturierung des Dateisystems - die Position des Skripts und/oder der Archivdateien ändert, bedingt das die Anpassung der Hyperlinks. Für den lokalen Bereich eines Web-Servers ist das noch machbar, alle an anderer Stelle gespeicherten Hyperlinks hingegen (zum Beispiel in Bookmark-Listen der Benutzer oder auf Web-Seiten anderer Server) bleiben unberücksichtigt.
Viel besser wäre es daher, wenn der Hyperlink nur die aufzurufende Datei enthielte und ein syntaktischer Zusatz dem Web-Server signalisierte, daß er den Inhalt genau dieser Datei ausgeben soll. Ein solcher Zusatz ist im Prinzip beliebig wählbar. Beispielsweise ersetzt die RewriteRule in Listing 1 eine Referenz auf mit '.tar.gz' endende Dateien durch den Aufruf des CGI-Skripts - vorausgesetzt, nach dem Dateinamen folgt ein per Konvention festgelegter Slash. Die obige Referenz kann dann wesentlich einfacher und wartbarer angegeben werden: <a href="bar.tar.gz/">bar.tar.gz</a>. Bisher bieten Web-Server nur rudimentäre Ansätze für ein solches notwendiges Mapping. Durch den Einsatz regulärer Ausdrücke, anhand derer die RewriteRule die Regel definiert, nach der Apache den URL umformuliert, stattet mod_rewrite den Web-Server mit deutlich mehr Flexibilität aus.
Zwingend erforderlich ist immer die erste Direktive in Listing 1, da sie die Rewriting Engine einschaltet - ohne das passiert nichts. RewriteBase setzt dann den URL des aktuellen Verzeichnisses. (Diese beiden Direktiven werden in späteren Beispielen nicht mehr explizit erwähnt.) Die Konfiguration des Apache-Moduls mod_rewrite mit Hilfe der genannten und möglicher weiterer Direktiven erfolgt in den Konfigurationsdateien des Web-Servers. (Siehe auch 'Die wichtigsten Direktiven von mod_rewrite'.)
Kooperation zwischen Modul und Server
Die Funktionsweise des Moduls ist im Prinzip recht einfach. mod_rewrite hängt sich beim Kompilieren über die API (Application Program Interface) in den Apache ein. Zur Laufzeit ruft der Apache-Kernel das Modul für jeden eingehenden URL auf. mod_rewrite manipuliert gegebenenfalls diesen URL und übergibt ihm den Apache-Kernel zur weiteren Verarbeitung. Die Ergebnisse der Manipulation können unterschiedlich sein. Eine Möglichkeit ist ein gültiger Pfadname, der direkt zur Auslieferung der angeforderten Web-Seite führt. Alternativ kann eins der drei folgenden Ereignisse im Kernel ausgelöst werden:
- Der HTTP-Redirect-Mechanismus sendet den neuen URL an den Web-Browser zurück und weist diesen damit an, die Web-Seite anzufordern, auf die der modifizierte URL verweist.
- Im zweiten Fall verarbeitet der interne Apache-Proxy den neuen URL und liefert die Daten an den Browser aus, als seien sie lokal vorhanden. Liegen sie noch nicht im Proxy-Cache vor, holt der Apache-Server sie selbständig über den neue URL von einem anderen Server.
- Schließlich kann der Web-Server die angeforderten Daten auch verweigern ('Forbidden'-Flag).
Wie das Ergebnis des Rewriting aussieht, ist abhängig von den anwendbaren Regeln. Eine solche Regel besteht immer aus einem regulären Ausdruck, der auf den URL angewendet wird (Vergleich), sowie einem Ergebnis-String, der im Fall eines erfolgreichen Vergleichs den aktuellen URL ersetzt (Substitution). Dazu geht die Rewriting Engine sequentiell durch die Liste der konfigurierten Regeln und wendet sie jeweils auf den aktuellen Wert des URL an, bis entweder eine Regel vorzeitig das Rewriting abbricht oder das Ende der Liste erreicht ist. Der Kasten 'Regeln bestimmen die URL-Manipulation' verdeutlicht diesen Mechanismus an einem Beispiel.
Neue Namen für alte URLs
Apache kennt neben dem serverglobalen Kontext, der sich auf alle vom Web-Master verwalteten Dateien bezieht, einen Verzeichniskontext, den Dateien namens .htaccess festlegen (siehe [1]). Hier eingetragene Konfigurationsdirektiven wirken sich nur auf Dateien in und unterhalb des Verzeichnisses aus, in dem .htaccess liegt.
Einige der Beispiele funktionieren nur im serverglobalen Kontext, die meisten sind aber für den Verzeichniskontext formuliert. Die Ausgangssituation ist folgende: .htaccess befindet sich auf dem Web-Server www.quux-corp.com im physikalischen Verzeichnis /home/quux/.www/, das über den URL /~quux/ erreichbar ist.
Häufiger Anwendungsfall für eine URL-Manipulation ist sicherlich, daß Dateien oder Verzeichnisse umbenannt wurden, die Seiten aber noch eine gewisse Zeit unter den alten Namen ansprechbar sein sollen. Dazu dient eine Direktive der Art
RewriteRule ^foo\.html$ bar.html
Sie bewirkt, daß alle HTTP-Anfragen an den alten URL /~quux/foo.html intern auf /home/quux/.www/bar.html umgesetzt werden. Der Benutzer sieht den Inhalt der Datei bar.html, die für den Browser noch immer /~quux/foo.html heißt.
Alternativ ist es möglich, die Inhalte über den für den Benutzer sichtbar umgeschriebenen URL anzuzeigen. Die dargestellte Seite bleibt die gleiche, aber der vom Browser angezeigte URL heißt jetzt /~quux/bar.html. Ein solcher HTTP-Redirect war zwar bisher schon über die Datei srm.config des Apache-Servers möglich, allerdings weder für lokale Verweise noch über den Abgleich mit regulären Ausdrücken.
In diesem zweiten Fall liefert der Web-Server nicht sofort den Inhalt aus, sondern verweist den Web-Browser lediglich auf den neuen URL, der von diesem unverzüglich angefordert wird. Vorteil dieses Vorgehens ist, daß ein Benutzer, der die Seite in seine Bookmark-Liste aufnimmt, das bereits unter der neuen Bezeichnung tut. Um dies zu erreichen, ergänzt man die RewriteRule am Ende mit dem R(edirect)-Flag. Das veranlaßt den Web-Server, den neuen URL an den Browser zurückzuliefern.
RewriteRule ^foo\.html$ bar.html [R]
Jedem Browser das Seine
Eine weitere oft gewünschte Anwendung besteht darin, abhängig vom Typ des anfragenden Web-Browsers unterschiedliche Seiten auszuliefern. Das 'Feature-Of-The-Week'-Syndrom der Web-Browser-Hersteller und das hinterherhinkende HTML-Standardisierungsgremium machen eine solche Unterscheidung zunehmend interessant. So kann man Seiten für bestimmte Web-Browser mit den aktuellsten HTML-Tags versehen und anderen gleichzeitig die standardkonforme Version anbieten. Mußte man für diesen Zweck bisher noch ein CGI-Skript schreiben, das anstelle der Default-Seite aufgerufen wurde, veranlassen bei Einsatz des Zusatzmoduls die RewriteRules in Listing 2 den Web-Server dazu, die zum Web-Browser passende Seite herauszusuchen.
Abblocken von Web-Robots
Eine Kombination von RewriteCond- und RewriteRule-Direktiven läßt sich einsetzen, um Web-Robots gezielt von bestimmten Web-Seiten fernzuhalten. Die RewriteCond-Direktive in Verbindung mit dem F(orbidden)-Flag der RewriteRule kann durch das Abblocken von HTTP-Requests dazu beitragen, die durch Robots erzeugte Serverlast beispielsweise bei dynamisch generierten Seiten möglichst gering zu halten.
Um einen 'wildernden' Robot aufzuspüren, der beispielsweise alle Hyperlinks in einem großen, dynamisch generierten Archiv verfolgt, empfiehlt sich ein Blick in das Logfile des Apache-Servers. Werden in kurzen Abständen fast sequentiell alle Hyperlinks verfolgt, deutet das auf einen solchen Robot hin. Ist der Server so konfiguriert, daß er zusätzlich den HTTP-Header 'User-Agent' mitprotokolliert, ist der Robot noch leichter erkennbar (siehe dazu die Dokumentation des Apache-Moduls mod_log_config). Konventionsmäßig erfolgt ein solcher Ausschluß über /robots.txt im Dateibaum des Web-Servers. Nur hält sich ein 'wildernder' Robot eben nicht an diese Konvention.
Listing 3 zeigt einen mod_rewrite-Ansatz, um einen solchen Robot namens 'NameOfBadRobot' abzuwehren. Zunächst wird er über seine IP-Adresse identifiziert. Die zusätzliche Abfrage seines Namens soll gewährleisten, daß der Server nicht auch normale Benutzer, die gegebenenfalls vom selben Rechner aus operieren, ausschließt. Außerdem wird die Anfrage nach der Übersichtsseite zugelassen, damit der Robot diese Seite noch liest und in seinen Index einträgt.
Daten dynamisch spiegeln
Für einen schnelleren Zugriff auf häufig angebotene Web-Seiten gibt es bereits seit längerem sogenannte Proxy-Caches, die lokale Kopien der Seiten vorhalten (siehe [2]).
Alternativ zu solch einem im Hintergrund arbeitenden Proxy kann ein Dynamic Mirror im URL-Namensraum eines Web-Servers explizit genutzt werden. Ein solcher Spiegel empfiehlt sich bei Datenbeständen, die häufig lokal abgefragt werden, sich aber ständig ändern. Ein Beispiel hierfür ist die Übersichtsseite HOTSHEET (http://www.tstimpreso.com/hotsheet/). In diesem Fall ist es sinnvoll, eine dynamische Kopie im Intranet bereitzustellen, die sich bei Bedarf automatisch mit der Originalseite abgleicht:
RewriteRule ^hotsheet/(.*)$
http://www.tstimpreso.com/\
hotsheet/$1 [P]
In gleicher Weise läßt sich ein Dynamic Mirror für eine einzelne HTML-Seite aufsetzen:
RewriteRule ^usa-news\.html$
http://www.quux-corp.com/\
news/index.html [P]
Genutzt wird hierbei das P-Flag der RewriteRule-Direktive, die den Ergebnis-URL direkt über das interne Apache-Proxy-Modul zur weiteren Verarbeitung leitet. Das Proxy-Modul liest die Web-Daten ein, schreibt sie in den persistenten Cache des Apache und liefert sie an den Web-Browser aus, als handele es sich um lokale Daten. Fordert der Browser den URL erneut an, erhält er die Web-Daten aus dem Cache.
Fehlende Daten aus dem Intranet
Der Einsatz von mod_rewrite bietet sich auch dann an, wenn eine Firma auf ihrem Web-Server (www.quux-corp.com) nicht nur die offiziellen Firmendaten anbieten will, sondern auch solche, die eigentlich nur im internen Intranet (www-intranet.quux-corp.com) verfügbar sind, etwa die Homepages der Mitarbeiter. Dazu ist es erforderlich, daß alle auf dem Internet-Web-Server nicht physikalisch zur Verfügung stehenden Daten automatisch aus dem Intranet geholt werden. Selbstverständlich nur unter der Voraussetzung, daß es sich um freigegebene Daten handelt. Dafür gelte im Intranet folgende Konvention: Das Heimatverzeichnis des Mitarbeiters 'quux' ist sowohl im Intranet als auch im Internet über den URL /~quux/ ansprechbar. Allerdings befindet es sich im ersten Fall physikalisch im Verzeichnis /home/quux/.www/, während der Internet-URL auf /home/quux/.www/pub/ verweist, wo die Daten liegen, die außerhalb des Firewall sichtbar sein sollen. Der Vorteil liegt auf der Hand: Der Mitarbeiter kann beide Datenbestände im Intranet ablegen und sie dort sowohl pflegen als auch über den Intranet-Server www-intranet.quux-corp.com unter den URLs /~quux/ und /~quux/pub/ ausprobieren.
Die Schwierigkeit besteht darin, daß die Intranet-Daten auf sicherem Wege durch den Internet-Web-Server abrufbar sein müssen. Dazu konfiguriert man zunächst aus Sicherheitsgründen auf dem Firewall eine Regel wie in Listing 4. Dies ist mit fast allen Arten von Firewalls in ähnlicher Weise realisierbar. Damit ist sichergestellt, daß nur der Web-Server www.quux-corp.com per HTTP Daten aus dem Intranet holen kann. Eine mod_rewrite-Konfiguration auf www.quux-corp.com sorgt dann dafür, daß dieser Web-Server die benötigten Daten auf Anfrage aus den pub-Unterverzeichnissen des Intranet holt (siehe Listing 5).
Web-Cluster durch homogenes URL-Layout
Eines der interessantesten Anwendungsgebiete von URL-Manipulationen war Anlaß für die Entwicklung von mod_rewrite. Das im folgenden vorgestellte Problem galt es für das Intranet der Firma sd&m zu lösen. Ausgangssituation war die Tatsache, daß die via WWW bereitzustellenden Daten auf unterschiedlichen Intranet-Servern lagen und man die Komplexität des Intranet nicht durch zusätzliche NFS-Mounts erhöhen wollte. Ein Web-Server kann aber nur die Daten ausliefern, die er über das Filesystem erreichen kann.
Will man keinen zentralen Web-Server, der viel Plattenplatz benötigt, bleibt nur die Möglichkeit, auf jeder Maschine mit Benutzerseiten jeweils einen weiteren Web-Server zu installieren. Dann ist das Erreichen der Daten gewährleistet und die Web-Belastung im Intranet auf mehrere Maschinen verteilt. Allerdings hat man trotz möglicher Indizes viele getrennte Web-Server und keine einheitliche Sicht auf verteilte Ressourcen. Wünschenswert wäre, die einzelnen Server zu einem sogenannten Web-Cluster zu vereinen und so einen gemeinsamen Namensraum für URLs zu schaffen, über den man auf die Daten zugreifen kann.
Gleichzeitig läßt sich erreichen, daß sich im URL die Konvention für die Pfadnamen der Heimatverzeichnisse widerspiegelt. Im hier geschilderten Fall sind alle Heimatverzeichnisse über /u/user, /g/group und /e/entity erreichbar. Die Web-Daten liegen aus Sicherheitsgründen jeweils eine Ebene tiefer in .www. Das Root-Verzeichnis des Benutzers 'quux' ist also auf dem jeweiligen Server unter /u/quux/.www/ zu finden und soll im Cluster immer über den URL /u/quux/ erreichbar sein.
Um dies zu realisieren, wurden zunächst den zum Cluster gehörigen Web-Servern im Domain Name Service (DNS) die Aliases swwN.sdm.de zugeteilt, wobei 'N' zur Durchnumerierung diente. Beim Ansprechen eines beliebigen Web-Servers über http://swwN.sdm.de/u/quux/ soll eine Weiterleitung auf den physikalischen Web-Server gewährleistet sein. Liegt beispielsweise das Heimatverzeichnis des Benutzers 'quux' auf sww2.sdm.de, muß das dem Server sww1.sdm.de bekannt sein, damit er den neuen URL http://sww2.sdm.de/u/quux/ über einen HTTP-Redirect an den Browser zurückliefern kann. Der Server sww2.sdm.de hingegen muß erkennen, daß quux lokal erreichbar ist, und die Daten direkt ausliefern.
Aus Geschwindigkeitsgründen beziehen die Server ihr Wissen aus vorab erzeugten Tabellen, die auf die Web-Server verteilt sind. Cron-Jobs auf den einzelnen Servern übermitteln jede Stunde die Informationen über die lokal verfügbaren Heimatverzeichnisse via HTTP an einen dedizierten Server des Web-Clusters. Im Gegenzug erhalten sie von diesem die Informationen der anderen Server zur Aktualisierung der eigenen Tabelle zurück. (Die dazu nötigen Perl-Programme enthält die offizielle mod_rewrite-Distribution.) Diese Tabellen haben folgende Form:
foos ww3.sdm.de bar sww1.sdm.de quux sww2.sdm.de baz sww4.sdm.de : :
Zur Einbindung in die serverweite Apache-Konfiguration auf den einzelnen Web-Servern dient der RewriteMap-Mechanismus. Er ordnet jeder Tabelle einen eindeutigen Namen zu, über den sie in den Substitutions-Strings der RewriteRule-Direktiven abfragbar ist:
${NameDerTabelle:Abfrageschlüssel|Defaultwert}
Bedenkt man, daß mod_rewrite bei jedem Auftreten eines Substitutions-URL der Form http://host:port/path versucht, diesen im Falle einer Selbstreferenz auf /path zu reduzieren, ist die Lösung für die Web-Server swwN.sdm.de fast offensichtlich.
Listing 6 ermittelt für jeden URL unterhalb von /u/, /g/ und /e/ den physikalischen Web-Server über den Namen des Users, der Group oder der Entity aus den zugehörigen Tabellen. Anschließend ergänzt das Präfix 'http://physikalischer-Host' den aktuellen URL. Ist 'physikalischer-Host' ein Alias für den lokalen Server, entfernt mod_rewrite das Präfix sofort wieder. Ansonsten führt dieser vollqualifizierte URL implizit zu einem HTTP-Redirect, der den Browser auf den neuen Web-Server 'physikalischer-Host' verweist.
Externe 'URL Rewriting Engines'
Das letzte Anwendungsbeispiel zeigt einen Ausweg aus allen von mod_ rewrite noch nicht unterstützten Problemstellungen. Hierbei übernimmt ein externes Programm die URL-Manipulation, indem es als eine Art dynamische Rewriting Map fungiert. Um zu verhindern, daß ein Benutzer den Apache in eine Endlosschleife manövriert, kann die Deklaration solcher Programme nur in der Serverkonfiguration erfolgen und nicht in den .htaccess-Dateien der Benutzer.
Angenommen, der Benutzer 'quux' benötigt sehr komplizierte URL-Manipulationen für sein Heimatverzeichnis /~quux/. Der Web-Master kann speziell für diesen Benutzer ein Skript, wie es Listing 7 zeigt, einrichten (vorausgesetzt, er hat das Programm vorher überprüft).
Diese Direktiven bewirken, daß beim nächsten Start des Apache map.quux.pl aufgerufen wird und parallel läuft. Über die Standardeingabe schickt der Apache alle URLs unterhalb von /~quux/ an dieses Programm und übernimmt das von dort über die Standardausgabe zurückgelieferte Ergebnis als neuen URL. Anstelle des Perl-Sripts kann ein beliebiges unter Unix ausführbares Programm stehen. Ein einfaches Beispiel für map.quux.pl zeigt Listing 8. In Verbindung mit obiger Konfiguration bewirkt dies bei Einsatz des Netscape Navigator ein Umschreiben des URL /~quux/foo/index.html in /~quux/bar/index.html.
Mächtigkeit hat seinen Preis
Trotz aller Vorteile, die mod_rewrite bietet, soll nicht verschwiegen werden, daß flexible URL-Manipulationen ihren Preis fordern, da die vielen Vergleiche über reguläre Ausrücke CPU-intensiv sind. In der Praxis hat sich allerdings gezeigt, daß bis zu 50 globale RewriteRules auf einer durchschnittlichen SPARCstation 10/61 keinen sichtbaren Einfluß auf die Performance des Web-Servers haben.
Auch sollte man nicht unterschätzen, daß der falsche Einsatz von Regeln leicht zu undurchsichtigen Ergebnis-URLs führen kann. Zur Ursachenforschung bei sochen Problemen läßt sich im Logfile von mod-rewrite jede Veränderung eines URL genau nachvollziehen. Eine Einführung findet sich übrigens auf dem Apache-Server.
ist Informatikstudent an der Technischen Universität München und seit vier Jahren bei der Firma sd&m GmbH & Co KG mit Unix-Systemen und Internet-Diensten betraut.
ist Dipl.-Informatiker und bei der Zeppelin Baumaschinen GmbH als System Engineer beschäftigt.
Literatur
[1] Henning Behme; Web-Indianer; Konfiguration des Apache-HTTP-Daemon; iX 6/96, S. 122 ff.
[2] Rainer Klute; Zwischenstation; Mit dem Proxy-Server Zeit und Geld sparen; iX 2/95, S. 154 ff.
| iX-TRACT |
|