Apache HTTP Server Version 2.2
Apache HTTP Server Version 2.2
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
httpd.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 http://www.domain.tld/domain/
abrufbar sind, wenngleich Clients, die den Header Host:
senden, auch �ber http://www.domain.tld/ auf sie zugreifen
k�nnen.
Legen Sie einen Link auf der Seite Ihres prim�ren virtuellen Hosts zu
http://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.,
"http://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.