Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort des Fachgutachters
Vorwort
1 Einführung
2 Mathematische und technische Grundlagen
3 Hardware
4 Netzwerkgrundlagen
5 Betriebssystemgrundlagen
6 Windows
7 Linux
8 Mac OS X
9 Grundlagen der Programmierung
10 Konzepte der Programmierung
11 Software-Engineering
12 Datenbanken
13 Server für Webanwendungen
14 Weitere Internet-Serverdienste
15 XML
16 Weitere Datei- und Datenformate
17 Webseitenerstellung mit (X)HTML und CSS
18 Webserveranwendungen
19 JavaScript und Ajax
20 Computer- und Netzwerksicherheit
A Glossar
B Zweisprachige Wortliste
C Kommentiertes Literatur- und Linkverzeichnis
Stichwort

Download:
- ZIP, ca. 26,3 MB
Buch bestellen
Ihre Meinung?

Spacer
IT-Handbuch für Fachinformatiker von Sascha Kersken
Der Ausbildungsbegleiter
Buch: IT-Handbuch für Fachinformatiker

IT-Handbuch für Fachinformatiker
Galileo Computing
ca. 1172 S., 5., aktualisierte und erweiterte Auflage, geb.
ca. 34,90 Euro, ISBN 978-3-8362-1744-6
Pfeil 13 Server für Webanwendungen
Pfeil 13.1 HTTP im Überblick
Pfeil 13.1.1 Ablauf der HTTP-Kommunikation
Pfeil 13.1.2 HTTP-Statuscodes
Pfeil 13.1.3 HTTP-Header
Pfeil 13.2 Der Webserver Apache
Pfeil 13.2.1 Apache im Überblick
Pfeil 13.2.2 Apache-Module
Pfeil 13.2.3 Apache installieren
Pfeil 13.2.4 Apache-Konfiguration
Pfeil 13.3 PHP installieren und einrichten
Pfeil 13.3.1 Installation
Pfeil 13.3.2 Die PHP-Konfigurationsdatei php.ini
Pfeil 13.4 Zusammenfassung

Galileo Computing - Zum Seitenanfang

13.2 Der Webserver ApacheZur nächsten Überschrift

Der Apache HTTP Server (kurz Apache) ist die mit Abstand verbreitetste Webserver-Software mit einem Marktanteil von 60 bis 70 %. Er entstand ab 1995, zunächst als Weiterentwicklung des NCSA-Webservers durch Detailverbesserungen (Patches), so dass der Name oft als »a patchy web server« erklärt wird. Um seine Entwickler bildete sich die Apache Software Foundation, die neben dem Webserver auch zahlreiche andere bekannte Open-Source-Programme beheimatet, beispielsweise den Spamfilter SpamAssassin, die Java-Servlet-Engine Tomcat (nebenbei ebenfalls ein Webserver) oder den XSLT-Prozessor Xalan (siehe Kapitel 15, »XML«).

Apache ist stabil, sicher und läuft auf den verschiedensten Plattformen. Ein Großteil seiner Funktionalität wird durch Module bereitgestellt. So kann er leicht durch Drittanbieter oder gar eigene Programmierung erweitert werden; außerdem können Sie nicht benötigte Teile deaktivieren, so dass sie nicht unnötig Ressourcen verschwenden.


Galileo Computing - Zum Seitenanfang

13.2.1 Apache im ÜberblickZur nächsten ÜberschriftZur vorigen Überschrift

Es gibt insgesamt drei verschiedene Apache-Entwicklungszweige. Neue Features werden zwar nur noch für den aktuell stabilen Zweig 2.2.x sowie die Betaversion 2.3.x (die als stabile Release 2.4 heißen wird) implementiert, aber es gibt bei Bedarf noch Bugfixes für den 2.0-Zweig. Tabelle 13.4 zeigt die drei Versionen im Überblick.

Tabelle 13.4 Die verschiedenen Apache-Versionszweige

Versionszweig aktuelles Release Eigenschaften
2.0.x 2.0.64

Neuentwicklung, inkompatibel mit den alten 1.x-Versionen Netzwerk- und andere Systemfunktionen werden jeweils plattformoptimiert durch die Abstraktionsschicht Apache Portable Runtime (APR) bereitgestellt. Module dynamisch ladbar verschiedene Laufzeitverhalten durch Multi-Processing-Module (MPM)

2.2.x 2.2.19 Detailverbesserungen gegenüber Version 2.0.x, z. B.: Neuordnung der Authentifizierungsmodule eingebaute Datenbankschnittstelle
2.3.x 2.3.12-beta

Vorschau des nächsten Versionszweigs, für den Produktiveinsatz nur bedingt geeignet Final Release wird 2.4.x heißen. Auch MPM sind nun dynamisch ladbar. Neuordnung der Autorisierungsmodule (Zugriffskontrolle)

Im Folgenden wird vorwiegend die aktuelle, stabile Version 2.2 besprochen, mit ein paar Hinweisen auf den kommenden Entwicklungszweig 2.4. Die in der Tabelle bereits kurz angedeuteten Eigenschaften von Apache 2 sind:

  • Abstraktionsbibliothek APR
    Bis zur Version 1.3.x verwendete Apache die auf Unix-Systemen üblichen POSIX-Systemaufrufe zur Verwaltung von Netzwerkverbindungen, Speicher, Dateizugriffen und so weiter. Auf Nicht-Unix-Systemen kam deshalb eine POSIX-Emulationsschicht zum Einsatz, die Apache auf diesen Plattformen allerdings langsamer und weniger stabil machte. Deshalb wurden solche systemnahen Funktionen für die neue Version 2 in die Abstraktionsbibliothek Apache Portable Runtime (APR) ausgelagert, die sie für jedes System nach dessen besten Möglichkeiten bereitstellt. Inzwischen wird die APR daher auch als Grundlage anderer Software eingesetzt.
  • Unterschiedliche Laufzeitmodelle durch MPM
    Ein Netzwerkserver muss in der Lage sein, mehrere Clientanfragen gleichzeitig zu beantworten. Dafür gibt es je nach System unterschiedliche Prozess- oder Thread-Verfahren (siehe den Abschnitt »Netzwerkprogrammierung« in Kapitel 10, »Konzepte der Programmierung«). Apache 1.x verwendete ausschließlich ein Preforking-Modell, das heißt, er erzeugte einige Child-Prozesse auf Vorrat. Apache 2 ermöglicht dagegen die Auswahl verschiedener sogenannter Multi-Processing-Module (MPM), die auf Prozessen, Threads oder einer Mischung aus beiden basieren, so dass für jedes System die vorteilhafteste Auswahl getroffen werden kann.

In der neuen Version 2.3-beta sind die MPM sogar dynamisch zur Laufzeit ladbar, genau wie alle anderen Module.

  • Dynamische Module
    Die bereits in der Einleitung erwähnten Apache-Module mussten früher statisch einkompiliert werden. Apache musste also für jeden Wechsel der Modulauswahl ganz neu kompiliert werden. In Apache 2 besteht dagegen die Möglichkeit, Module als Dynamic Shared Objects (DSO) zu kompilieren und über die Konfigurationsdatei ein- oder auszuschalten. Somit braucht der Server nur neu gestartet zu werden, wenn Sie neue Module hinzufügen oder vorhandene entfernen möchten.
  • Eingebaute SSL-Unterstützung
    Sicherheitsbedürftige Webanwendungen wie E-Commerce oder gar Homebanking benötigen gesicherte Verbindungen, die die Identität des Servers und die Integrität der Daten garantieren sowie die Kommunikation verschlüsseln. Die Lösung für diese Anforderung ist HTTP über SSL, kurz HTTPS. Bis Apache 1.3 gab es dafür diverse Erweiterungen, teilweise von Drittanbietern. Apache 2 ist dagegen ab Werk mit dem Modul mod_ssl ausgestattet, das die SSL-Funktionalität nahtlos integriert.

Galileo Computing - Zum Seitenanfang

13.2.2 Apache-ModuleZur nächsten ÜberschriftZur vorigen Überschrift

Zum Lieferumfang von Apache gehören gut 70 verschiedene Module. Daneben gibt es unzählige Erweiterungen von unabhängigen Anbietern, sowohl als Open Source als auch kommerziell. Die meisten dieser Zusatzmodule werden auf der Site http://modules.apache.org/ erwähnt und verlinkt.

Tabelle 13.5 enthält eine Übersicht über die wichtigsten mitgelieferten Module. Die Spalte »aktiv« informiert darüber, ob das jeweilige Modul in einer Standardinstallation von Apache automatisch mitinstalliert und aktiviert wird oder nicht.

Tabelle 13.5 Die wichtigsten Module in Apache 2.2

Modul aktiv Beschreibung
mod_authz_host ja Zugriffsschutz anhand von Client-Hostnamen und/oder -IP-Adressen
mod_alias ja Einbinden externer Verzeichnisse in den URL-Namensraum der Website; interne und externe Weiterleitungen
mod_auth_basic ja Grundmodul zur Authentifizierung, das die Anmeldedaten vom Client (klartextbasiert) entgegennimmt und anschließend mit Hilfe verschiedener Provider-Module auf ihre Gültigkeit überprüft
mod_auth_digest nein wie mod_auth_basic, allerdings MD5-verschlüsselt
mod_authn_dbd nein Authentifizierungs-Provider-Modul, das eine SQL-Abfrage an eine externe Datenbank sendet, um die Anmeldedaten zu überprüfen
mod_authn_dbm nein Authentifizierungs-Provider; verwendet datenbankähnliche DBM-Dateien.
mod_authn_file ja Authentifizierungs-Provider; verwendet einfache Textdateien.
mod_authnz_ldap nein Authentifizierungs-Provider; befragt ein externes LDAP-Verzeichnis.
mod_authz_dbm nein Vergleicht Gruppenzugehörigkeiten mit Hilfe von DBM-Dateien.
mod_authz_groupfile ja Vergleicht Gruppenzugehörigkeiten mit Hilfe einfacher Textdateien.
mod_autoindex ja automatisch generierte Verzeichnisindizes für Verzeichnisse ohne Startseite
mod_cgi ja Unterstützung für CGI-Skripte, das heißt externe Programme oder interpretierte Skripte als Webanwendungen
mod_dbd nein Integrierte Datenbankschnittstelle; wird u. a. für mod_authn_dbd benötigt.
mod_dir ja Definition des Startseitennamens sowie Verarbeitung von Anfragen, die ein Verzeichnis statt einer Datei anfordern
mod_env ja Setzen und Ändern von Server-Umgebungsvariablen
mod_headers nein Manipulation der Anfrage- und Antwort-Header
mod_imagemap ja Unterstützung serverseitiger Image Maps, d. h. Bilder mit verschiedenen anklickbaren Bereichen
mod_include ja Server Side Includes, eine der ältesten Technologien zum Einbinden dynamischer Daten in Webseiten
mod_ldap nein erweiterte LDAP-Verbindungsoptionen (z. B. Caching) für LDAP-basierte Module wie mod_authnz_ldap
mod_log_config ja Formatierung von Server-Log-Dateien mit Hilfe zahlreicher Platzhalter
mod_mime ja Setzt Entity-Header wie Content-Type inklusive Zeichensatz anhand der Dateiendung(en) einer Ressource.
mod_mime_magic nein Ermittelt den MIME-Type aufgrund des Datei-Inhalts, wie das Unix-Kommando file.
mod_negotiation ja Content-Negotiation, d. h. Lieferung verschiedener Varianten einer Ressource anhand der Accept*-Anfrage-Header
mod_rewrite nein beliebige URL-Manipulationen auf der Basis regulärer Ausdrücke
mod_setenvif ja Setzen und Ändern von Server-Umgebungsvariablen je nach den Werten bestimmter Anfrage-Header
mod_ssl nein gesicherte HTTPS-Verbindungen
mod_userdir ja Ermöglicht persönliche Websites für die Benutzerkonten des Servers unter http://servername/~username.

Galileo Computing - Zum Seitenanfang

13.2.3 Apache installierenZur nächsten ÜberschriftZur vorigen Überschrift

Wenn Sie eine Unix-Variante verwenden, können Sie zunächst überprüfen, ob Apache zum Lieferumfang Ihrer Distribution gehört – dies wird meist der Fall sein. Falls Sie aber mehr Kontrolle über den Installationsumfang ausüben möchten oder die aktuellste Version brauchen, sollten Sie Apache mit Hilfe des offiziellen Sourcecode-Pakets selbst kompilieren. Für Windows liefert die Apache Software Foundation dagegen einen offiziellen Binär-Installer.

Installation auf Unix-Systemen

Laden Sie zunächst das neueste Release von Apache 2.2 (Anfang Juli 2011: 2.2.19) von http://httpd.apache.org/ herunter. Falls die endgültige Version 2.4 bereits erschienen ist, wenn Sie dies lesen, sollten Sie stattdessen diese wählen. Die Download-Site wählt automatisch einen nahegelegenen Mirror, so dass Sie nach dem Download die Integrität des Pakets überprüfen sollten. Dazu müssen Sie die MD5-Prüfsumme der heruntergeladenen Datei ermitteln und mit dem Wert auf der Apache-Website vergleichen. Geben Sie dazu beispielsweise dieses Kommando ein:

$ md5sum httpd-2.2.19.tar.gz

Unter Mac OS X heißt das Kommando md5 statt md5sum.

Als Nächstes können Sie das Paket auspacken. Geben Sie für die .tar.gz-Variante Folgendes ein:

$ tar xzvf httpd-2.2.19.tar.gz

Haben Sie dagegen ein .tar.bz2-Archiv heruntergeladen, so lautet die Eingabe:

$ tar xjvf httpd-2.2.19.tar.bz2

Nun müssen Sie in das neu erstellte Verzeichnis wechseln:

$ cd httpd-2.2.19

Der erste Schritt besteht darin, das Skript configure auszuführen, das die Makefiles an Ihr System und mit Hilfe von Kommandozeilenparametern an Ihre Wünsche anpasst. Eine vollständige Liste aller verfügbaren Optionen erhalten Sie durch Eingabe von:

$ ./configure --help |less

Hier einige der wichtigsten Optionen im Überblick:

  • --prefix=/Verzeichnispfad
    Übergeordnetes Verzeichnis, in das Apache installiert wird (Standard /usr/local/apache2)
  • --enable-layout=Layoutname
    Auswahl eines benannten Verzeichnislayouts aus der Datei layout.config; kann als Ersatz für oder zusätzlich zu --prefix angegeben werden.
  • --with-mpm=MPM-Modul
    Auswahl des passenden MPM – die wichtigsten sind prefork (rein prozessbasiert, Standard) und worker (gemischtes Prozess-/Thread-Modell). worker arbeitet auf Plattformen mit guter Thread-Unterstützung etwas speicherschonender, sollte aber nicht mit Drittanbietermodulen wie PHP eingesetzt werden.
  • --enable-so
    Aktiviert die grundsätzliche Unterstützung für Module als Dynamic Shared Objects; inzwischen ist diese Option Standard.
  • --enable-modules="modul1 modul2 ..."
    Kompiliert die angegebenen Module (ohne das Präfix mod_) statisch ein.
  • --enable-mods-shared="modul1 modul2 ..."
    Kompiliert die angegebenen Module als Shared Objects.
  • --enable-modules=most
    Kompiliert fast alle Module (außer die experimentellen sowie diejenigen, die Schwierigkeiten bereiten würden) statisch ein.
  • enable-mods-shared=most
    Kompiliert fast alle Module als Shared Objects.
  • --disable-modules="modul1 modul2 ..."
    Lässt die angegebenen Module explizit weg.

Das folgende Kommando bereitet Apache zur Installation ins Standardverzeichnis /usr/ local/apache2 sowie zur Kompilierung fast aller Module als DSOs vor:

$ ./configure --enable-layout=Apache \
--enable-mods-shared=most

Danach müssen Sie die beiden folgenden Kommandos eingeben, um die eigentliche Kompilierung sowie die Installation in das Zielverzeichnis durchzuführen:

$ make
# make install

Mindestens den letzten Schritt müssen Sie als User root ausführen, da ein normaler User nicht in Verzeichnisse wie /usr/local schreiben darf.

Nach der Installation können Sie Apache starten und anderweitig steuern. Dazu dient das Skript apachectl im Unterverzeichnis bin. Es besitzt u. a. folgende Aufrufoptionen:

  • apachectl start
    Apache starten
  • apachectl stop
    Apache beenden
  • apachectl graceful-stop
    Apache beenden, aber erst nach Bearbeitung aller laufenden Clientanfragen (seit Version 2.2 verfügbar)
  • apachectl restart
    Apache neu starten – wichtig nach Konfigurationsänderungen
  • apachectl graceful
    Apache nach Fertigstellung der aktuellen Anfragen neu starten; manche Änderungen benötigen allerdings einen »richtigen« Neustart.

Im Übrigen eignet sich apachectl auch als Startskript, das den automatischen Start von Apache beim Booten ermöglicht. Einzelheiten dazu finden Sie in Kapitel 7, »Linux«. Auf den meisten Linux-Systemen genügt es, einen Symlink auf apachectl in /etc/init.d abzulegen und diesen anschließend per chkconfig -a zu aktivieren. Beispiel:

# ln -s /usr/local/apache2/bin/apachectl \
/etc/init.d/apache2
# chkconfig -a apache2

Installation unter Windows

Laden Sie den Apache-Installer (zurzeit httpd-2.2.19-win32-x86-openssl-0.9.8r.msi) von http://httpd.apache.org/ herunter.[55] Doppelklicken Sie danach auf das Icon des Installers.

Befolgen Sie danach in jedem Fall die Installationsanweisungen. Der Dialog besteht aus den folgenden Seiten, auf denen Sie jeweils Next anklicken müssen, um fortzufahren:

  1. kurze Information, dass Apache 2 installiert wird
  2. Anzeige der Apache-Lizenz – eine typische Open-Source-Lizenz, die sowohl die freie Verwendung als auch die beliebige Veränderung des Webservers gestattet. Wählen Sie die Option I accept the terms in the license agreement.
  3. Informationstext über Apache 2 und Hinweise zu weiteren Informationsquellen
  4. Voreinstellungen einiger Konfigurationsdaten: Geben Sie unter Network Domain Ihren Domainnamen ein, etwa »test.local« für einen nicht-öffentlichen Testserver. Als Server Name müssen Sie den DNS-Namen des Servers selbst angeben, zum Beispiel »www.test.local«. Die Administrator’s E-Mail Address ermöglicht Benutzern den Versand einer Mitteilung über Serverfehler, da sie auf automatisch generierten Fehlermeldungsseiten angezeigt wird; üblich ist die Adresse webmaster@<Domain>. Auch für einen lokalen Test sollten Sie Apache als vollwertigen Produktionsserver (For All Users, on Port 80, as a Service) installieren.[56]
  5. Wenn Sie Typical wählen, werden nur gängige Komponenten installiert. Custom ermöglicht dagegen die freie Auswahl, was zu bevorzugen ist.
  6. Wenn Sie Custom ausgewählt haben, wird nun eine Baumansicht mit den möglichen Komponenten der Installation angezeigt. In der Regel können Sie einfach die Wurzel anklicken und die Option This Feature, and all subfeatures, will be installed on local hard drive einstellen; dies erfordert knapp 50 MByte Festplattenspeicher. Am unteren Rand wird das Verzeichnis gewählt; der Vorgabewert ist Apache Software Foundation im Verzeichnis Program Files oder Programme.
  7. Wenn Sie doch noch etwas ändern möchten, können Sie nun auf Back klicken; andernfalls beginnt ein Klick auf Install mit der eigentlichen Installation.

Wenn Sie Apache als Dienst installiert haben (siehe Punkt 4), startet er automatisch. Zur Verwaltung des Dienstes können Sie den mitinstallierten Apache Service Monitor verwenden, der im Systray als kleines Feder-Symbol angezeigt wird. Mit der rechten Maustaste können Sie dieses Programm öffnen und Apache 2 steuern.


Galileo Computing - Zum Seitenanfang

13.2.4 Apache-KonfigurationZur nächsten ÜberschriftZur vorigen Überschrift

Einstellungen für den Apache-Webserver werden in diversen Konfigurationsdateien vorgenommen. Bei Apache 2.0 befanden sich alle Einstellungen in der zentralen Datei httpd.conf, die standardmäßig unter /usr/local/apache2/conf (Unix) oder C:\Program Files\Apache Software Foundation\Apache2.2\conf (Windows) liegt.

In Apache 2.2 wurden einige Einstellungen dagegen in separate Dateien im Unterverzeichnis extra ausgelagert. Um sie zu aktivieren, müssen Sie das Kommentarzeichen (#) vor der jeweiligen Include-Direktive in der Konfigurationsdatei httpd.conf entfernen. Im Einzelnen handelt es sich um folgende Dateien:

  • httpd-mpm.conf – Einstellungen für das jeweilige MPM, deren Änderung je nach Serverlast die Performance verbessern kann
  • httpd-multilang-errordoc.conf – Fehlermeldungsseiten in unterschiedlichen Sprachen
  • httpd-autoindex.conf – Einstellungen für automatisch generierte Verzeichnisseiten
  • httpd-languages.conf – Zuordnung zusätzlicher Dateiendungen zu Inhaltssprachen für Content-Negotiation
  • httpd-userdir.conf – Benutzerspezifische Webverzeichnisse (http://servername/~username)
  • httpd-info.conf – Veröffentlichung von Serverinformationen unter einer speziellen URL
  • httpd-vhosts.conf – Konfiguration virtueller Hosts, das heißt verschiedener Websites für unterschiedliche Hostnamen oder IP-Adressen
  • httpd-manual.conf – Veröffentlichung der Apache-Dokumentation unter dem URL-Pfad /manual
  • httpd-dav.conf – Einstellungen für WebDAV (Web-based Distributed Authoring and Versioning), ein HTTP-basiertes Repository
  • httpd-default.conf – optionale Standardeinstellungen für den Server
  • httpd-ssl.conf – SSL-Konfiguration

Der mit Ihrer Distribution gelieferte Apache verwendet oft eine andere Dateiaufteilung. Mitunter hilft es dann auch nichts, diese Dateien direkt zu editieren, da ihr Inhalt durch distributionseigene Tools oder Konfigurationsdateien bestimmt wird.

Jede Apache-Konfigurationseinstellung (Direktive) hat das folgende Format:

Direktive Wert [Wert ...]

Außerdem existieren Container-Direktiven wie etwa <Directory> ... </Directory>, die die Wirkung der enthaltenen Apache-Direktiven auf bestimmte Verzeichnisse, Dateien oder andere Spezialwerte beschränken.

Wichtige Konfigurationsdirektiven

Es folgt eine Beschreibung der wichtigsten Apache-Direktiven. Für jede von ihnen wird das Modul mitgeteilt, das sie bereitstellt; core ist dabei kein Modul, sondern der immer verfügbare Funktionskern des Servers. Zudem erfahren Sie durch eine oder mehrere der nachfolgenden Abkürzungen diejenigen Kontexte, in denen eine Direktive stehen darf:

  • SServerkontext
    Diese Direktive gilt serverweit.
  • Vvirtueller Host
    Die Direktive kann in einem <VirtualHost>-Container stehen und gilt dann nur für den betreffenden virtuellen Host.
  • DVerzeichnis-Kontext
    Die Direktive gilt für einen Verzeichnisbereich und darf sich in einem <Directory>-, <Location>- oder <Files>-Container befinden.
  • H.htaccess-Dateien
    Die Direktive darf in einer .htaccess-Datei stehen, über die Sie Konfigurationsdaten in die einzelnen Verzeichnisse der Website selbst auslagern können. .htaccess-Dateien werden nur benötigt, falls Sie bei einem Hoster Webspace angemietet haben oder umgekehrt virtuelle Hosts für andere User zur Verfügung stellen. Auf Ihrem eigenen Server sollten Sie dagegen alle Direktiven in die Datei httpd.conf beziehungsweise die mit ihr verknüpften Konfigurationsdateien schreiben.

Ausführlichere Informationen zu diesen Direktiven sowie zu allen anderen finden Sie in der Apache-Originaldokumentation (http://httpd.apache.org/docs-2.2) sowie in meinem Buch »Apache 2« (4. Auflage, Bonn 2011, Galileo Press). Zu diesem Buch gibt es auch eine Website mit einer umfangreichen Direktivenliste (http://buecher.lingoworld.de/apache2/dirs.php).

Die Werte mancher Direktiven sind Pfadangaben. Auch unter Windows müssen Sie in diesem Fall den Unix-Slash (/) als Pfadtrennzeichen verwenden. Falls Pfadangaben oder andere Werte Leerzeichen enthalten, müssen Sie sie in Anführungszeichen setzen.

  • Alias URL-Pfad Verzeichnispfad

Kontext: SV; Modul: mod_alias

Ein Verzeichnispfad, der sich außerhalb der DocumentRoot (siehe unten) befindet, wird an der angegebenen Stelle in den URL-Pfad eingebunden. Beispiel:

Alias /info /var/webdata/info

Die Eingabe von »http://servername/info/...« liefert daraufhin die entsprechenden Inhalte aus dem Verzeichnis /var/webdata/info.

  • Allow from all | IP-Adresse | Hostname

Kontext: DH; Modul: mod_authtz_host

Gibt Hosts an, denen der Zugriff auf eine bestimmte Ressource erlaubt wird. Als Wert hinter Allow from können Hostnamen, ganze IP-Adressen oder Teile von ihnen eingetragen werden; alternativ auch das Schlüsselwort all für jeden Host.

Das folgende Beispiel erlaubt allen Hosts den Zugriff auf URLs unter http://servername/public:

<Location /public>
Order allow,deny
Allow from all
</Location>

In Apache 2.4 wird diese Syntax zwar noch unterstützt, gilt aber als veraltet. Hier wird sie von dem Modul mod_access_compat bereitgestellt, während mod_authz_host keine eigenen Direktiven mehr definiert, sondern Require ip für IP-Adressen beziehungsweise Require host für Hostnamen verwendet.

  • AllowOverride None|All|Direktiventyp [Direktiventyp ...]

Kontext: D; Modul: core

Legt fest, welche Direktiven im aktuellen Kontext und seinen Unterverzeichnissen durch .htaccess-Dateien überschrieben werden dürfen. Diese Direktive ist nur in <Directory>-Abschnitten erlaubt, nicht in <Location> oder <Files>. Eine Voreinstellung für alle Verzeichnisse kann in einem Container für das Wurzelverzeichnis, also

<Directory />
...
</Directory>

vorgenommen werden.

Die möglichen Werte sind:

  • None: Apache wertet im angegebenen Kontext keine .htaccess-Dateien aus; empfiehlt sich als Vorgabewert für /.
  • FileInfo: Direktiven für Dateitypen und -inhalte
  • Indexes: Direktiven für automatisch generierte Verzeichnisindizes
  • Limit: Direktiven zur Zugriffskontrolle, insbesondere Order, Allow und Deny
  • AuthConfig: Direktiven zur Authentifizierung
  • Options: Direktiven für Verzeichnisoptionen, z. B. Options
  • All: alle bisher genannten sowie einige zusätzliche Direktiven
  • AuthBasicProvider provider

Kontext: DH; Modul: mod_auth_basic

Gibt das Provider-Modul (mod_authn_*) an, das die Vergleichsdaten für die klartextbasierte Authentifizierung liefern soll. Hier ein Beispiel, das einfache Textdateien (Modul mod_authn_file) auswählt:

AuthBasicProvider file
  • AuthDigestProvider provider

Kontext: DH; Modul: mod_auth_digest

Wie AuthBasicProvider, allerdings für die verschlüsselte Digest-Authentifizierung

  • AuthName Bereichsname

Kontext: DH; Modul: core

Bestimmt den Namen eines Authentifizierungsbereiches, den sogenannten Realm. Nach einmaliger erfolgreicher Anmeldung senden Browser die Anmeldedaten für denselben Realm innerhalb einer Sitzung automatisch. Außerdem zeigen Browser den Realm im Anmeldefenster an. Beispiel:

AuthName "Privater Bereich"
  • AuthType Basic | Digest

Kontext: DH; Modul: core

Legt fest, auf welche Weise ein Browser die Anmeldedaten an den Server senden soll: Basic steht für Klartext, Digest dagegen für MD5-Verschlüsselung. Letzteres ist natürlich sicherer, funktioniert aber nicht mit allen Provider-Modulen und bereitet sehr alten Browsern Schwierigkeiten.

  • AuthUserFile Dateipfad

Kontext: DH; Modul: mod_authn_file

Gibt eine Textdatei an, in der sich Benutzerdaten zur Überprüfung bei der Anmeldung befinden. Für die Erzeugung solcher Dateien ist das im bin-Verzeichnis von Apache befindliche Kommandozeilentool htpasswd zuständig. Beispiel:

# htpasswd [-c] .htuser username

Nach dieser Eingabe wird zweimal nach dem neuen Passwort für den angegebenen Usernamen gefragt; daraufhin wird es verschlüsselt in der Datei .htuser im aktuellen Verzeichnis gespeichert. Die Option -c (»create«) muss zum Anlegen einer neuen Datei verwendet werden.

In der Direktive wird der Dateipfad relativ zur ServerRoot (siehe unten) interpretiert, es sei denn, Sie geben einen absoluten Pfad an. Hier ein Beispiel, das die Datei .htuser aus dem Verzeichnis credentials im Apache-Installationsverzeichnis auswählt:

AuthUserFile credentials/.htuser

Aus Sicherheitsgründen sollte die angegebene Datei sich auf keinen Fall innerhalb des Website-Verzeichnisses selbst befinden. Falls Sie gemieteten Webspace verwenden und daher keine andere Möglichkeit haben, müssen Sie den Zugriff auf die entsprechende Datei ganz verbieten. Dies funktioniert für den Dateinamen .htuser zum Beispiel so:

<Files .htuser>
Order deny,allow
Deny from all
</Files>
  • Deny from all|IP-Adresse|Hostname

Kontext: DH; Modul: mod_authtz_host

Verbietet den angegebenen Rechnern, auf Ressourcen in dem Kontext zuzugreifen, in dem die Direktive steht. Das folgende Beispiel untersagt zunächst allen Hosts den Zugriff auf den URL-Pfad /geheim und erlaubt anschließend den Zugriff vom lokalen Rechner aus:

<Location /geheim>
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>

Für die Änderungen in Apache 2.4 beachten Sie bitte die Anmerkungen zur Direktive Allow.

  • <Directory Verzeichnis> ... </Directory>

Kontext: SV; Modul: core

Umschließt Einstellungen für ein bestimmtes Verzeichnis der Website. Das folgende Beispiel verbietet .htaccess-Dateien auf dem gesamten Server (kann für einzelne Verzeichnisse aber wieder überschrieben werden):

<Directory />
AllowOverride None
</Directory>
  • DirectoryIndex Dateiname [Dateiname ...]

Kontext: SVDH; Modul: mod_dir

Gibt Namen für Startseiten an, das heißt für Dateien, nach denen Apache in der angegebenen Reihenfolge suchen soll, wenn nur ein Verzeichnis ohne konkreten Dateinamen angefordert wurde. Der Vorgabewert ist index.html; das folgende Beispiel erlaubt zusätzlich index.htm und index.php:

DirectoryIndex index.html index.htm index.php
  • DocumentRoot Verzeichnis

Kontext: SV; Modul: core

Das Wurzelverzeichnis der Website, dem der URL-Pfad / zugeordnet ist. Die Voreinstellung ist /htdocs im Apache-Verzeichnis.
Unix-Standard:

DocumentRoot /usr/local/apache2/htdocs

Windows-Standard:

DocumentRoot "C:/Programme/Apache Software Foundation/Apache2.2/htdocs"
  • <IfModule Modul> ... </IfModule>

Kontext: SVDH; Modul: core

Direktiven in diesem Container werden nur dann ausgeführt, wenn das betreffende Modul verfügbar ist. Der Modulname wird so angegeben wie das erste Argument von LoadModule (siehe unten); für mod_mime wird beispielsweise mime_module geschrieben. Das folgende Beispiel, das so in der Original-Konfigurationsdatei steht, stellt nur dann die Startseite index.html ein, wenn mod_dir aktiv ist:

<IfModule dir_module>
DirectoryIndex index.html
</IfModule>
  • Listen [IP-Adresse:]Port

Kontext: S; Modul: MPM-Module

Bestimmt den TCP-Port, an dem Apache auf eingehende Clientverbindungen lauscht. Wenn eine IP-Adresse angegeben wird, gilt die Einstellung nur für die betreffende Netzwerkschnittstelle, ansonsten für alle. Standard:

Listen 80

Falls Apache an mehreren Ports lauschen soll, müssen mehrere Listen-Direktiven angegeben werden, zum Beispiel 443 für SSL-verschlüsselte Verbindungen.

  • LoadModule Modulname Dateipfad

Kontext: S; Modul: mod_so

Module, die als Dynamic Shared Objects (DSOs) kompiliert wurden (unter Windows ist dies grundsätzlich der Fall), werden mit Hilfe dieser Direktive geladen und aktiviert. Der erste Parameter, der Modulname, entspricht dem Grundnamen mit angehängtem _module (zum Beispiel rewrite_module für mod_rewrite); der Dateipfad verweist meist auf eine .so-Datei im Verzeichnis modules relativ zur ServerRoot (siehe unten). Das folgende Beispiel lädt mod_autoindex:

LoadModule autoindex_module modules/mod_autoindex.so
  • <Location URL-Pfad> ... </Location>

Kontext: SV; Modul: core

Umschließt die Konfiguration für einen bestimmten URL-Pfad. Hier ein Beispiel, das für alle Dateien in Verzeichnissen unter der URL http://servername/info die Startseite start.html einstellt:

<Location /test>
DirectoryIndex start.html
</Location>
  • NameVirtualHost IP-Adresse[:Port]

Kontext: S; Modul: core

Konfiguriert eine IP-Adresse und/oder einen TCP-Port für den Einsatz namensbasierter virtueller Hosts, das heißt, dass bei Zugriffen auf diese Adresse oder diesen Port je nach Host-Header der Anfrage unterschiedliche Sites geliefert werden. Wenn alle Netzwerkschnittstellen angesprochen werden sollen, können Sie statt einer konkreten Adresse * benutzen. Um virtuelle Hosts einzurichten, müssen Sie anschließend mehrere <VirtualHost>-Container definieren, in denen die Direktive ServerName die unterschiedlichen möglichen Hostnamen angibt.

Wichtig: Für die betreffende Adresse beziehungsweise den Port gibt es danach keinen »Hauptserver« mehr. Auch die bisherige Hauptserver-Konfiguration muss in einen <VirtualHost>-Container verschoben werden.

Hier zwei Beispiele:

NameVirtualHost 196.23.17.42
NameVirtualHost *:8080
  • Options None|All|[+|-]Optionstyp [[+|-]Optionstyp ...]

Kontext: SVDH; Modul: core

Diese Direktive stellt Optionen für ein Verzeichnis ein. None deaktiviert alle Optionen, während All alle außer MultiViews einschaltet. Die verfügbaren Optionen sind:

  • Indexes: Wenn ein Verzeichnis angefordert wurde, wird die Startseite (DirectoryIndex) beziehungsweise der automatisch generierte Index geliefert.
  • FollowSymLinks: Falls die angeforderte URL ein symbolischer Link ist, wird deren Ziel geliefert.
  • SymLinksIfOwnerMatch: Verfolgt ebenfalls symbolische Links, aber nur, wenn der Eigentümer des SymLinks demjenigen der Zieldatei entspricht.
  • ExecCGI: CGI-Skripte werden ausgeführt.
  • Includes: Server Side Includes (SSI) werden ausgeführt.
  • IncludesNOEXEC: Aktiviert ebenfalls SSI, allerdings mit Ausnahme von #exec (Programmausführung) und #exec cgi (CGI-Ausführung).
  • MultiViews: Content-Negotiation wird automatisch anhand bestimmter Dateiendungen durchgeführt.

In untergeordneten Kontexten stehen die speziellen Schreibweisen +Option und ?Option zur Verfügung, um Optionen zu den Einstellungen des übergeordneten Kontextes hinzuzufügen beziehungsweise daraus zu entfernen.

  • Order allow,deny | deny,allow

Kontext: DH; Modul: mod_authtz_host

Legt die Reihenfolge fest, in der Allow- und Deny-Direktiven ausgewertet werden. Der vordere Wert gilt dabei als Voreinstellung (meist mit dem Wert All), der hintere als Ausnahme von dieser Regel. Wichtig: In allow,deny beziehungsweise deny,allow darf kein Leerzeichen hinter dem Komma stehen.

Hier ein Komplettbeispiel, das nur Rechnern aus dem Netzwerk 192.168.1.0/24 den Zugriff auf den URL-Pfad /intranet gestattet:

<Location /intranet>
Order deny,allow
Deny from all
Allow from 192.168.1
</Location>

In Apache 2.4 gilt Order zusammen mit Allow und Deny als veraltet; in der Beschreibung der Direktive Allow steht mehr dazu.

  • Redirect [Status] URL-Pfad URL

Kontext: SVDH; Modul: mod_alias

Anfragen für den angegebenen URL-Pfad werden an die (externe) URL weitergeleitet. Das folgende Beispiel leitet alle Anfragen für http://servername/extern an entsprechende Ressourcen unter http://externerserver weiter:

Redirect /extern http://externerserver
  • Require user Username | group Groupname | valid-user

Kontext: DH; Modul: core

Gibt im Rahmen von Authentifizierungsdirektiven an, welche Benutzer (user) oder Gruppen (group) sich anmelden dürfen. valid-user steht für alle Benutzer aus der aktuellen Datenquelle, zum Beispiel dem AuthUserFile (siehe oben).

In Apache 2.4 wird Require auch verwendet, um Clients anhand ihrer IP-Adressen (Require ip) beziehungsweise Hostnamen (Require host) den Zugriff zu erlauben beziehungsweise zu verweigern. Außerdem stehen verschachtelbare Require-Container zur Verfügung, um zu bestimmen, wie mehrere Require-Direktiven zusammenwirken sollen:

  • <RequireAll>...</RequireAll> ist eine logische Und-Verknüpfung, legt also fest, dass alle enthaltenen Require-Direktiven erfüllt sein müssen.
  • <RequireAny>...</RequireAny> ist dagegen logisches Oder, das heißt, mindestens eine der enthaltenen Require-Direktiven muss erfüllt sein.
  • <RequireNone>...</RequireNone> gilt nur als bestanden, wenn keine der enthaltenen Require-Direktiven zutrifft.
  • Satisfy Any | All

Kontext: DH; Modul: core

Falls Authentifizierung und Zugriffskontrolle über Order/Allow/Deny für dasselbe Verzeichnis eingesetzt werden, gibt diese Direktive an, ob beide Kriterien erfüllt sein müssen (All) oder ob eines von ihnen genügt (Any). Der Vorgabewert ist All.

In Apache 2.4 entfällt Satisfy, weil die Require-Container eine viel genauere Festlegung erlauben.

  • ScriptAlias URL-Pfad Verzeichnispfad

Kontext: SV; Modul: mod_alias

Entspricht der Funktionsweise von Alias (siehe oben), betrachtet aber zusätzlich die Dateien im angegebenen Verzeichnis als CGI-Skripte. In der Standardkonfiguration gibt es ein Verzeichnis cgi-bin unter der ServerRoot (nicht etwa der DocumentRoot!), das als solches CGI-Verzeichnis dient. Der betreffende Eintrag sieht unter Unix so aus:

ScriptAlias /cgi-bin /usr/local/apache2/cgi-bin

Die Windows-Variante lautet:

ScriptAlias /cgi-bin \
"C:/Programme/Apache Software Foundation/Apache2.2/cgi-bin"
  • ServerAdmin E-Mail-Adresse

Kontext: SV; Modul: core

Die E-Mail-Adresse des Server-Administrators, an die Benutzer Fehlermeldungen schicken können. Beispiel:

ServerAdmin webmaster@test.local
  • ServerName Domainname

Kontext: SV; Modul: core

Gibt den Domainnamen des Servers oder des virtuellen Hosts an. Beachten Sie, dass der Server in der Öffentlichkeit nur dann tatsächlich unter diesem Namen verfügbar ist, wenn entsprechende Nameserver-Einträge existieren. Die nötigen Einzelheiten zur Nameserver-Konfiguration werden im nächsten Kapitel erläutert. Beispiel:

ServerName www.test.local
  • ServerRoot Verzeichnispfad

Kontext: S; Modul: core

Dies ist das Stammverzeichnis, in dem Apache installiert wurde. Verzeichnisangaben in vielen Direktiven werden relativ zu diesem Wert interpretiert. Unter Unix wird standardmäßig der folgende Wert verwendet:

ServerRoot /usr/local/apache2

Hier zum Vergleich die übliche Windows-Voreinstellung:

ServerRoot \
"C:/Programme/Apache Software Foundation/Apache2.2"

  • ServerSignature On|Off|E

Kontext: SVDH; Modul: core

Bestimmt die Fußzeile mit Informationen über den Server, den Hostnamen und eventuell die E-Mail-Adresse des Administrators. Die drei möglichen Werte sind: Off – keine Fußzeile; On – Fußzeile ohne E-Mail-Adresse (Beispiel: Apache/2.2.11 (Unix) Server at www.test.local Port 80); EMail – wie On, aber als Link auf die ServerAdmin-E-Mail-Adresse.

  • ServerTokens Major|Minor|Minimal|ProductOnly|OS|Full

Kontext: S; Modul: core

Bestimmt, wie ausführlich die Serversoftware im Server-Header und auf automatisch generierten Seiten genannt wird. Angenommen, es handelt sich um Apache 2.2.11 auf einem Unix-System, dann lautet ProductOnly: Apache, Major: Apache/2, Minor: Apache/2.2, Minimal: Apache/2.2.11 und OS: Apache/2.2.11 (Unix). Full hängt noch die Selbstbeschreibungen diverser Module an, zum Beispiel Apache/2.2.11 (Unix) Dav/2 PHP/5.2.9.

  • <VirtualHost Host[:Port]> ... </VirtualHost>

Kontext: S; Modul: core

Umschließt die Konfiguration eines virtuellen Hosts, der durch eine IP-Adresse, einen Hostnamen und/oder einen TCP-Port angegeben wird. Die zugehörigen Listen- und eventuellen NameVirtualHost-Direktiven müssen allerdings im Serverkontext stehen. Näheres über das komplexe Thema Virtual Hosts erfahren Sie in der Beschreibung dieser Direktive auf der Website zu meinem Buch »Apache 2«: http://buecher.lingoworld.de/apache2/showdir.php?id=757.

Konfigurationsbeispiele

Nachdem soeben diverse Apache-Direktiven vorgestellt wurden, sollten Sie sich einige von ihnen im größeren Konfigurationszusammenhang anschauen.

Als Erstes sollten restriktive Voreinstellungen für das Wurzelverzeichnis – und damit für jedes beliebige Verzeichnis – vorgenommen werden:

<Directory />
# Alle Optionen ausschalten
Options None
# .htaccess ausschalten (f. Sicherheit & Performance)
AllowOverride None
# ALLE Zugriffe verbieten
Order deny,allow
Deny from all
</Directory>

Die DocumentRoot benötigt dagegen großzügigere Einstellungen, beispielsweise diese:

<Directory /usr/local/apache2/htdocs>
# Einige Optionen aktivieren
Options Indexes FollowSymLinks
# Alle Zugriffe gestatten
Order allow,deny
Allow from all
</Directory>

Wenn Sie Aliasse verwenden, müssen Sie für die betreffenden Verzeichnisse übrigens auch derartige Angaben machen.

Hier ein etwas umfangreicheres Beispiel, das zwei namensbasierte virtuelle Hosts für den Port 8080 bereitstellt:

# An Port 8080 lauschen
Listen 8080

# Namensbasierte virtuelle Hosts für Port 8080 aktivieren
NameVirtualHost *:8080

# Erster VHost, server1.test.local:8080
<VirtualHost *:8080>
# ServerName, mit dem der Host-Header
# einer Anfrage verglichen wird
ServerName server1.test.local
# Spezifische Webmaster-E-Mail-Adresse
ServerAdmin webmaster@server1.test.local
# Wurzelverzeichnis der Website
DocumentRoot /var/www/vhosts/server1
# Zugriffe auf dieses Verzeichnis erlauben
<Directory /var/www/vhosts/server1>
Options All
Order allow,deny
Allow from all
</Directory>
# Fehler-Logdatei
ErrorLog logs/server1.test.local-error_log
# Zugriffs-Logdatei

CustomLog logs/server1.test.local-access_log common
</VirtualHost>

# Zweiter VHost, server2.test.local:8080
<VirtualHost *:8080>
ServerName server2.test.local
ServerAdmin webmaster@server1.test.local
DocumentRoot /var/www/vhosts/server1
<Directory /var/www/vhosts/server1>
Options All
Order allow,deny
Allow from all
</Directory>
ErrorLog logs/server1.test.local-error_log
CustomLog logs/server1.test.local-access_log common
</VirtualHost>

Je nachdem, ob ein Besucher eine Adresse unter http://server1.test.local:8080 oder unter http://server2.test.local:8080 eingibt, wird die gewünschte Ressource aus der jeweiligen DocumentRoot geliefert.

Als Nächstes sehen Sie hier ein vollständiges Beispiel für ein geschütztes Verzeichnis, dessen Inhalte Benutzer nur nach Anmeldung mit Benutzername und Passwort aufrufen dürfen. Die gewünschten Benutzerdaten müssen sich dabei in der htpasswd-Datei .htuser im Apache-conf-Verzeichnis befinden:

<Location /privat>
# Klartextbasierte Übertragung der Anmeldedaten
AuthType Basic
# Anmeldedaten in einfacher htpasswd-Textdatei
AuthBasicProvide file
# Realm
AuthName "Privater Bereich"
# Pfad der htpasswd-Datei
AuthUserFile conf/.htuser
# Alle User aus der Datei haben Zutritt
Require valid-user
</Location>

Dies akzeptiert alle Benutzer/Passwort-Kombinationen aus der Datei .htuser. Wenn ein User einen URL-Pfad aus diesem Verzeichnis anfordert, erhält sein Browser den Status 401 Unauthorized als Antwort und zeigt einen Anmeldedialog an. Wenn die Anmeldung innerhalb einer Sitzung einmal korrekt erfolgt ist, sendet der Browser bei weiteren Zugriffen auf denselben Bereich die Anmeldedaten automatisch.

Hier zu guter Letzt noch eine Standardkonfiguration für einen virtuellen Host unter dem SSL-Standardport 443. Anfragen, die an https://servername gesendet werden, erzeugen dadurch gesicherte Verbindungen und werden mit Dateien aus der DocumentRoot /var/www/secure beantwortet:

# An Port 443 (SSL-Standard) lauschen
Listen 443

# Die wichtigsten allgemeinen SSL-Voreinstellungen

# Standardverhalten bei der SSL-Serialisierung
# (geordnete Verarbeitungsreihenfolge)
SSLMutex default
# Den eingebauten Startwertalgorithmus für
# den Zufallsgenerator verwenden
SSLRandomSeed startup builtin
# Kein Cache für SSL-Sitzungsdaten
SSLSessionCache none

# Virtueller Host für Port 443
<VirtualHost *:443>
# SSL-Funkitonalität einschalten
SSLEngine On
# Pfad zum Server-Zertifikat
SSLCertificateFile conf/ssl/test.cert
# Pfad zum Public Key des Server-Zertifikats
SSLCertificateKeyFile conf/ssl/test.key
# Pfad der gesicherten Website
DocumentRoot /var/www/secure
</VirtualHost>

Das Zertifikat können Sie mit Hilfe von openssl erzeugen, müssen es für den Praxiseinsatz aber von einer anerkannten Zertifizierungsstelle durch eine digitale Signatur beglaubigen lassen, damit Browser es ohne Fehlermeldung akzeptieren. Eine solche Signatur kostet Geld; in der Regel ist es aber günstiger, sich dafür an Ihren Hoster zu wenden als direkt an eine Zertifizierungsstelle. Näheres zur Zertifikatserstellung und SSL-Konfiguration erfahren Sie auf der Webseite http://buecher.lingoworld.de/apache2/mod_ssl.html.

Andere Webserver im Überblick

Neben dem ausführlich vorgestellten Marktführer Apache gibt es zahlreiche weitere Webserver. Drei bekannte Modelle sind:

  • Microsoft Internet Information Services (IIS)
    Der Microsoft-Webserver gehört zum Lieferumfang aller Windows-Server seit Windows NT 4.0 Server. In Windows Server 2003 ist Version 6 enthalten; Windows Server 2008 enthält die neue Version 7. Für Windows XP Professional und diverse erweiterte Vista-Varianten existiert IIS als optionaler Download.

Der Leistungsumfang von IIS reicht an denjenigen von Apache heran; hinzu kommen eingebaute FTP-Server- und Mailserver-Funktionen. Die Konfiguration erfolgt nicht über eine textbasierte Konfigurationsdatei, sondern ausschließlich über die grafische Benutzer-oberfläche.

IIS ist außerdem ein Web Application Server für ASP.NET, Microsofts eigene Technologie für Webanwendungen. Gemäß der .NET-Spezifikation können diese Anwendungen in allen Sprachen der Common Language Runtime geschrieben werden, zum Beispiel in VB.NET, C# oder C++.

  • Lighttpd
    Dieser Webserver ist ein Open-Source-Produkt. Wie der Name vermuten lässt, handelt es sich um eine leichtgewichtige Alternative zu einem umfangreichen HTTP-Server wie Apache. Der »Lighty« wurde vor allem im Hinblick auf geringen Ressourcenverbrauch geschrieben. Dafür bietet er natürlich weniger Features als Apache, ist aber ebenfalls durch Module erweiterbar.

  • Apache Tomcat
    Tomcat stammt ebenfalls von der Apache Software Foundation. Es handelt sich in erster Linie um einen Application Server für Java Servlets und Java Server Pages (JSP), der aber auch statische HTML-Seiten ausliefern kann. Dies erledigt er natürlich nicht ganz so performant und flexibel wie der Apache-HTTP-Server, aber für eine größtenteils Java-basierte Webapplikation mit nur wenigen statischen Seiten genügt er auch in dieser Rolle. Wenn nötig lässt er sich aber auch als Backend-Server mit einem Apache verknüpfen.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.







<< zurück




Copyright © Galileo Press 2011
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de


  Zum Katalog
Zum Katalog: IT-Handbuch für Fachinformatiker






IT-Handbuch für Fachinformatiker
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Java ist auch eine Insel






 Java ist auch
 eine Insel


Zum Katalog: Android 3






 Android 3


Zum Katalog: Linux






 Linux


Zum Katalog: Ubuntu GNU/Linux






 Ubuntu
 GNU/Linux


Zum Katalog: Windows Server 2008 R2






 Windows Server
 2008 R2


Zum Katalog: PHP & MySQL






 PHP & MySQL


Zum Katalog: Visual C# 2010






 Visual C# 2010


Zum Katalog: C von A bis Z






 C von A bis Z


Zum Katalog: C++ von A bis Z






 C++ von A bis Z


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo