Apache HTTP Server Version 2.4
Apache HTTP Server Version 2.4
Das Dokument beschreibt, wann und wie namensbasierte virtuelle Hosts zu verwenden sind.
Namensbasierte gegenüber IP-basierten
virtuellen Hosts Die Verwendung von namensbasierten virtuellen Hosts Kompatibilität mit älteren Browsern
IP-basierte virtuelle Hosts verwenden die IP-Adresse der Verbindung, um den korrekten virtuellen Host zur Bedienung einer Anfrage zu ermitteln. Folglich benötigen Sie eine IP-Adresse für jeden virtuellen Host. Bei der Verwendung von namensbasierten virtuellen Hosts verläßt sich der Server darauf, dass der Client den Hostnamen als Bestandteil der HTTP-Header angibt. Durch Anwendung dieser Technik können sich mehrere verschiedene Hosts die gleiche IP-Adresse teilen.
Die Verwendung von namensbasierten virtuellen Hosts ist gewöhnlich einfacher. Sie müssen lediglich Ihren DNS-Server darauf einstellen, jeden Hostnamen auf die richtige IP-Adresse abzubilden, und dann den Apache HTTP Server so konfigurieren, dass er die verschiedenen Hostnamen erkennt. Namensbasierte virtuelle Hosts entschärfen auch den Bedarf an knappen IP-Adressen. Daher sollten Sie namensbasierte virtuelle Hosts verwenden, sofern kein besonderer Grund dafür existiert, IP-basierte virtuelle Hosts zu wählen. Mögliche Gründe für die Verwendung IP-basierter virtueller Hosts sind:
| Referenzierte Module | Referenzierte Direktiven |
|---|---|
Um namensbasierte virtuelle Hosts zu verwenden, müssen Sie die
IP-Adresse (und möglicherweise den Port) des Servers benennen, an
der Anfragen für die Hosts entgegengenommen werden. Dies wird mit
der Direktive NameVirtualHost
eingestellt. Im Normalfall, wenn alle IP-Adressen des Server verwendet
werden sollen, können Sie * als Argument für
NameVirtualHost verwenden. Wenn Sie
vorhaben, mehrere Ports zu nutzen (etwa wenn SSL läuft), sollten
Sie dem Argument einen Port hinzufügen, wie zum Beispiel
*:80. Beachten Sie,
dass die Angabe einer IP-Adresse in einer NameVirtualHost-Anweisung den Server nicht
automatisch an dieser Adresse lauschen läßt. Lesen Sie bitte "Bestimmen der vom Apache verwendeten Adressen und
Ports" für weitere Details. Zusätzlich muss jede hier
angegebene IP-Adresse einer Netzwerkkarte des Servers zugeordnet sein.
Der nächste Schritt ist die Erstellung eines <VirtualHost>-Blocks für jeden einzelnen
Host, den Sie bedienen wollen. Das Argument der Direktive <VirtualHost> sollte das gleiche
sein wie das Argument der NameVirtualHost-Anweisung (d.h. eine IP-Adresse
oder * für alle Adressen). Innerhalb jedes <VirtualHost>-Blocks benötigen
Sie zumindestens eine ServerName-Anweisung, um zu bestimmen, welcher
Host bedient wird, und eine DocumentRoot-Anweisung, um anzugeben, wo im
Dateisystem der Inhalt des Hosts abgelegt ist.
<VirtualHost>-Block für den bestehenden Host
(Anm.d.Ü.: und bisherigen Hauptserver) erstellen.
Die ServerName- und
DocumentRoot-Anweisungen zu diesem
virtuellen Host sollten die gleichen sein wie die globalen ServerName- und DocumentRoot-Anweisungen. Führen Sie diesen
virtuellen Host als erstes in der Konfigurationsdatei auf, so dass er als
Standard-Host fungiert.
Vorausgesetzt, Sie bedienen z.B. die Domain
www.domain.tld und möchten den virtuellen Host
www.otherdomain.tld hinzufügen, welcher auf
die gleiche IP-Adresse zeigt. Dann fügen Sie einfach Folgendes der
apache2.conf hinzu:
NameVirtualHost *:80
<VirtualHost *:80>
ServerName www.domain.tld
ServerAlias domain.tld *.domain.tld
DocumentRoot /www/domain
</VirtualHost>
<VirtualHost *:80>
ServerName www.otherdomain.tld
DocumentRoot /www/otherdomain
</VirtualHost>
Sie können anstelle des * bei den beiden Anweisungen
NameVirtualHost und <VirtualHost> alternativ eine
eindeutige IP-Adresse angeben. Das kann man beispielsweise machen, um
einige namensbasierte virtuelle Hosts auf einer IP-Adresse zu betreiben und
entweder IP-basierte oder ein anderes Set von namensbasierten virtuellen
Hosts auf einer anderen Adresse.
Viele Server wollen unter mehr als einem Namen erreichbar sein. Die
Direktive ServerAlias, die innerhalb
des <VirtualHost>-Abschnittes angegeben wird,
ermöglicht dies. Zum Beispiel zeigt die ServerAlias-Anweisung in dem ersten <VirtualHost>-Block oben an, dass die
aufgeführten Namen alternative Namen sind, die man verwenden kann, um
das gleiche Webangebot zu erreichen:
ServerAlias domain.tld *.domain.tld
Anfragen für alle Hosts der Domain domain.tld werden
von dem virtuellen Host www.domain.tld bedient. Die
Platzhalter * und ? können anstelle
entsprechender Namen verwendet werden. Natürlich können Sie nicht
einfach Namen erfinden und diese bei ServerName oder ServerAlias
angeben, Sie müssen zunächst Ihren DNS Server entsprechend
konfigurieren, dass er diese Namen auf die mit Ihrem Server verknüpfte
IP-Adresse abbildet.
Und schlußendlich können Sie die Konfiguration der virtuellen
Hosts mittels Angabe weiterer Direktiven innherhalb der <VirtualHost>-Container
feineinstellen. Die meisten Direktiven können in diesen Containern
angegeben werden und verändern dann ausschließlich die
Konfiguration des entsprechenden virtuellen Hosts. Prüfen Sie den Kontext einer Direktive, um
herauszufinden, ob eine bestimmte Direktive zulässig ist.
Im Hauptserver-Kontext (außerhalb der <VirtualHost>-Container) definierte
Konfigurationsanweisungen werden nur dann angewendet, wenn sie nicht durch
Einstellungen des virtuellen Hosts außer Kraft gesetzt wurden.
Wenn nun eine Anfrage eintrifft, prüft der Server zuerst, ob sie eine
IP-Adresse verwendet, die der NameVirtualHost-Anweisung entspricht. Ist dies der
Fall, dann sieht er sich jeden <VirtualHost>-Abschnitt mit einer passenden
IP-Adresse an und versucht den einen zu finden, dessen ServerName- oder ServerAlias-Anweisung mit dem gewünschten
Hostnamen übereinstimmt. Findet er einen, dann verwendet er die
Konfiguration dieses Servers. Wird kein passender virtueller Host gefunden,
dann wird der erste angegeben virtuelle Host verwendet,
dessen IP-Adresse paßt.
Die Folge davon ist, dass der erste aufgeführte virtuelle Host der
Standard-Virtual-Host ist. Die DocumentRoot-Anweisung des Hauptservers
wird niemals verwendet, wenn eine IP-Adresse mit einer
NameVirtualHost-Anweisung
übereinstimmt. Wenn Sie eine spezielle Konfiguration für Anfragen
angeben möchten, die keinem bestimmten virtuellen Host entsprechen,
packen Sie diese Konfiguration einfach in einen <VirtualHost>-Container und führen diesen als
erstes in der Konfigurationsdatei auf.
Wie zuvor erwähnt gibt es einige Clients, die nicht die notwendigen Daten senden, mit denen namensbasierte virtuelle Hosts korrekt funktionieren. Diesen Clients werden stets die Seiten des ersten, für diese IP-Adresse aufgeführten virtuellen Hosts gesendet werden (des primären namensbasierten virtuellen Hosts).
Beachten Sie bitte, wenn wir von älter sprechen, meinen wir auch
älter. Es ist sehr unwahrscheinlich, dass sie einen dieser Browser
heutzutage in Verwendung finden werden. Alle aktuellen Browser-Versionen
senden den Host-Header, so wie er für namensbasierte
virtuelle Hosts benäötigt wird.
Mit der Direktive ServerPath existiert
eine mögliche Behelfskonstruktion, obgleich sie etwas schwerfällig
ist:
Beispielkonfiguration:
NameVirtualHost 111.22.33.44
<VirtualHost 111.22.33.44>
ServerName www.domain.tld
ServerPath /domain
DocumentRoot /web/domain
</VirtualHost>
Was bedeutet das? Es bedeutet, dass eine Anfrage für eine mit
"/domain" beginnende URI von dem virtuellen Host
www.domain.tld bedient wird. Dies heißt, dass die Seiten
für alle Clients unter https://www.domain.tld/domain/
abrufbar sind, wenngleich Clients, die den Header Host:
senden, auch über https://www.domain.tld/ auf sie zugreifen
können.
Legen Sie einen Link auf der Seite Ihres primären virtuellen Hosts zu
https://www.domain.tld/domain/, um die Behelfslösung
verfügbar zu machen. Bei den Seiten der virtuellen Hosts müssen
Sie dann sicherstellen, entweder außschließlich relative Links
(z.B. "file.html" oder
"../icons/image.gif") zu verwenden oder Links, die das
einleitende /domain/ enthalten (z.B.,
"https://www.domain.tld/domain/misc/file.html" oder
"/domain/misc/file.html").
Dies erfordert etwas Disziplin, die Befolgung dieser Richtlinien stellt jedoch größtenteils sicher, dass Ihre Seiten mit allen Browsern funktionieren, alten wie neuen.