Apache/08/1 Aliase und Weiterleitungen: Unterschied zwischen den Versionen
| Zeile 17: | Zeile 17: | ||
=== 8.1.3 Benutzerverzeichnisse === | === 8.1.3 Benutzerverzeichnisse === | ||
[[Apache2.4/08/1/3 Benutzerverzeichnisse]] | |||
=== 8.1.4 Fehlerbehandlung === | === 8.1.4 Fehlerbehandlung === | ||
Version vom 5. März 2025, 12:06 Uhr
Apache2.4/08/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
8.1.2 mod_rewrite
8.1.3 Benutzerverzeichnisse
Apache2.4/08/1/3 Benutzerverzeichnisse
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
- 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