Beim Apache 1.1.1 und früheren Versionen, war das Verfahren zum Erzeugen von PATH_INFO in der CGI-Umgebung nicht problemlos und konnte in bestimmten Situationen zum Absturz führen. Mit der Apache-Version 1.2 hat sich dieses Verhalten geändert. Das führte zwar in einigen Fällen zu Kompatibilitätsproblemen mit bestimmten herkömmlichen CGI-Anwendungen, die Apache-Version 1.2 ist aber kompatibel zur CGI-Spezifikation 1.1 und CGI-Skripte sind einfach zu anzupassm (siehe unten ).

Der Apache-Server Version 1.1.1 und frühere Versionen implementierten die Umgebungsvariablen PATH_INFO und SCRIPT_NAME über den Dateinamen und nicht mit der URL. Das führte zwar in vielen Fällen zu richtigen Ergebnissen, lagen jedoch umfangreiche Pfadinformationen vor, dann konnte das zu einem fehlerhaften Verhalten führen. Zum Beispiel konnte die Konfigurationsdatei folgende Zeile enthalten:

In diesem Fall ist user.cgi das CGI-Skript und /ralph die CGI zu übergebende Information. Kam bei dieser Konfiguration eine Anfrage nach /cgi-ralph/script/, setzte der Code PATH_INFO auf /ralph/script und SCRIPT_NAME auf /cgi-, wobei letzteres offensichtlich nicht korrekt ist. Unter bestimmten Umständen konnte dies sogar zu einem Server-Absturz führen.

Beim Apache 1.1.1 und früheren Versionen, war das Verfahren zum Erzeugen von PATH_INFO in der CGI-Umgebung nicht problemlos und konnte in bestimmten Situationen zum Absturz führen. Mit der Apache-Version 1.2 hat sich dieses Verhalten geändert. Das führte zwar in einigen Fällen zu Kompatibilitätsproblemen mit bestimmten herkömmlichen CGI-Anwendungen, die Apache-Version 1.2 ist aber kompatibel zur CGI-Spezifikation 1.1 und CGI-Skripte sind einfach zu anzupassm (siehe unten ).

Der Apache-Server Version 1.1.1 und frühere Versionen implementierten die Umgebungsvariablen PATH_INFO und SCRIPT_NAME über den Dateinamen und nicht mit der URL. Das führte zwar in vielen Fällen zu richtigen Ergebnissen, lagen jedoch umfangreiche Pfadinformationen vor, dann konnte das zu einem fehlerhaften Verhalten führen. Zum Beispiel konnte die Konfigurationsdatei folgende Zeile enthalten:

In diesem Fall ist user.cgi das CGI-Skript und /ralph die CGI zu übergebende Information. Kam bei dieser Konfiguration eine Anfrage nach /cgi-ralph/script/, setzte der Code PATH_INFO auf /ralph/script und SCRIPT_NAME auf /cgi-, wobei letzteres offensichtlich nicht korrekt ist. Unter bestimmten Umständen konnte dies sogar zu einem Server-Absturz (Continue reading)

Der Apache-Server unterstützt die Content Negotiation, wie sie in der HTTP/1.1-Spezifikation beschrieben wird. Er kann anhand der vom Browser angegebenen Präferenzen für den Medientyp, die Sprachen, Zeichensatz und Verschlüsselung die beste Darstellungsform für eine Ressource wählen. Außerdem implementiert er eine Reihe von Eigenschaften für ein intelligenteres Handling bei Browser-Anfragen mit unvollständigen Angaben zum Inhaltstyp.

Für die Content Negotiation ist das standardmäßig kompilierte Modul mod_negotiation zuständig.

Eine Ressource kann in unterschiedlichen Darstellungsarten vorliegen, beispielsweise in unterschiedlichen Sprache und/oder verschiedenen Medientypen. Damit die entsprechende Auswahl getroffen werden kann, kann dem Benutzer eine Indexseite mit den Optionen angezeigt werden. Häufig kann der Server die Auswahl aber auch automatisch treffen. Das ist möglich, weil der Browser mit seiner Anfrage Header zur bevorzugten Darstellungsform senden kann. So kann der Browser beispielsweise angeben, dass er die Informationen am liebsten in Französisch oder falls das nicht möglich ist, auf Englisch angezeigt bekommen möchte. Mit folgendem Header kann der Browser französische Dokumente anfordern:

Diese Präferenzen werden nur berücksichtigt, wenn eine Auswahl in unterschiedlichen Sprachen vorhanden ist.

Um ein etwas ausführlicheres Beispiel zu zeigen, wurde der Browser im folgenden so konfiguriert, dass er Französisch und Englisch akzeptiert. Ferner akzeptiert er unterschiedliche Medientypen, wobei er HTML gegenüber einfachem Text oder anderen Textformaten vorzieht. Außerdem zieht er die Formate (Continue reading)

Um einen Webserver effektiv verwalten zu können, ist die Aufzeichnung der Aktivitäten und Leistungsmerkmale des Servers sowie der aufgetretenen Probleme erforderlich. Der Apache-Server bietet hierfür umfangreiche und flexible Möglichkeiten. Im folgenden wird beschrieben, wie die Protokollierung konfiguriert wird und was die Aufzeichnungen enthalten.

Jeder, der in dem Verzeichnis Schreibrechte besitzt, in das der Apache die Protokolldateien schreibt, kann Zugriff auf die uid (in der Regel root) erhalten, unter der der Server gestartet wurde. Seien Sie sich deshalb über die Konsequenzen im Klaren, wenn sie jemandem Schreibrechte für das Verzeichnis gewähren, in welchem der Server die Protokolldateien speichert. Weitere Einzelheiten finden Sie unter den Sicherheitstipps.

Darüber hinaus können Protokolldateien direkt vom Client übergebene Informationen enthalten. Böswillige Clients können daher Steuerzeichen in Protokolldateien schreiben, so dass Vorsicht beim Umgang mit den Rohdaten geboten ist.

Das Fehlerprotokoll des Servers, dessen Name und Verzeichnis mit der ErrorLog-Direktive setzt werden, ist die wichtigste Protokolldatei. In diese Datei schreibt der Apache bei der Bearbeitung der Anfragen Fehlermeldungen und Diagnosen. An dieser Stelle muss als erstes gesucht werden, wenn beim Serverstart oder Betrieb Probleme auftreten, weil sich hier oft Details finden, die zeigen, wo der Fehler liegt und wie er behoben werden kann.

Das Fehlerprotokoll wird in der Regel in eine Datei geschrieben (unter Unix normalerweise in die Datei error_log und unter Windows und OS/2 in die Datei error.log). Unter Unix kann der Server die Fehler auch (Continue reading)

Dank des suEXEC-Wrappers können Apache-Benutzer CGI- und SSI-Programme unter anderen IDs als der des aufrufenden Webservers ausführen. Normalerweise werden CGI- oder SSI-Programme unter der User-ID des Webservers ausgeführt.

Der korrekte Einsatz dieser Möglichkeit kann die Sicherheitsrisiken beträchtlich vermindern, die sich daraus ergeben können, dass Benutzern die Entwicklung und Ausführung eigener CGI- oder SSI-Programme erlaubt wird. Bei einer fehlerhaften Konfiguration können sich jedoch viele Probleme ergeben und größere Sicherheitslücken auftreten. Wenn Sie keine Erfahrung mit setuid root-Programmen und den damit verbundenen Sicherheitsrisiken haben, wird von der Verwendung von suEXEC dringend abgeraten.

Vorab sind noch einige generelle Anmerkungen notwendig.

Es wird vorausgesetzt, dass Sie ein UNIX-Betriebssystem benutzen, dass setuid- und setgid-Operationen durchführen kann. Davon wird in allen Beispielen ausgegangen. Andere Betriebssysteme, die suEXEC unterstützen, können in der Konfiguration abweichen.

Zum zweiten wird davon ausgegangen, dass Sie mit den Grundkonzepten der Computersicherheit und der Administration vertraut sind. Hierzu gehören die setuid/setgid-Operationen sowie die unterschiedlichen Effekte, die sie auf Ihrem System und für Ihre Sicherheitsstufe auslösen können.

Zum Dritten wird davon ausgegangen, dass Sie eine unveränderte Version des suEXEC-Code benutzen. Der gesamte suEXEC-Code wurde sowohl von den Entwicklern als auch (Continue reading)

Die Direktiven in den Konfigurationsdateien können sich auf den gesamten Server oder nur auf bestimmte Verzeichnisse, Dateien, Hosts oder URLs beziehen. In den folgenden Abschnitten wird beschrieben, wie mit den Containern der Konfigurationsabschnitte oder .htaccess-Dateien der Bereich anderer Konfigurationsdirektiven geändert wird.

Es gibt zwei Grundtypen von Containern. Die meisten von ihnen werden für jede Anfrage ausgewertet. Die enthaltenen Direktiven werden nur für die Anfragen angewendet, für die der Containern zuständig ist. Die Container IfDefine und IfModule werden dagegen nur beim Serverstart und beim Neustart ausgewertet. Sind ihre Bedingungen beim Start erfüllt, werden die enthaltenen Direktiven für alle Anfragen angewendet. Werden sie nicht erfüllt, werden sie ignoriert.

Die IfDefine-Direktive enthält Direktiven, die nur angewendet werden, wenn ein entsprechender Parameter in der httpd-Befehlszeile angegeben wird. Bei der folgenden Konfiguration werden beispielsweise alle Anfragen nur dann zu einer anderen Site umgeleitet, wenn der Server mit den Befehl httpd -DClosedForNow gestartet wird:

Bei der Direktive IfModule werden die enthaltenen Direktiven nur angewendet, wenn ein bestimmtes Modul für den Server geladen wurde. Das Modul muss statisch oder dynamisch kompiliert sein und die Zeile mit der LoadModule-Direktive muss in der (Continue reading)