Apache-Kernfunktionen

AcceptPathInfo-Direktive

Die Direktive steuert, ob Anfragen akzeptiert oder abgewiesen werden, bei denen nach der tatsÄchlichen Datei (oder einer nicht existierenden Datei in einem existierenden Verzeichnis) zusÄtzliche Pfadangaben folgen. Die angehÄngte Pfadangabe kann Skripten in der Umgebungsvariable PATH_INFO verfÝgbar gemacht werden.

Nehmen wir beispielsweise an, dass /test/ auf ein Verzeichnis zeigt, welches lediglich eine Datei here.html enthÄlt. Dann wird bei Anfragen nach /test/here.html/more und /test/nothere.html/more beides Mal /more als PATH_INFO ermittelt.

Die drei mÆglichen Argumente fÝr die Direktive AcceptPathInfo sind:

Off

Eine Anfrage wird nur dann akzeptiert, wenn sie exakt auf ein existierendes Verzeichnis (oder eine Datei) abgebildet werden kann. Daher wÝrde eine Anfrage mit einer nach dem tatsÄchlichen Dateinamen angehÄngten Pfadangabe, wie /test/here.html/more im obigen Beispiel, den Fehler 404 NOT FOUND (Anm.d.ý.: nicht gefunden) zurÝckgeben.

On

Eine Anfrage wird akzeptiert, wenn eine vorangestellte Pfadangabe auf ein existierendes Verzeichnis abgebildet werden kann. Das obige Beispiel /test/here.html/more wird akzeptiert, wenn /test/here.html auf eine gÝltige Datei zeigt.

Default

Die Behandlung von Anfragen mit angehÄngten Pfadangaben wird von dem fÝr die Anfrage verantwortlichen Handler bestimmt. Der Core-Handler fÝr gewÆhnliche Dateien weist PATH_INFO-Zugriffe standardmÄúig zurÝck. Handler, die Skripte bedienen, wie z.B. cgi-script und isapi-isa, sind im Allgemeinen darauf voreingestellt, PATH_INFO zu akzeptieren.

Das eigentliche Ziel von AcceptPathInfo ist es, Ihnen das ýberschreiben der Voreinstellung der Handler bezÝglich der Akzeptanz oder Ablehnung von PATH_INFO zu erlauben. Eine solche änderung ist zum Beispiel notwendig, wenn Sie einen Filter wie INCLUDES verwenden, um Inhalte abhÄngig von PATH_INFO zu generieren. Der Core-Handler wÝrde die Anfrage normalerweise abweisen. Verwenden Sie die folgende Konfiguration, um dennoch solch ein Skript zu ermÆglichen.

AccessFileName-Direktive

Aus dieser Namensliste sucht der Server wÄhrend der Bearbeitung einer Anfrage in jedem Verzeichnis nach der ersten existierenden Datei, sofern im betreffenden Verzeichnis dezentrale Konfigurationsdateien erlaubt sind. Beispiel:

Vor der RÝcksendung des Dokuments /usr/local/web/index.html wird der Server /.acl, /usr/.acl, /usr/local/.acl und /usr/local/web/.acl einlesen, solange diese nicht mit

deaktiviert wurden.

Siehe auch

• AllowOverride
• Konfigurationsdateien
• .htaccess-Dateien

AddDefaultCharset-Direktive

Die Direktive gibt einen Standardwert fÝr den Charset-Paramter des Medientyps (den Namen einer Zeichencodierung) an, der einer Antwort genau dann hinzugefÝgt wird, wenn der Content-Type der Antwort entweder text/plain oder text/html ist. Dies sollte jedes mittels META-Element im Datenteil der Antwort angegebene Charset Ýberschreiben. Das genaue Verhalten hÄngt jedoch oft von der Client-Konfiguration des Benutzers ab. Die Einstellung AddDefaultCharset Off deaktiviert diese FunktionalitÄt. AddDefaultCharset On aktiviert die Standard-Zeichenkodierung iso-8859-1. Jeder andere Wert wird als die zu verwendende Zeichenkodierung aufgefaút, die eines der bei IANA registrierten Charset-Werte zur Verwendung in MIME-Medientypen sein sollte. Zum Beispiel:

AddDefaultCharset sollte nur verwendet werden, wenn von allen Textressourcen, fÝr die es gilt, bekannt ist, dass sie in dieser Zeichkodierung vorliegen, oder wenn es zu unbequem ist, ihre Zeichenkodierung indivuell zu benennen. Ein solches Beispiel ist das HinzufÝgen des Charset-Parameters zu Ressourcen, die generierte Inhalte enthalten. Ein Beispiel sind CGI-Skript-Altlasten, die aufgrund von in die Ausgabe integrierten Daten, die durch den Benutzer Ýbermittelt wurden, gegen Cross-Site-Scripting-Angriffe verwundbar sind. Eine bessere LÆsung wÄre jedoch, diese Skripte zu korrigieren (oder zu lÆschen), da die Angabe einer Standard-Zeichencodierung keine Anwender schÝtzt, die in ihrem Browser die Funktion zur automatischen Erkennung der Zeichenkodierung aktiviert haben.

Siehe auch

• AddCharset

AddOutputFilterByType-Direktive

Die Direktive aktiviert fÝr eine Anfrage abhÄngig vom MIME-Type der Antwort einen bestimmten Ausgabe-Filter.

Das folgende Beispiel verwendet den Filter DEFLATE, der von mod_deflate angeboten wird. Er komprimiert jede Ausgabe, die als text/html oder text/plain gekennzeichnet ist, (gleichgÝltig, ob statisch oder dynamisch) bevor sie an den Client gesendet wird.

Wenn Sie den Inhalt von mehr als einem Filter verarbeiten lassen wollen, dann mÝssen deren Namen durch Semikolons voneinander getrennt werden. Es ist ebenfalls mÆglich, eine AddOutputFilterByType-Direktive fÝr jeden von diesen Filtern zu verwenden.

Die folgende Konfiguration sorgt dafÝr, dass alle Skriptausgaben, die als text/html gekennzeichnet sind, zuerst vom INCLUDES-Filter und dann vom DEFLATE-Filter verarbeitet werden.

Siehe auch

• AddOutputFilter
• SetOutputFilter
• Filter

AllowEncodedSlashes-Direktive

Die AllowEncodedSlashes-Direktive erlaubt die Verwendung von URLs, welche kodierte Pfadtrennzeichen (%2F fÝr / und auf entsprechenden Systemen zusÄtzlich %5C fÝr \) enthalten. Normalerweise werden derartige URLs mit einem 404-Fehler (Nicht gefunden) abgewiesen.

AllowEncodedSlashes On ist vor allem in Verbindung mit PATH_INFO hilfreich.

Siehe auch

• AcceptPathInfo

AllowOverride-Direktive

Wenn der Server eine .htaccess-Datei (wie durch AccessFileName definiert) findet, muss er wissen, welche in der Datei angegebenen Direktiven frÝhere Konfigurationsanweisungen Ýberschreiben dÝrfen.

Wenn diese Anweisung auf None gesetzt wird, dann werden .htaccess-Dateien komplett ignoriert. In diesem Fall wird der Server nicht einmal versuchen, die .htaccess-Dateien im Dateisystem zu lesen.

Wenn diese Anweisung auf All gesetzt wird, dann ist jede Direktive in den .htaccess-Dateien erlaubt, die den Kontext .htaccess besitzt.

Der Direktiven-Typ kann eine der folgenden Anweisungsgruppen sein.

AuthConfig

Erlaubt die Verwendung von Autorisierungs-Anweisungen (AuthDBMGroupFile, AuthDBMUserFile, AuthGroupFile, AuthName, AuthType, AuthUserFile, Require usw.).

FileInfo

Erlaubt die Verwendung von Direktiven zur Steuerung der Dokumenttypen (DefaultType, ErrorDocument, ForceType, LanguagePriority, SetHandler, SetInputFilter, SetOutputFilter, und mod_mime-Direktiven Add* und Remove* usw.).

Indexes

Erlaubt die Verwendung von Direktiven zur Steuerung von Verzeichnisindizes (AddDescription, AddIcon, AddIconByEncoding, AddIconByType, DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName usw.).

Limit

Erlaubt die Verwendung von Direktiven zur Steuerung des Zugriffs von Hosts (Allow, Deny und Order).

Options

Erlaubt die Verwendung von Direktiven zur Steuerung spezieller Verzeichniseigenschaften (Options und XBitHack).

Beispiel:

Im obigen Beispiel erzeugen alle Direktiven einen internal server error (Anm.d.ý.: (Server-interner Fehler)), die weder der Gruppe AuthConfig noch der Gruppe Indexes angehÆren.

Siehe auch

• AccessFileName
• Konfigurationsdateien
• .htaccess-Dateien

AuthName-Direktive

Die Direktive legt den Namen des Autorisierungsbereiches (Anm.d.ý.: Der Autorisierungsbereich wird auch Realm genannt.) fÝr ein Verzeichnis fest. Dieser Realm wird dem Client mitgeteilt, damit der Anwender weiú, welchen Benutzernamen und welches Passwort er zu Ýbermitteln hat. AuthName akzeptiert ein Argument. Falls der Name des Realm Leerzeichen enthÄlt, muss er in AnfÝhrungszeichen eingeschlossen werden. Um zu funktionieren, muss die Anweisung von den Direktiven AuthType und Require sowie von Direktiven wie AuthUserFile und AuthGroupFile begleitet werden.

Beispiel:

Die AuthName Ýbergebene Zeichenkette ist das, was in dem von den meisten Browsern angebotenen Passwort-Dialog angezeigt wird.

Siehe auch

• Authentisierung, Autorisierung und Zugriffskontrolle

AuthType-Direktive

Die Direktive wÄhlt die Art der Benutzer-Authentisierung fÝr ein Verzeichnis aus. Derzeit sind lediglich Basic und Digest implementiert. Um zu funktionieren, muss die Anweisung von den Direktiven AuthName und Require sowie von Direktiven wie AuthUserFile und AuthGroupFile begleitet werden.

Siehe auch

• Authentisierung, Autorisierung und Zugriffskontrolle

CGIMapExtension-Direktive

Die Direktive wird zur Steuerung verwendet, wie Apache den Interpreter ermittelt, der zur AusfÝhrung von CGI-Skripten verwendet wird. Beispielsweise bestimmt die Angabe von CGIMapExtension sys:\foo.nlm .foo, dass alle CGI-Scripte mit der Endung .foo an den FOO-Interpreter Ýbergeben werden.

ContentDigest-Direktive

Die Direktive aktiviert die Generierung von Content-MD5-Headern, wie sie in RFC1864 bzw. RFC2068 definiert sind.

MD5 ist ein Algorithmus zur Berechnung eines "Datenextrakts" (zuweilen "Fingerabdruck" genannt) (Anm.d.ý.: Der "Datenextrakt" wird im Englischen als "message digest" oder "fingerprint" bezeichnet.) aus beliebig langen Daten. Es gilt als zuverlÄssig, dass VerÄnderungen an den Daten sich in VerÄnderungen des Extrakts wiederspiegeln.

Der Content-MD5-Header bietet eine End-to-End-IntegritÄtsprÝfung (MIC) (Anm.d.ý.: MIC steht fÝr "message integrity check".) des Daten-Inhalts. Ein Proxy oder Client kann diesen Header prÝfen, um zufÄllige VerÄnderungen des Entity-Inhalts bei der ýbertragung festzustellen. Beispielheader:

Beachten Sie bitte, dass dies Performanceprobleme auf Ihrem System verursachen kann, da der Extrakt bei jeder Anfrage berechnet wird (der Wert wird nicht zwischengespeichert).

Content-MD5 wird nur fÝr Dokumente gesendet, die von core bedient werden, nicht jedoch bei Modulen. SSI-Dokumente, CGI-Skript-Ausgaben und Byte-Range-Antworten besitzen diesen Header beispielsweise nicht.

DefaultType-Direktive

Es kann vorkommen, dass der Server ein Dokument ausliefern muss, dessen Typ er nicht mit Hilfe seiner MIME-Type-Zuordnungen bestimmen kann.

Der Server muss den Client Ýber den Content-Type des Dokumentes informieren. Daher verwendet er im Falle eines unbekannten Typs die DefaultType-Einstellung. Zum Beispiel:

wÄre angemessen fÝr ein Verzeichnis, das viele GIF-Bilder enthÄlt, deren Dateinamen nicht Endung .gif besitzen.

Beachten Sie bitte, dass die Direktive anders als ForceType lediglich den Standard-MIME-Type bestimmt. Alle anderen MIME-Type-Definitionen, einschlieúlich Dateierweiterungen, die den Medien-Typ anzeigen kÆnnen, Ýberschreiben diese Voreinstellung.

<Directory>-Direktive

<Directory> und </Directory> werden dazu verwendet, eine Gruppe von Direktiven zusammenzufassen, die nur fÝr das genannte Verzeichnis und dessen Unterverzeichnisse gelten. Jede Direktive, die im Verzeichnis-Kontext erlaubt ist, kann verwendet werden. Verzeichnispfad ist entweder der vollstÄndige Pfad zu einem Verzeichnis oder eine Zeichenkette mit Platzhaltern wie sie von der Unix-Shell zum Abgleich verwendet werden. In einer Zeichenkette mit Platzhaltern (Anm.d.ý.: sogenannte wild-cards) entspricht ? einem einzelnen Zeichen und * einer Zeichenkette beliebiger LÄnge. Sie kÆnnen auch auch []-Zeichenbereiche verwenden. Keiner der Platzhalter entspricht dem Zeichen "/". Daher passt <Directory /*/public_html> nicht auf /home/user/public_html, <Directory /home/*/public_html> jedoch tut es. Beispiel:

Erweiterte regulÄre AusdrÝcke kÆnnen ebenfalls verwendet werden, indem das Zeichen ~ hinzugefÝgt wird. Beispielsweise wÝrde

auf Verzeichnisse in /www/ passen, die aus drei Zahlen bestehen.

Wenn mehrere <Directory>-Abschnitte (ohne regulÄre AusdrÝcke) auf ein Verzeichnis (oder ein ihm Ýbergeordnetes Verzeichnis) passen, welches ein Dokument enthÄlt, dann werden die Direktiven der Reihe nach, angefangen beim kÝrzesten passenden Muster, vermischt mit den Direktiven aus den .htaccess-Dateien, angewendet. Beispiel:

Beim Zugriff auf das Dokument /home/web/dir/doc.html sind die einzelnen Schritte:

• Wende die Direktive AllowOverride None an (deaktiviere .htaccess-Dateien).
• Wende die Direktive AllowOverride FileInfo (auf das Verzeichnis /home) an.
• Wende jede FileInfo-Direktive aus /home/.htaccess, /home/web/.htaccess und /home/web/dir/.htaccess der Reihe nach an.

RegulÄre AusdrÝcke werden solange nicht berÝcksichtigt, bis alle normalen Abschnitte angewendet wurden. Anschlieúend werden alle regulÄren AusdrÝcke in der Reihenfolge geprÝft, in der sie in der Konfigurationsdatei auftauchen. Beispielsweise wird bei

der Abschnitt mit dem regulÄren Ausdruck nicht berÝcksichtigt, bis alle normalen <Directory>-Abschnitte und .htaccess-Dateien angewendet wurden. Dann erst wird der regulÄre Ausdruck mit /home/abc/public_html/abc abgeglichen und der entsprechende <Directory>-Abschnitt angewendet.

Beachten Sie bitte, dass der vom Apache voreingestellte Zugriff fÝr <Directory /> Allow from All ist. Das bedeutet, dass der Apache jede Datei ausliefert, die durch eine URL abgebildet wird. Es wird empfohlen, dass Sie dies durch einen Block wie

Ändern und anschlieúend fÝr Verzeichnisse Ýberschreiben, die Sie verfÝgbar machen wollen. FÝr weitere Einzelheiten lesen Sie bitte die Seite zu den Sicherheitshinweisen.

Die Verzeichnisabschnitte erscheinen in der Datei httpd.conf. <Directory>-Direktiven dÝrfen nicht ineinander verschachtelt werden oder innerhalb von <Limit>- oder <LimitExcept>-Abschnitten auftauchen.

Siehe auch

• Wie die Abschnitte <Directory>, <Location> und <Files> arbeiten fÝr eine ErlÄuterung, wie diese verschiedenen Abschnitte miteinander kombiniert werden, wenn eine Anfrage empfangen wird

<DirectoryMatch>-Direktive

<DirectoryMatch> und </DirectoryMatch> werden dazu verwendet, eine Gruppe von Direktiven zusammenzufassen, die nur fÝr das genannte Verzeichnis und dessen Unterverzeichnisse gelten, genauso wie bei <Directory>. Als Argument dient jedoch ein regulÄrer Ausdruck. Beispielsweise wÝrde

auf Verzeichnisse in /www/ passen, die aus drei Zeichen bestehen.

Siehe auch

• <Directory> fÝr eine Beschreibung, wie regulÄre AusdrÝcke mit normalen <Directory>-Anweisungen vermischt werden.
• Wie die Abschnitte <Directory>, <Location> und <Files> arbeiten fÝr eine ErlÄuterung, wie diese verschiedenen Abschnitte miteinander kombiniert werden, wenn eine Anfrage empfangen wird

DocumentRoot-Direktive

Die Direktive setzt das Verzeichnis, von dem aus httpd Dateien ausliefert. Sofern nicht eine Direktive wie Alias greift, hÄngt der Server Pfade aus der angeforderten URL an das Wurzelverzeichnis an, um den Pfad zum Dokument zu bilden. Beispiel:

Damit bezieht sich ein Zugriff auf http://www.my.host.com/index.html auf /usr/web/index.html.

DocumentRoot sollte ohne einen SchrÄgstrich am Ende angegeben werden.

Siehe auch

• URLs auf das Dateisystem abbilden

EnableMMAP-Direktive

Die Direktive steuert, ob httpd Memory-Mapping verwenden darf, wenn er wÄhrend der Auslieferung den Inhalt einer Datei lesen muss. Wenn die Bearbeitung einer Anfrage es erfordert, auf die Daten in einer Datei zuzugreifen -- zum Beispiel bei der Auslieferung einer mittels mod_include serverseitig analysierten Datei --, dann verwendet der Apache standardmÄúig Memory-Mapping fÝr diese Datei, sofern das Betriebssystem es unterstÝtzt.

Memory-Mapping bedeutet zuweilen eine Performanceverbesserung. In einigen Umgebungen ist es jedoch besser, Memory-Mapping zu deaktivieren, um Problemen wÄhrend des Betriebs vorzubeugen:

• Bei einigen Multiprozessorsystemen kann Memory-Mapping die Performance von httpd reduzieren.
• Bei einem per NFS eingebundenen DocumentRoot kann httpd mit einem Speicherzugriffsfehler (Anm.d.ý.: ein so genannter "segmentation fault") abstÝrzen, wenn eine Datei gelÆscht oder gekÝrzt wird, wÄhrend httpd sie im Speicher abbildet.

Bei Serverkonfigurationen, die fÝr dieses Problem anfÄllig sind, sollten Sie das Memory-Mapping fÝr auszuliefernde Dateien deaktivieren, indem Sie schreiben:

Bei per NFS eingebundenen Dateien kann diese Funktion explizit fÝr die stÆrenden Dateien deaktiviert werden, indem Sie angeben:

EnableSendfile-Direktive

Die Direktive steuert, ob httpd die sendfile-UnterstÝtzung des Kernels verwenden kann, um Dateiinhalte an den Client zu Ýbermitteln. Wenn die Bearbeitung einer Anfrage keinen Zugriff auf die Daten in der Datei erfordert -- zum Beispiel bei der Auslieferung einer statischen Datei -- und das Betriebssystem es unterstÝtzt, verwendet der Apache standardmÄúig sendfile, um den Dateiinhalt zu Ýbertragen, ohne die Datei jemals zu lesen.

Der sendfile-Mechanismus vermeidet getrennte Lese- und Sendeoperationen sowie Puffer-Zuweisungen. Bei einigen Plattformen bzw. Dateisystemen deaktivieren Sie diese Funktion jedoch besser, um Probleme wÄhrend des Betriebs zu vermeiden:

• Einige Plattformen besitzen u.U. eine fehlerhafte sendfile-UnterstÝtzung, die das Erstellungssystem nicht erkennt, insbesondere wenn die BinÄrdateien auf einem anderen Rechner erstellt und auf eine solche Maschine mit fehlerhafter sendfile-UnterstÝtzung Ýbertragen wurden.
• Bei einem Ýber das Netzwerk eingebundenen DocumentRoot (z.B. NFS oder SMB) ist der Kernel mÆglicherweise nicht in der Lage, die Netzwerkdatei Ýber seinen eigenen Cache zu bedienen.
• Unter Linux lÆst die Verwendung von sendfile in Verbindung mit bestimmten Netzwerkkarten und IPv6 TCP-Checksummenfehler aus.

Bei Serverkonfigurationen, die fÝr dieses Problam anfÄllig sind, sollten die diese Funktion deaktivieren, indem Sie schreiben:

Bei per NFS oder SMB eingebundenen Dateien kann diese Funktion explizit fÝr die stÆrenden Dateien deaktiviert werden, indem Sie angeben:

ErrorDocument-Direktive

Im Falle eines Problems oder Fehlers kann der Apache konfiguriert werden, eine der vier Aktionen auszufÝhren:

1. Ausgabe einer einfachen, hartkodierten Fehlermeldung
2. Ausgabe einer angepassten Meldung
3. Umleitung zu einem lokalen URL-Pfad der das Problem bzw. den Fehler behandelt
4. Umleitung zu einer externen URL, die das Problem bzw. den Fehler behandelt

Die erste Option ist Voreinstellung, wÄhrend die Optionen 2 bis 4 Ýber die Direktive ErrorDocument eingestellt werden, welcher der HTTP-Statuscode und eine URL oder Nachricht folgen. AbhÄngig vom Problem bzw. Fehler bietet der Apache manchmal zusÄtzliche Informationen an.

URLs kÆnnen bei lokalen Adressen mit einem SchrÄgstrich (/) beginnen oder eine komplette URL bilden, die der Client auflÆsen kann. Alternativ kann eine Nachricht fÝr die Anzeige im Browser angeboten werden. Beispiel:

Auúerdem kann auch der Spezialwert default verwendet werden, um die schlichte, im Apache hartkodierte Nachricht anzugeben. WÄhrend es normalerweise nicht benÆtigt wird, stellt default die einfache, hartkodierte Nachricht des Apache bei Konfigurationen wieder her, bei denen andernfalls eine bestehende ErrorDocument-Anweisung Ýbernommen wÝrde.

Wenn Sie eine ErrorDocument-Anweisung angeben, die auf eine entfernte URL weist (d.h. irgendetwas mit der Methode http davor), beachten Sie bitte, dass der Apache eine Umleitung zum Client sendet, um diesem mitzuteilen, wo das Dokument zu finden ist, auch wenn das Dokument letztlich wieder zum gleichen Server fÝhrt. Das hat mehrere Auswirkungen. Die wichtigste ist, dass der Client nicht den Original-Statuscode erhÄlt sondern statt dessen einen Umleitungs-Statuscode. Dies wiederum kann Web-Robots und andere Clients verwirren, die den Statuscode dazu verwenden, herauszufinden ob eine URL gÝltig ist. Wenn Sie eine entfernte URL in einer Anweisung ErrorDocument 401 verwenden, wird der Client darÝber hinaus nicht wissen, dass er den Benutzer zur Eingabe eines Passwortes auffordern muss, da er den Statuscode 401 nicht erhÄlt. Deshalb mÝssen Sie sich auf ein lokales Dokument beziehen, wenn Sie eine Anweisung ErrorDocument 401 verwenden.

Der Microsoft Internet Explorer (MSIE) ignoriert standardmÄúig serverseitig generierte Fehlermeldungen, wenn sie "zu kurz" sind und ersetzt sie durch eigene "freundliche" Fehlermeldungen. Die GrÆúe variiert abhÄngig von der Art des Fehlers, im Allgemeinen zeigt der MSIE jedoch den serverseitig generierten Fehler, anstatt ihn zu verstecken, wenn Ihr Fehlerdokument grÆúer als 512 Bytes ist. Weitere Informationen sind im Artikel Q294807 in der Microsoft Knowledgebase article verfÝgbar.

In Versionen vor 2.0 wurden Meldungen durch ein einzelnes vorangestelltes AnfÝhrungszeichen (") erkannt.

Siehe auch

• Dokumentation zu individuellen Fehlermeldungen

ErrorLog-Direktive

Die Direktive ErrorLog bestimmt den Namen der Datei, in welcher der Server alle auftretenden Fehler protokolliert werden. Wenn Dateiname nicht absolut ist, wird er relativ zu ServerRoot betrachtet.

Wenn der Dateiname mit einem senkrechten Strich (|, engl.: Pipe) beginnt, wird angenommen, dass es sich um einen Befehl handelt, der ausgefÝhrt wird, um das Fehlerprotokolls zu verarbeiten.

Die Verwendung von syslog anstelle eines Dateinamens aktiviert die Protokollierung mittels syslogd(8), sofern das System es unterstÝtzt. Als Voreinstellung wird der syslog-Typ (syslog facility) local7 verwendet, Sie kÆnnen dies jedoch auch Ýberschreiben, indem Sie die Syntax syslog:facility verwenden, wobei facility einer der Namen sein kann, die Ýblicherweise in syslog(1) dokumentiert sind.

SICHERHEITSHINWEIS: Lesen Sie das Dokument Sicherheitshinweise zu Einzelheiten darÝber, warum Ihre Sicherheit gefÄhrdet sein kann, wenn das Verzeichnis, in dem die Log-Dateien gespeichert werden, fÝr jemand anderen, als den Benutzer, der den Server gestartet hat, beschreibbar ist.

Siehe auch

• LogLevel
• Apache-Log-Dateien

FileETag-Direktive

Wenn dem Dokument eine Datei zugrundeliegt, bestimmt die Direktive FileETag die Dateiattribute, die zur Erstellung des HTTP-Response-Headers ETag (Entity-Tag) verwendet werden. (Der Wert von ETag wird bei der Cache-Verwaltung zur Einsparung von Netzwerk-Bandbreite benutzt.) Im Apache 1.3.22 und frÝher wurde der ETag-Wert stets aus der I-Node, der GrÆúe und dem Datum der letzten änderung (mtime) der Datei gebildet. Die Direktive FileETag erlaubt es Ihnen, zu bestimmen, welche dieser Eigenschaften -- falls Ýberhaupt -- verwendet werden sollen. Die gÝltigen SchlÝsselworte lauten:

INode

Die I-Node-Nummer wird in die Berechnung mit einbezogen

MTime

Datum und Uhrzeit der letzten änderung werden mit einbezogen

Size

Die Anzahl der Bytes in der Datei wird mit einbezogen

All

Alle verfÝgbaren Angaben werden verwendet. Die ist gleichbedeutend mit:

FileETag INode MTime Size

None

Es wird keine ETag-Angabe in die Antwort eingefÝgt, wenn dem Dokument eine Datei zugrundeliegt.

Den SchlÝsselwÆrtern INode, MTime und Size kann entweder ein + oder ein - vorangestellt werden, was die änderung einer Vorgabe erlaubt, die von einem grÆúeren Umfeld geerbt wurde. Jedes SchlÝselwort ohne ein solches Prefix hebt die ererbte Einstellung sofort und vollstÄndig auf.

Wenn die Konfiguration fÝr ein Verzeichnis FileETag INode MTime Size enthÄlt und die eines Unterverzeichnisses FileETag -INode, dann ist die Einstellung fÝr das Unterverzeichnis (die an jedes Unter-Unterverzeichnis weitervererbt wird, welches dies nicht Ýberschreibt) Äquivalent mit FileETag MTime Size.

<Files>-Direktive

Die Direktive <Files> begrenzt die Reichweite der enthaltenen Anweisungen auf Dateinamen. Sie ist vergleichbar mit den Direktiven <Directory> und <Location>. Sie muss eine passende </Files>-Anweisung besitzen. Die innerhalb dieses Abschnittes angegebenen Direktiven werden auf jedes Objekt mit einem Basisnamen (letzte Komponente des Dateinamens) angewendet, der auf die angegebenen Dateinamen passt. <Files>-Container werden, nachdem die <Directory>-Container und .htaccess-Dateien gelesen sind, jedoch vor den <Location>-Containern, in der Reihenfolge ihres Auftretens ausgefÝhrt. Beachten Sie, dass <Files>-Anweisungen innerhalb von <Directory>-Containern auftreten kÆnnen, um den Teil des Dateisystems einzuschrÄnken, den sie betreffen.

Das Argument Dateiname kann einen Dateinamen oder eine Zeichenkette mit Platzhaltern enthalten, wobei ? auf ein einzelnes Zeichen passt und * auf eine beliebige Folge von Zeichen. Erweiterte regulÄre AusdrÝcke kÆnnen ebenfalls verwendet werden, indem das Zeichen ~ hinzugefÝgt wird. Beispielsweise wÝrde

auf die gebrÄuchlichsten Grafikformate im Internet passen. <FilesMatch> wird jedoch bevorzugt.

Beachten Sie bitte, dass die <Files>-Container anders als <Directory>- und <Location>-Container innerhalb von .htaccess-Dateien verwendet werden kÆnnen. Dies erlaubt den Anwendern auf Dateiebene die Kontrolle Ýber ihre eigenen Dateien.

Siehe auch

• Wie die Abschnitte <Directory>, <Location> und <Files> arbeiten fÝr eine ErlÄuterung, wie diese verschiedenen Abschnitte miteinander kombiniert werden, wenn eine Anfrage empfangen wird

<FilesMatch>-Direktive

Die Direktive <FilesMatch> begrenzt wie die Direktive <Files> die enthaltenen Anweisungen auf Dateinamen. Sie akzeptiert jedoch regulÄre AusdrÝcke. Beispielsweise wÝrde

auf die gebrÄuchlichsten Grafikformate im Internet passen.

Siehe auch

• Wie die Abschnitte <Directory>, <Location> und <Files> arbeiten fÝr eine ErlÄuterung, wie diese verschiedenen Abschnitte miteinander kombiniert werden, wenn eine Anfrage empfangen wird

ForceType-Direktive

Wenn sie innerhalb einer .htaccess-Datei, eines <Directory>-, <Location>- <Files>-Containers angegeben wird, erzwingt die Direktive die Auslieferung aller entsprechenden Dateien mit dem Content-Type, der durch MIME-Type definiert wurde. Wenn Sie zum Beispiel ein Verzeichnis voller GIF-Dateien haben, die Sie nicht alle durch .gif kennzeichnen wollen, kÆnnen Sie angeben:

Beachten Sie bitte, dass die Direktive anders als DefaultType alle MIME-Type-Zuordnungen Ýberschreibt, einschlieúlich Dateiendungen, die einen Medientyp bezeichnen kÆnnten.

Sie kÆnnen jede ForceType-Angabe durch die Verwendung des Wertes None Ýberschreiben:

HostnameLookups-Direktive

Diese Direktive aktiviert die DNS-Abfrage (Anm.d.ý.: ein sogenannter DNS-Lookup), so dass Hostnamen protokolliert (und in REMOTE_HOST an CGIs/SSIs Ýbergeben) werden kÆnnnen. Der Wert Double bezieht sich auf ein Double-Reverse-DNS-Lookup. D.h. nachdem ein Reverse-Lookup durchgefÝhrt wurde, wird dann auf dem Ergebnis ein Forward-Lookup ausgefÝhrt. Wenigstens eine der IP-Adressen aus dem Forward-Lookup muss der Originaladresse entsprechen. (In der "tcpwrappers"-Terminologie wird dies PARANOID genannt.)

UnabhÄngig von der Einstellung wird ein Double-Reverse-Lookup durchgefÝhrt, wenn mod_access zur Zugriffskontrolle per Hostnamen eingesetzt wird. Dies ist aus SicherheitsgrÝnden notwendig. Beachten Sie, dass das Ergebnis dieses Double-Reverse-Lookups nicht generell verfÝgbar ist, solange Sie nicht HostnameLookups Double setzen. Wenn beispielsweise nur HostnameLookups On angegeben ist und eine Anfrage fÝr ein Objekt erfolgt, welches durch Hostnamen-BeschrÄnkungen geschÝtzt ist, dann wird CGIs nur das Ergebnis des Singel-Reverse-Lookups in REMOTE_HOST Ýbergeben, egal ob das Doble-Reverse-Lookup fehlschlug oder nicht.

Die Voreinstellung ist Off, um Netzwerktraffic bei den Angeboten einzusparen, die nicht tatsÄchlich Reverse-Lookups benÆtigen. Es ist auch fÝr die Endanwender besser, da sie nicht die zusÄtzliche Wartezeit ertragen mÝssen, die ein Lookup mit sich bringt. Hoch frequentierte Angebote sollten diese Direktive auf Offlassen. Das Hilfsprogramm logresolve, das standardmÄúig in das Unterverzeichnis bin Ihres Installationsverzeichnisses kompiliert wird, kann dazu verwendet werden, um offline Hostnamen von protokollierten IP-Adressen nachzuschlagen.

IdentityCheck-Direktive

Die Direktive ermÆglicht die RFC1413-konforme Protokollierung des entfernten Benutzernamens fÝr jede Verbindung, bei der auf der Client-Maschine identd oder etwas Ähnliches lÄuft. Die Information wird im Zugriffsprotokoll festgehalten.

Der Information sollte auúer fÝr eine rudimentÄre Benutzerverfolgung in keinster Weise vertraut werden.

Beachten Sie bitte, dass dies betrÄchtliche Zeitprobleme beim Zugriff auf Ihren Server verursachen kann, da fÝr jede Anfrage eine solche RÝckfrage durchgefÝhrt werden muss. Wenn Firewalls beteiligt sind, kann unter UmstÄnden jede RÝckfrage fehlschlagen und weitere 30 Sekunden Wartezeit zu jedem Hit zufÝgen. Daher ist dies im Allgemeinen bei Æffentlichen Servern, die im Internet erreichbar sind, nicht besonders sinnvoll.

<IfDefine>-Direktive

Der Container <IfDefine Test>...</IfDefine> wird dazu verwendet, Direktiven als bedingt zu kennzeichnen. Die Direktiven innerhalb eines <IfDefine>-Abschnittes werden nur ausgefÝhrt, wenn Test wahr ist. Ist Test falsch, wird alles zwischen der Start- und Endemarkierung ignoriert.

In der <IfDefine>-Anweisung kann Test eine von zwei Formen annehmen:

• Parametername
• !Parametername

Im ersten Fall werden die Direktiven zwischen der Start- und Endemarkierung nur ausgefÝhrt, wenn der Parameter namens Parametername definiert ist. Die zweite Form kehrt den Test um und fÝhrt die Direktiven nur dann aus, wenn Parametername nicht definiert ist.

Das Argument Parametername ist ein sogenanntes "Define", das beim beim Start des Servers in der httpd-Befehlszeile durch -DParameter angegeben wird.

<IfDefine>-Container kÆnnen ineinander verschachtelt werden, um einfache Multi-Parameter-Tests zu implementieren. Beispiel:

<IfModule>-Direktive

Der Container <IfModule Test>...</IfModule> wird dazu verwendet, Direktiven als abhÄngig von dem Vorhandensein eines speziellen Moduls zu kennzeichnen. Die Direktiven innerhalb eines <IfModule>-Abschnitts werden nur ausgefÝhrt, wenn Test wahr ist. Ist Test falsch, wird alles zwischen der Start- und Endemarkierung ignoriert.

In der <IfModule>-Anweisung kann Test eine von zwei Formen annehmen:

• Modulname
• !Modulname

Im ersten Fall werden die Direktiven zwischen der Start- und Endemarkierung nur ausgefÝhrt, das Modul namens Modulname im Apache enthalten ist -- entweder einkompiliert oder mittels LoadModule dynamisch geladen. Die zweite Form dreht den Test um und fÝhrt die Direktiven nur aus, wenn Modulname nicht enthalten ist.

Das Argument Modulname ist der Dateiname des Moduls zum Zeitpunkt seiner Kompilierung, z.B. mod_rewrite.c. Wenn ein Modul aus mehreren Quelltext-Dateien besteht, verwenden Sie den Namen der Datei, welche die Zeichenfolge STANDARD20_MODULE_STUFF enthÄlt.

<IfModule>-Container kÆnnen inneinander verschachtelt werden, um einfache Multi-Modul-Tests durchzufÝhren.

Dieser Container sollte verwendet werden, wenn Sie eine Konfigurationsdatei benÆtigen, die unabhÄngig davon funktioniert, ob ein bestimmtes Modul verfÝgbar ist oder nicht. Normalerweise ist es nicht notwendig, Direktiven in <IfModule>-Containern unterzubringen.

Include-Direktive

Die Direktive erlaubt das EinfÝgen anderer Konfigurationsdateien in die Konfigurationsdatei des Servers.

Shell-typische (fnmatch()) Platzhlaterzeichen kÆnnen dazu verwendet werden, mehrere Dateien auf einmal in alphabetischer Reihenfolge einzufÝgen. Wenn Include darÝber hinaus auf ein Verzeichnis anstatt auf eine Datei zeigt, liest der Apache alle Dateien in diesem Verzeichnis und allen Unterverzeichnissen ein. Das EinfÝgen ganzer Verzeichnisse ist jedoch nicht empfehlenswert, da temporÄre Dateien sehr leicht versehentlich in einem Verzeichnis zurÝckgelassen werden, was httpd scheitern lassen kann.

Der angegebene Dateiname kann ein absoluter Pfad sein oder relativ zum ServerRoot-Verzeichnis angegeben werden.

Beispiele:

Oder Sie geben Pfade relativ zu Ihrem ServerRoot-Verzeichnis an:

Der Aufruf von apachectl configtest liefert eine Liste der Dateien, die wÄhrend des Konfigurations-Tests verarbeitet werden:

Siehe auch

• apachectl

KeepAlive-Direktive

Die Keep-Alive-Erweiterung von HTTP/1.0 und die HTTP/1.1-FunktionalitÄt persistenter Verbindungen unterstÝtzt langlebige HTTP-Sitzungen, die es erlauben, mehrere Anfragen Ýber die gleich TCP-Verbindung zu senden. In einigen FÄllen wurde eine Beschleunigung der Wartezeiten von beinahe 50% fÝr HTML-Dokumente mit vielen Bildern festgestellt. Um Keep-Alive-Verbindungen zu aktivieren, setzen Sie KeepAlive On.

Bei HTTP/1.0-Clients werden Keep-Alive-Verbindungen nur dann verwendet, wenn sie vom Client eigens angefordert werden. Desweiteren kÆnnen Keep-Alive-Verbindungen bei einem HTTP/1.0-Client nur dann verwendet werden, wenn die LÄnge des Inhalts im Voraus bekannt ist. Dies impliziert, dass dynamische Inhalte wie CGI-Ausgaben, SSI-Seiten und servergenerierte Verzeichnisauflistungen im Allgemeinen keine Keep-Alive-Verbindungen mit HTTP/1.0-Clients verwenden. Bei HTTP/1.1-Clients sind Keep-Alive-Verbindungen Voreinstellung, solange nichts anderes angegeben ist. Wenn der Client es anfordert, wird Chunked-Encoding verwendet, um Inhalte mit unbekannter LÄnge Ýber persistente Verbindungen zu senden.

Siehe auch

• MaxKeepAliveRequests

KeepAliveTimeout-Direktive

Dies legt die Anzahl der Sekunden fest, die der Apache auf weitere Anfragen wartet, bevor er die Verbindung schlieút. Nachdem einmal eine Anfrage entgegen genommen wurde, wird die durch die Direktive Timeout festgelegte Auszeit angewendet.

Auf stark belasteten Servern kann ein hoher KeepAliveTimeout-Wert zu Durchsatzminderungen fÝhren. Je hÆher die Auszeit angegeben ist, desto lÄnger ist der Apache damit beschÄftigt, auf untÄtige Clients zu warten.

<Limit>-Direktive

Zugriffskontrollen gelten normalerweise fÝr alle Zugriffsmethoden, was normalerweise auch das gewÝnschte Verhalten ist. Im Allgemeinen sollten Zugriffskontrollen nicht in einen <Limit>-Container gepackt werden.

Der Sinn der Direktive <Limit> ist es, den Effekt der Zugriffskontrollen auf die angegebenen HTTP-Methoden zu beschrÄnken. Bei allen anderen Methoden haben die in der <Limit>-Gruppe enthaltenen ZugriffsbeschrÄnkungen keine Wirkung. Im folgenden Beispiel gilt die Zugriffskontrolle nur fÝr die Methoden POST, PUT und DELETE. Alle anderen Methoden bleiben ungeschÝtzt:

Sie kÆnnen eine oder mehrere der folgenden Methoden angeben: GET, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK und UNLOCK. Die Methodennamen unterscheiden zwischen Groú- und Kleinschreibung. Wenn GET verwendet wird, sind HEAD-Anfragen ebenfalls eingeschrÄnkt. Die TRACE-Methode kann nicht limitiert werden.

<LimitExcept>-Direktive

<LimitExcept> und </LimitExcept> werden dazu verwendet, eine Gruppe von Anweisungen zur Zugriffskontrolle zusammenzufassen, die dann auf jede HTTP-Methode angewendet werden, die nicht als Argument angegeben ist. D.h. dies ist das Gegenteil des <Limit>-Containers und kann zur Steuerung von Standard- und nicht-Standard-/unbekannten Methoden verwendet werden. FÝr weitere Einzelheiten lesen Sie bitte die Beschreibung zu <Limit>.

Beispiel:

LimitInternalRecursion-Direktive

Eine interne Umleitung erfolgt beispielsweise, wenn die Direktive Action verwendet wird, welche die Originalanfrage intern zu einem CGI-Skript weiterleitet. Eine Unteranfrage (Anm.d.ý.: engl. Subrequest) ist ein Mechanismus des Apache, um herauszufinden, was bei einer URI geschehen wÝrde, wÄre sie angefordert worden. mod_dir z.B. verwendet Unteranfragen, um nach den Dateien zu suchen, die in der DirectoryIndex-Anweisung aufgefÝhrt sind.

LimitInternalRecursion bewahrt den Server vor einem Absturz, wenn er in eine Endlosschleife aus internen Umleitungen oder Unteranfragen hineinlÄuft. Derartige Schleifen werden gewÆhnlich durch Fehlkonfiguration verursacht.

Die Direktive setzt zwei verschiedene Begrenzungen, welche je Anfrage ausgewertet werden. Die erste Zahl bestimmt die maximale Anzahl der Umleitungen, die aufeinander folgen dÝrfen. Die zweite Zahl legt fest, wie tief Unteranfragen ineinander verschachtelt werden dÝrfen. Wenn Sie lediglich eine Zahl angeben, wird sie beiden Begrenzungen zugewiesen.

LimitRequestBody-Direktive

Die Direktive gibt die Anzahl der Bytes zwischen 0 (unbegrenzt) und 2147483647 (2GB) an, die im Request-Body (Datenteil der Anfrage) erlaubt sind.

Die Direktive LimitRequestBody erlaubt es dem Benutzer, die GrÆúe des HTTP-Request-Bodys in dem Kontext zu begrenzen, in dem die Anweisung angegeben ist (Server, pro Verzeichnis, pro Datei oder pro Adresse). Wenn die Anfrage des Clients dieses Limit Ýberschreitet, gibt der Server einen Fehler zurÝck anstatt die Anfrage zu bearbeiten. Die GrÆúe des Datenteils einer Anfrage kann sehr stark variieren, abhÄngig von der Art der Ressource und den fÝr diese Ressource erlaubten Methoden. CGI-Skripte verwenden den Datenteil Ýblicherweise zum Empfang von Formulardaten. Wird die PUT-Methode angewendet, dann muss der Wert mindestens so groú sein wie irgendeine Darstellungsform, die der Server fÝr diese Ressource akzeptieren soll.

Die Direktive gibt dem Serveradministrator eine grÆúere Kontrolle gegenÝber abnormalem Verhalten von Clients, was bei der Vermeidung einiger Formen von Denial-of-Service-Attacken hilfreich sein kann.

Wenn Sie beispielsweise das Hochladen von Dateien zu einer bestimmten Adresse erlauben, aber die GrÆúe der hochgeladenen Dateien auf 100K beschrÄnken wollen, kÆnnen Sie die folgende Anweisung verwenden:

LimitRequestFields-Direktive

Anzahl ist ein Integer-Wert (eine positive Ganzzahl) zwischen 0 (unbegrenzt) und 32767. Die Voreinstellung wird durch die Konstante DEFAULT_LIMIT_REQUEST_FIELDS (100 bei der Auslieferung) zur Kompilierungszeit gesetzt.

Die Direktive LimitRequestFields erlaubt es dem Serveradministrator, die maximale Anzahl der in einem HTTP-Request erlaubten HTTP-Request-Header zu verÄndern. FÝr den Server muss dieser Wert grÆúer sein als die Anzahl der Headerzeilen, die ein normaler Client senden kÆnnte. Die Anzahl der Request-Header, die ein gewÆhnlicher Client verwendet, Ýberschreitet selten 20 Zeilen. Allerdings kann dies zwischen den verschiedenen Client-AusfÝhrungen variieren, oft abhÄngig vom Ausmaú, mit dem der Anwender die genaue Content-Negotiation-UnterstÝtzung seines Browsers konfiguriert hat. Optionale HTTP-Erweiterungen Äuúern sich oft in Form von HTTP-Headern.

Die Direktive gibt dem Serveradministrator eine grÆúere Kontrolle gegenÝber abnormalem Verhalten von Clients, was bei der Vermeidung einiger Formen von Denial-of-Service-Attacken hilfreich sein kann. Der Wert sollte erhÆht werden, wenn normale Clients eine Fehlermeldung vom Server erhalten, die besagt, dass mit der Anfrage zu viele Headerzeilen gesendet wurden.

Beispiel:

LimitRequestFieldSize-Direktive

Die Direktive gibt die Anzahl der Bytes zwischen 0 und dem Wert der zur Kompilierungszeit definierten Konstante DEFAULT_LIMIT_REQUEST_FIELDSIZE (8190 bei der Auslieferung) an, die in einem HTTP-Header erlaubt sind.

Die Direktive LimitRequestFieldsize erlaubt es dem Serveradministrator, die maximale GrÆúe eines HTTP-Request-Headers auf einen Wert unterhalb der normalen, im Server einkompilierten GrÆúe des Eingabepuffers zu verringern. FÝr den Server muss der Wert groú genug sein, um eine beliebige Headerzeile einer normalen Client-Anfrage vorzuhalten. Die GrÆúe variiert stark zwischen den verschiedenen Client-AusfÝhrungen, oft abhÄngig vom Ausmaú, mit dem der Anwender die genaue Content-Negotiation-UnterstÝtzung seines Browsers konfiguriert hat.

Die Direktive gibt dem Serveradministrator eine grÆúere Kontrolle gegenÝber abnormalem Verhalten von Clients, was bei der Vermeidung einiger Formen von Denial-of-Service-Attacken hilfreich sein kann.

Beispiel:

LimitRequestLine-Direktive

Die Direktive legt die Anzahl der Bytes zwischen 0 und dem Wert der zur Kompilierungszeit definierten Konstante DEFAULT_LIMIT_REQUEST_LINE (8190 bei der Auslieferung) fest, die in der HTTP-Anfragezeile erlaubt sind.

Die Direktive LimitRequestLine erlaubt es dem Serveradministrator, die maximale GrÆúe der HTTP-Anfragezeile auf einen Wert unterhalb der normalen, im Server einkompilierten GrÆúe des Eingabepuffers zu verringern. Da die Anfragezeile aus der HTTP-Methode, der URI und der Protokollversion besteht, bedeutet die LimitRequestLine-Direktive eine BeschrÄnkung der LÄnge der fÝr eine Anfrage an den Server erlaubten Anfrage-URI. FÝr den Server muss der Wert groú genug sein, um jeden seiner Ressourcennamen vorzuhalten, einschlieúlich aller Informationen, die im Query-String einer GET-Anfrage Ýbergeben werden kÆnnen.

Die Direktive gibt dem Serveradministrator eine grÆúere Kontrolle gegenÝber abnormalem Verhalten von Clients, was bei der Vermeidung einiger Formen von Denial-of-Service-Attacken hilfreich sein kann.

Beispiel:

LimitXMLRequestBody-Direktive

Dies gibt die Grenze fÝr die maximale GrÆúe (in Bytes) des XML-basierten Request-Bodys an. Der Wert 0 deaktiviert diese PrÝfung.

Beispiel:

<Location>-Direktive

Die Direktive <Location> begrenzt die Reichweite der enthaltenen Anweisungen auf URLs. Sie ist der Direktive <Directory> Ähnlich und startet einen Abschnitt, der mit der Anweisung </Location> abgeschlossen wird. <Location>-Container werden, nachdem die <Directory>-Container und .htaccess-Dateien gelesen wurden, und nach den <Files>-Containern, in der Reihenfolge ausgefÝhrt, in der sie in der Konfigurationsdatei erscheinen.

<Location>-Abschnitte operieren vollstÄndig auúerhalb des Dateisystems. Dies hat mehrere Konsequenzen. An Wichtigsten, <Location>-Anweisungen sollten nicht dafÝr verwendet werden, den Zugriff zu Teilen des Dateisystems zu steuern. Da mehrere unterschiedliche URLs auf die gleiche Stelle des Dateisystems zeigen kÆnnen, kÆnnte eine solche Zugriffskontrolle u.U. umgangen werden.

FÝr alle nicht-Proxy-Anfragen ist die entsprechende URL ein URL-Pfad in der Form /path/. Es dÝrfen weder ein Schema, noch ein Hostname, noch ein Port, noch ein Query-String einbezogen werden. FÝr Proxy-Anfragen hat die Vergleichs-URL die Form schema://servername/path. Das PrÄfix muss angegeben werden.

Die URL kann Platzhalter verwenden. In einer Zeichenfolge mit Platzhaltern entspricht ? einem einzelnen Zeichen und *einer beliebigen Zeichenfolge.

Erweiterte regulÄre AusdrÝcke kÆnnen ebenfalls verwendet werden, indem das Zeichen ~ hinzugefÝgt wird. Beispielsweise wÝrde

auf URLs passen, welche die Zeichenfolge /extra/data oder /special/data enthalten. Die Direktive <LocationMatch> verhÄlt sich genauso wie <Location> mit regulÄren AusdrÝcken.

Die FunktionalitÄt von <Location> ist insbesondere dann nÝtzlich, wenn sie mit der SetHandler-Direktive kombiniert wird. Um zum Beispiel Statusabfragen zu aktivieren, sie aber nur von Browsern aus foo.com zuzulassen, kÆnnten Sie schreiben:

Siehe auch

• Wie die Abschnitte <Directory>, <Location> und <Files> arbeiten fÝr eine ErlÄuterung, wie diese verschiedenen Abschnitte miteinander kombiniert werden, wenn eine Anfrage empfangen wird

<LocationMatch>-Direktive

Die Direktive <LocationMatch> begrenzt die Reichweite der enthaltenen Anweisungen in der gleichen Weise wie <Location> auf URLs. Sie verwendet jedoch regulÄre AusdrÝcke als Argument anstelle einer einfachen Zeichenkette. Beispielsweise wÝrde

auf URLs passen, welche die Zeichenfolge /extra/data oder /special/data enthalten.

Siehe auch

• Wie die Abschnitte <Directory>, <Location> und <Files> arbeiten fÝr eine ErlÄuterung, wie diese verschiedenen Abschnitte miteinander kombiniert werden, wenn eine Anfrage empfangen wird

LogLevel-Direktive

LogLevel stellt die AusfÝhrlichkeit der Nachrichten ein, die im Fehlerprotokoll aufgezeichnet werden (siehe Direktive ErrorLog). Die folgenden, nach absteigender Aussagekraft sortierten Level sind verfÝgbar:

Geben Sie einen bestimmten Level an, denn werden Nachrichten von allen hÆheren Leveln ebenso angezeigt. Z.B.: Wenn LogLevel info eingestellt ist, dann werden Nachrichten der Log-Level notice und warn ebenso eingetragen.

Es wird empfohlen, mindestens den Level crit zu verwenden.

Beispiel:

MaxKeepAliveRequests-Direktive

Die Direktive MaxKeepAliveRequests begrenzt die Anzahl der Anfragen, die pro Verbindung zulÄssig sind, wenn KeepAlive eingeschaltet ist. Bei der Einstellung 0 sind unbegrenzt viele Anfragen erlaubt. Wir empfehlen fÝr diese Einstellung einen hohen Wert fÝr eine maximale Serverleistung.

Beispiel:

NameVirtualHost-Direktive

Die Direktive NameVirtualHost ist erforderlich, wenn Sie namensbasierte virtuelle Hosts konfigurieren mÆchten.

Obwohl Adresse eine Hostname sein kann, wird empfohlen, dass Sie stets eine IP-Adresse verwenden, z.B.:

Mit der NameVirtualHost-Anweisung geben Sie die IP-Adresse an, unter der der Server Anfragen fÝr namensbasierte virtuelle Hosts entgegennimmt. Das ist Ýblicherweise die Adresse, zu der die Namen Ihrer namensbasierten virtuellen Hosts aufgelÆst werden. Falls eine Firewall oder ein anderer Proxy die Anfrage in Empfang nimmt und Sie zu einer weiteren IP-Adresse des Servers weiterleitet, mÝssen Sie die IP-Adresse der physikalischen Schnittstelle der Maschine angeben, welche die Anfragen bedient. Wenn Sie mehrere namensbasierte Hosts an verschiedenen Adressen betreiben, wiederholen Sie einfach die Anweisung fÝr jede Adresse.

Optional kÆnnen Sie die Nummer eines Ports angeben, an dem namensbasierte virtuelle Hosts verwendet werden sollen. Beispiel:

IPv6-Adressen mÝssen, wie im folgenden Beispiel angegeben, in eckige Klammern eingeschlossen werden:

Um an allen Schnittstellen Anfragen zu empfangen, kÆnnen Sie * als Argument verwenden.

Siehe auch

• Dokumentation zu virtuellen Hosts

Options-Direktive

Die Direktive Options steuert, welche Eigenschaften bzw. Funktionen in einem bestimmten Verzeichnis verfÝgbar sind.

Option kann auf None gesetzt werden, wobei keine der besonderen Eigenschaften verfÝgbar sind, oder auf eines oder mehrere der folgenden:

All

Alle Optionen auúer MultiViews. Dies ist die Voreinstellung.

ExecCGI

Die AusfÝhrung von CGI-Skripten, welche mod_cgi verwenden, ist erlaubt.

FollowSymLinks

Der Server folgt symbolischen Links in diesem Verzeichnis.

Auch wenn der Server symbolischen Links folgt, bedeutet dies nicht, dass der zum Abgleich gegen <Directory>-Abschnitte verwendete Pfadname wechselt.

Beachten Sie auch, dass diese Option innerhalb eines <Location>-Abschnitts ignoriert wird.

Includes

Server Side Includes, die von mod_include bereitgestellt werden, sind erlaubt.

IncludesNOEXEC

Server Side Includes sind erlaubt, #exec cmd und #exec cgi sind jedoch deaktiviert. Es ist aber noch mÆglich, CGI-Skripte aus ScriptAlias-Verzeichnissen mittels #include virtual einzubinden.

Indexes

Wenn eine URL, die auf ein Verzeichnis zeigt, in dem sich keine durch DirectoryIndex definierte Indexdatei (z.B. index.html) befindet, dann liefert mod_autoindex eine formatierte Auflistung des Verzeichnisses zurÝck.

MultiViews

"MultiViews" sind bei der Verwendung von mod_negotiation erlaubt (siehe Content-Negotiation).

SymLinksIfOwnerMatch

Der Server folgt nur symbolischen Links, bei denen die Zieldatei bzw. das Zielverzeichnis der gleichen Benutzerkennung gehÆrt, wie der Link.

Anmerkung

Diese Option wird innerhalb eines <Location>-Abschnitts ignoriert.

Wenn mehrere Options auf ein Verzeichnis angewandt werden kÆnnen, dann wird normalerweise die spezifischste (Anm.d.ý.: Gemeint ist die zuletzt ausgefÝhrte Option.) verwendet und alle anderen werden ignoriert; die Optionen werden nicht vermischt. (Siehe auch Wie Abschnitte zusammengefÝhrt werden..) Wenn jedoch allen Optionen der Options-Anweisung eines der Zeichen + oder - vorangestellt wird, werden die Optionen zusammengemischt. Jede Option mit vorangestelltem + wird zu den momentan gÝltigen Optionen hinzugefÝgt und jede Option mit vorangestelltem - wird aus den derzeit gÝltigen Optionen entfernt.

So wird zum Beispiel ohne die Zeichen + und -

fÝr das Verzeichnis /web/docs/spec wird jetzt lediglich Includes gesetzt. Wenn die zweite Options-Anweisung jedoch +- und --Zeichen verwenden wÝrde,

dann wÝrden die Optionen FollowSymLinks und Includes fÝr das Verzeichnis /web/docs/spec gesetzt.

Die Voreinstellung ist All, sofern keine anderen Angaben gemacht wurden.

Require-Direktive

Die Direktive wÄhlt aus, welche authentisierten Benutzer auf eine Ressource zugreifen dÝrfen. Folgende Syntax ist erlaubt:

Require user User-ID [User-ID] ...

Nur die genannten Benutzer dÝrfen auf die Ressource zugreifen.

Require group Gruppenname [Gruppenname] ...

Nur Benutzer der genannten Gruppen dÝrfen auf die Ressource zugreifen.

Require valid-user

Alle gÝltigen Benutzer dÝrfen auf die Ressource zugreifen.

Require muss von den Direktiven AuthName und AuthType sowie Direktiven wie AuthUserFile und AuthGroupFile (zur Definition von Benutzern und Gruppen) begleitet werden, um korrekt zu funktionieren. Beispiel:

Zugriffskontrollen, die in dieser Form angewandt werden, gelten fÝr alle Methoden. Dies ist normalerweise gewÝnscht. Wenn Sie Zugriffskontrollen nur auf bestimmte Methoden anwenden mÆchten, wÄhrend andere Methoden ungeschÝtzt bleiben, dann mÝssen Sie die Require-Anweisung innerhalb eines <Limit>-Abschnitts platzieren.

Siehe auch

• Satisfy
• mod_access

RLimitCPU-Direktive

Akzeptiert einen oder zwei Parameter. Der erste Paramater setzt eine weiche Ressourcenbegrenzung fÝr alle Prozesse, der zweite Parameter setzt die Maximalgrenze fÝr die Ressourcennutzung. Jeder der Parameter kann eine Zahl oder max sein. max zeigt dem Server an, dass das vom Betriebssystem erlaubte Maximum verwendet werden soll. Das Anheben der maximal erlaubten Ressourcennutzung erfordert, dass der Server als root lÄuft, zumindest in der anfÄnglichen Startphase.

Dies wird auf Prozesse angewendet, die von Anfragen bearbeitenden Apache-Kindprozessen abgespalten werden, nicht auf die Apache-Kindprozesse selbst. Das beinhaltet CGI-Skripte und SSI-exec-Befehle, nicht jedoch Prozesse, die vom Apache-Elternprozess abgespalten werden, wie z.B. Protokollierung.

CPU-Ressourcenbegrenzung wird in Sekunden pro Prozess ausgedrÝckt.

Siehe auch

• RLimitMEM
• RLimitNPROC

RLimitMEM-Direktive

Akzeptiert einen oder zwei Parameter. Der erste Paramater setzt eine weiche Ressourcenbegrenzung fÝr alle Prozesse, der zweite Parameter setzt die Maximalgrenze fÝr die Ressourcennutzung. Jeder der Parameter kann eine Zahl oder max sein. max zeigt dem Server an, dass das vom Betriebssystem erlaubte Maximum verwendet werden soll. Das Anheben der maximal erlaubten Ressourcennutzung erfordert, dass der Server als root lÄuft, zumindest in der anfÄnglichen Startphase.

Dies wird auf Prozesse angewendet, die von Anfragen bearbeitenden Apache-Kindprozessen abgespalten werden, nicht auf die Apache-Kindprozesse selbst. Das beinhaltet CGI-Skripte und SSI-exec-Befehle, nicht jedoch Prozesse, die vom Apache-Elternprozess abgespalten werden, wie z.B. Protokollierung.

Die Begrenzung des Speicherverbrauchs wird in Bytes pro Prozess ausgedrÝckt.

Siehe auch

• RLimitCPU
• RLimitNPROC

RLimitNPROC-Direktive

Akzeptiert einen oder zwei Parameter. Der erste Paramater setzt eine weiche Ressourcenbegrenzung fÝr alle Prozesse, der zweite Parameter setzt die Maximalgrenze fÝr die Ressourcennutzung. Jeder der Parameter kann eine Zahl oder max sein. max zeigt dem Server an, dass das vom Betriebssystem erlaubte Maximum verwendet werden soll. Das Anheben der maximal erlaubten Ressourcennutzung erfordert, dass der Server als root lÄuft, zumindest in der anfÄnglichen Startphase.

Dies wird auf Prozesse angewendet, die von Anfragen bearbeitenden Apache-Kindprozessen abgespalten werden, nicht auf die Apache-Kindprozesse selbst. Dies beinhaltet CGI-Skripte und SSI-exec-Befehle, nicht jedoch Prozesse, die vom Apache-Elternprozess abgespalten werden, wie z.B. Protokollierung.

Prozessbegrenzungen steuern die Anzahl der Prozesse pro Benutzer.

Siehe auch

• RLimitMEM
• RLimitCPU

Satisfy-Direktive

Verfahrensweise fÝr den Zugriff, falls sowohl Allow als auch Require verwendet werden. Der Parameter kann entweder All oder Any sein. Die Direktive ist nur dann nÝtzlich, wenn der Zugriff zu einem bestimmten Bereich durch Benutzername/Passwort und Clientrechner-Adressen eingeschrÄnkt ist. In diesem Fall verlangt die Voreinstellung (All), dass der Client die AdressbeschrÄnkung passiert und eine gÝltige Benutzerkennung und ein gÝltiges Passwort Ýbermittelt. Mit der Auswahl Any wird dem Client der Zugriff erlaubt, wenn er entweder die Rechner-BeschÄnkung passiert oder einen gÝltigen Benutzernamen und ein gÝltiges Passwort Ýbermittelt. Dies kann verwendet werden, um einen Bereich mit einem Passwort zu schÝtzen, jedoch Clients von bestimmten Adressen ohne Abfrage des Passwortes zuzulassen.

Wenn Sie beispielsweise mÆchten, dass Personen aus Ihrem privaten Netzwerk unbechÄnkten Zugriff zu Teilen Ihres Webangebots haben, jedoch verlangen, dass Personen auúerhalb Ihres privaten Netzwerks ein Passwort Ýbergeben mÝssen, kÆnnen Sie eine Konfiguration Ähnlich der folgenden verwenden:

Seit Version 2.0.51 kÆnnen Satisfy-Anweisungen durch <Limit>- und <LimitExcept>-Abschnitte auf bestimmte Methoden beschrÄnkt werden.

Siehe auch

• Allow
• Require

ScriptInterpreterSource-Direktive

Die Direktive steuert, wie der Apache den Interpreter zur AusfÝhrung von CGI-Skripten bestimmt. Die Voreinstellung ist Script. Dies veranlaút den Apache, den Interpreter zu verwenden, auf den die Shebang-Zeile (erste Zeile, beginnt mit #!) im Skript zeigt. Auf Win32-Systemen sieht diese Zeile Ýblicherweise so aus:

oder, wenn perl im Pfad (Umgebungsvariable PATH) liegt, einfach:

Die Einstellung ScriptInterpreterSource Registry veranlaút eine Suche in HKEY_CLASSES_ROOT der Windows-Registrierungsdatenbank und verwendet die Endung der Skript-Datei (z.B. .pl) als Suchargument. Der durch den UnterschlÝssel Shell\ExecCGI\Command oder, falls dieser nicht existiert, Shell\Open\Command definierte Befehl wird zum æffnen der Skript-Datei verwendet. Wenn die RegistrierungsschlÝsel nicht gefunden werden, dann verwendet der Apache die Option Script.

Die seit Apache 2.0 neue Option Registry-Strict macht das gleiche wie Registry, verwendet jedoch nur den UnterschlÝssel Shell\ExecCGI\Command. Der SchlÝssel ExecCGI ist gewÆhnlich nicht voreingestellt. Er muss manuell in der Windows-Registrierungsdatenbank eingerichtet werden und verhindert dann versehentlicht Programmaufrufe auf Ihrem System.

ServerAdmin-Direktive

ServerAdmin legt die E-Mail-Adresse fest, die der Server in jede Fehlermeldung einfÝgt, die er an den Client zurÝckschickt.

Es kann sich lohnen, hierfÝr eine reservierte Adresse anzugeben, z.B.

da Anwender nicht unbedingt erwÄhnen, dass sie vom Server sprechen!

ServerAlias-Direktive

Die Direktive ServerAlias bestimmt die alternativen Namen eines Hosts zur Verwendung mit namensbasierten virtuellen Hosts.

Siehe auch

• Apache-Dokumentation zu virtuellen Hosts

ServerName-Direktive

Die Direktive ServerName bestimmt den Rechnernamen und Port, den der Server dazu verwendet, sich selbst zu identifizieren. Diese werden bei der Erstellung von Umleitungs-URLs benÆtigt. Wenn beispielsweise der Name der Maschine, die den Webserver beherbergt, simple.example.com lautet, die Maschine jedoch auch einen DNS-Alias www.example.com besitzt und Sie den Webserver so identifizieren mÆchten, sollten Sie die folgende Anweisung verwenden:

Wenn kein ServerName angegeben wurde, dann versucht der Server den Rechnernamen mittels eines Reverse-Lookup herzuleiten. Wenn kein Post in der ServerName-Anweisung angegeben wurde, dann verwendet der Server den Port der eingegangenen Anfrage. FÝr eine optimale ZuverlÄssigkeit und Berechenbarkeit sollten Sie einen eindeutigen Rechnernamen und Port angeben, in dem Sie die Direktive ServerName verwenden.

Wenn Sie namensbasierte virtuelle Hosts verwenden, gibt ServerName innerhalb eines <VirtualHost>-Abschnitts an, welcher Hostname im Host:-Header der Anfrage auftauchen muss, damit sie diesem virtuellen Host zugeordnet wird.

Lesen Sie bitte die Beschreibung der Direktive UseCanonicalName fÝr Einstellungen, die bestimmen, ob selbstreferenzierende URLs (z.B. vom Modul mod_dir) auf den angegebenen Port zeigen oder auf die Portnummern die in der Anfrage des Clients angegeben ist.

Siehe auch

• Probleme bezÝglich DNS und Apache
• Apache-Dokumentation zu virtuellen Hosts
• UseCanonicalName
• NameVirtualHost
• ServerAlias

ServerPath-Direktive

Die Direktive ServerPath legt den veralteten (Anm.d.ý.: Gemeint ist eigentlich "Altlast" aufgrund antiquierter Clients.) URL-Pfad eines Hosts zur Verwendung mit namensbasierten virtuellen Hosts fest.

Siehe auch

• Apache-Dokumentation zu virtuellen Hosts

ServerRoot-Direktive

Die Direktive ServerRoot bestimmt das Verzeichnis, in dem der Server installiert ist. ýblicherweise enthÄlt es die Unterverzeichnisse conf/ und logs/. Relative Pfadangaben anderer Direktiven (wie z.B. Include oder LoadModule) werden relativ zu diesem Verzeichnis betrachtet.

Siehe auch

• Die httpd-Option -d
• Sicherheitshinweise fÝr Informationen, wie die Rechte auf das ServerRoot-Verzeichnis richtig gesetzt werden

ServerSignature-Direktive

Die Direktive ServerSignature ermÆglicht die Gestaltung einer unter servergenerierten Dokumenten (z.B. Fehlerdokumente, FTP-Verzeichnislisten von mod_proxy, mod_info-Ausgaben, ...) angefÝgten Fuúzeile. Ein mÆglicher Grund fÝr die Aktivierung einer solchen Fuúzeile ist, dass der Anwender bei einer Kette von Proxy-Servern oft keine MÆglichkeit hat, zu erkennen, welcher der verketteten Server gegenwÄrtig die zurÝckgegebene Fehlermeldung produziert hat.

Die (Vor-)Einstellung Off unterdrÝckt die Fuúzeile (und ist damit kompatibel zum Verhalten des Apache 1.2 und frÝher). Die Einstellung On fÝgt schlicht eine Zeile mit der Versionsnummer des Servers und dem Servernamen (ServerName) des bedienenden virtuellen Hosts an. Die Einstellung EMail erstellt zusÄtzlich einen "mailto:"-Verweis zum Serveradministrator (ServerAdmin) des referenzierten Dokuments.

Ab Version 2.0.44 werden die Details der angegebenen Versionsnummer des Servers von der Direktive ServerTokens kontrolliert.

Siehe auch

• ServerTokens

ServerTokens-Direktive

die Direktive steuert, ob der Response-Header Server, der an den Client zurÝckgesendet wird, eine Beschreibung des allgemeinen Betriesbsystemtyps des Servers wie auch Informationen Ýber einkompilierte Module enthÄlt.

ServerTokens Prod[uctOnly]

Der Server sendet (z.B.): Server: Apache

ServerTokens Major

Der Server sendet (z.B.): Server: Apache/2

ServerTokens Minor

Der Server sendet (z.B.): Server: Apache/2.0

ServerTokens Min[imal]

Der Server sendet (z.B.): Server: Apache/2.0.41

ServerTokens OS

Der Server sendet (z.B.): Server: Apache/2.0.41 (Unix)

ServerTokens Full (oder nicht angegeben)

Der Server sendet (z.B.): Server: Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2

Diese Einstellung gilt fÝr den gesamten Server und kann nicht auf Virtual-Host-Basis aktiviert oder deaktiviert werden.

Ab Version 2.0.44 steuert diese Direktive auch die Informationen, die durch die Direktive ServerSignature angeboten werden.

Siehe auch

• ServerSignature

SetHandler-Direktive

Wenn die Direktive innerhalb einer .htaccess-Datei oder in einem <Directory>- oder <Location>-Abschnitt angegeben wird, erzwingt sie, dass alle entsprechenden Dateien von dem durch Handlername angegebenen Handler analysiert werden. Wenn Sie beispielsweise ein Verzeichnis haben, dessen Dateien unabhÄngig von der Endung gÄnzlich als Image-Maps interpretiert werden sollen, kÆnnen Sie folgendes in eine .htaccess-Datei in dem Verzeichnis schreiben:

Noch ein Beispiel: wenn Sie den Server immer, wenn die URL http://servername/status aufgerufen wird, einen Statusbericht anzeigen lassen mÆchten, dann kÆnnen Sie folgendes in die httpd.conf schreiben:

Sie kÆnnen eine zuvor definierte SetHandler-Anweisung aufheben, indem Sie den Wert None verwenden.

Siehe auch

• AddHandler

SetInputFilter-Direktive

Die Direktive SetInputFilter bestimmt den oder die Filter, die Client-Anfragen und POST-Eingaben verarbeiten, wenn sie vom Server empfangen werden. Diese gelten zusÄtzlich zu anderweitig definierten Filtern, einschlieúlich denen der Direktive AddInputFilter.

Wenn mehr als ein Filter angegeben wird, dann mÝssen diese durch Semikolon voneinander getrennt in der Reihenfolge angegeben werden, in der sie die Daten verarbeiten sollen.

Siehe auch

• Filter-Dokumentation

SetOutputFilter-Direktive

Die Direktive SetOutputFilter bestimmt die Filter, die Antworten des Servers verarbeiten, bevor sie an den Client gesendet werden. Diese gelten zusÄtzlich zu anderweitig definierten Filtern, einschlieúlich denen der Direktive AddOutputFilter.

Die folgende Konfiguration verarbeitet zum Beispiel alle Dateien im Verzeichnis /www/data als Server Side Includes.

Wenn mehr als ein Filter angegeben wird, dann mÝssen diese durch Semikolon voneinander getrennt in der Reihenfolge angegeben werden, in der sie die Daten verarbeiten sollen.

Siehe auch

• Filter-Dokumentation

TimeOut-Direktive

Die Direktive TimeOut definiert derzeit die Zeitspanne, die der Apache auf drei Dinge wartet:

1. Die gesamte Zeispanne, die benÆtigt wird, um eine GET-Anfrage zu empfangen.
2. Die Zeitspanne zwischen dem Empfang von TCP-Paketen einer POST- oder PUT-Anfrage.
3. Die Zeitspanne zwischen ACKs bei der ýbermittlung der TCP-Pakete der Antwort.

Wir haben vor, diese Zeitspannen in Zukunft separat konfigurierbar zu machen. Vor Version 1.2 war der Zeitgeber auf 1200 voreingestellt, wurde dann aber auf 300 herabgesetzt, was immer noch weit mehr ist, als in den meisten Situationen benÆtigt wird. Die Voreinstellung wurde nicht weiter herabgesetzt, da gelegentlich noch Stellen im Code existieren kÆnnen, wo der Zeitgeber nicht zurÝckgesetzt wird, wenn ein Paket verschickt wird.

UseCanonicalName-Direktive

In vielen Situationen muss der Apache eine selbstreferenzierende URL -- d.h. eine URL, die auf den selben Server zurÝck verweist -- zusammenbauen. Bei UseCanonicalName On verwendet der Apache den Hostnamen und Port, der in der ServerName-Anweisung angegeben ist, um den kanonischen Namen des Servers zu erstellen. Dieser Name wird in allen selbstreferenzierenden URLs sowie in CGI-Skripten fÝr die Werte von SERVER_NAME und SERVER_PORT verwendet.

Bei UseCanonicalName Off bildet der Apache selbstreferenzierende URLs, indem er den vom Client Ýbermittelten Hostnamen und Port verwendet, sofern diese vorhanden sind (andernfalls wird der kanonische Name, wie oben beschrieben, benutzt). Die Werte sind die gleichen, die zur Anwendung von namensbasierten virtuellen Hosts verwendet werden, und sie sind mit den gleichen Clients verfÝgbar (Anm.d.ý.: , die auch in der Lage sind, auf namensbasierte virtuelle Hosts zuzugreifen, d.h. einen Host-Header mitschicken). Die CGI-Variablen SERVER_NAME und SERVER_PORT werden ebenfalls aus den vom Client angeboten Werten erstellt.

Ein Intranet-Server, auf den Anwender mit kurzen Namen wie www zugreifen, ist ein Beispiel, wo dies sinnvoll sein kann. Sie werden bemerken, dass der Apache den Benutzer auf http://www.domain.com/splat/ umleitet, wenn dieser einen Kurznamen und eine URL, die einem Verzeichnis entspricht, ohne abschlieúenden SchrÄgstrich eingibt, wie z.B. http://www/splat. Wenn Sie Authentisierung aktiviert haben, bewirkt dies, dass der Benutzer sich zweimal identifizieren muss (einmal fÝr www und noch einmal fÝr www.domain.com -- lesen Sie fÝr weitere Informationen die FAQ zu diesem Thema). Wenn UseCanonicalName jedoch auf Off gesetzt ist, denn wird der Apache zu http://www/splat/ umleiten.

Es existiert noch eine dritte Option, UseCanonicalName DNS, die fÝr den Betrieb von IP-basierten Massen-Virtual-Hosts gedacht ist, um antiquierte Clients zu unterstÝtzen, die keinen Host:-Header bereit stellen. Um selbstreferenzierende URLs zu ermitteln, fÝhrt der Apache bei dieser Option ein Reverse-DNS-Lookup auf die IP-Adresse des Servers aus, zu der der Client Verbindung aufgenommen hat.

Siehe auch

• ServerName
• Listen

<VirtualHost>-Direktive

<VirtualHost> und </VirtualHost> werden dazu verwendet, eine Gruppe von Direktiven zusammenzufassen, die nur auf einen bestimmten virtuellen Host angewendet werden. Jede Direktive, die im Virtual-Host-Kontext zulÄssig ist, kann verwendet werden. Wenn der Server eine Anfrage fÝr ein bestimmtes Dokument eines bestimmten virtuellen Hosts empfÄngt, dann benutzt er die im <VirtualHost>-Container enthaltenen Konfigurationsanweisungen. Adresse kann sein:

• Die IP-Adresse des virtuellen Hosts.
• Ein voll qualifizierter Domainname fÝr die IP-Adresse des virtuellen Hosts.
• Das Zeichen *, welches nur in Kombination mit NameVirtualHost * verwendet wird, um allen IP-Adressen zu entsprechen.
• Die Zeichenkette _default_, die nur mit IP-basierten virtuellen Hosts verwendet wird, um nicht zugewiesene IP-Adressen aufzufangen.

IPv6-Adressen mÝssen in eckigen Klammern angegeben werden, da die optionale Portnummer sonst nicht erkannt werden kann. Hier ein IPv6-Beispiel:

Jeder virtuelle Host muss einer anderen IP-Adresse, einem anderen Port oder einem anderen Hostnamen fÝr den Server entsprechen. Im ersten Fall muss die Servermaschine so eingerichtet sein, dass sie IP-Pakete fÝr mehrere Adressen akzeptiert. (Wenn der Rechner nicht mehrere Netzwerkkarten besitzt, kann dies mit dem Befehl ifconfig alias durchgefÝhrt werden -- sofern Ihr Betriebssystem das unterstÝtzt).

Bei der Verwendung IP-basierter virtueller Hosts kann der spezielle Name _default_ benutzt werden. In diesem Fall weist der Apache jede IP-Adresse diesem virtuellen Host zu, die nicht explizit in einem anderen virtuellen Host angegeben ist. Falls kein virtueller Host _default_ angegeben ist, wird die "Hauptserver"-Konfiguration, die aus allen Definitionen auúerhalb der Virtual-Host-Abschnitte besteht, fÝr nicht passende IPs verwendet. (Beachten Sie jedoch, dass eine IP-Adresse die zu einer NameVirtualHost-Anweisung passt, weder den "Hauptserver" noch den virtuellen Host _default_ verwendet. Lesen Sie fÝr weitere Details die Dokumentation zu namensbasierten virtuellen Hosts.)

Sie kÆnnen einen speziellen :Port angeben, um den entsprechenden Port zu wechseln. Falls nicht angegeben, wird er auf den gleichen Port voreingestellt, wie die letzte Listen-Anweisung des Hauptservers. Sie kÆnnen auch :* angeben, um alle Ports dieser Adresse zu akzeptieren. (Dies wird zusammen mit _default_ empfohlen.)

Siehe auch

• Apache-Dokumentation zu virtuellen Hosts
• Probleme bezÝglich DNS und Apache
• Bestimmen, welche Adressen und Ports der Apache verwendet
• Wie die Abschnitte <Directory>, <Location> und <Files> arbeiten fÝr eine ErlÄuterung, wie diese verschiedenen Abschnitte miteinander kombiniert werden, wenn eine Anfrage empfangen wird