<-
Apache > HTTP-Server > Dokumentation > Version 2.0 > Module

Apache-Kernfunktionen

Verf�gbare Sprachen:  de  |  en  |  ja 

Beschreibung:St�ndig verf�gbare Kernfunktionen des Apache HTTP Servers
Status:Core

Direktiven

top

AcceptPathInfo-Direktive

Beschreibung:Ressourcen lassen angeh�ngte Pfadangaben zu
Syntax:AcceptPathInfo On|Off|Default
Voreinstellung:AcceptPathInfo Default
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:FileInfo
Status:Core
Modul:core
Kompatibilit�t:Verf�gbar ab Apache 2.0.30

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.

<Files "mypaths.shtml">
Options +Includes
SetOutputFilter INCLUDES
AcceptPathInfo On
</Files>

top

AccessFileName-Direktive

Beschreibung:Name der dezentralen Konfigurationsdateien
Syntax:AccessFileName Dateiname [Dateiname] ...
Voreinstellung:AccessFileName .htaccess
Kontext:Serverkonfiguration, Virtual Host
Status:Core
Modul:core

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:

AccessFileName .acl

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

<Directory />
AllowOverride None
</Directory>

deaktiviert wurden.

Siehe auch

top

AddDefaultCharset-Direktive

Beschreibung:Standard-Charset-Parameter, der bei Antworten vom Content-Type text/plain oder text/html hinzugef�gt wird
Syntax:AddDefaultCharset On|Off|Zeichenkodierung
Voreinstellung:AddDefaultCharset Off
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:FileInfo
Status:Core
Modul:core

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 utf-8

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

top

AddOutputFilterByType-Direktive

Beschreibung:einen Ausgabefilter einem bestimmten MIME-Type zuordnen
Syntax:AddOutputFilterByType Filter[;Filter...] MIME-Type [MIME-Type] ...
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:FileInfo
Status:Core
Modul:core
Kompatibilit�t:Verf�gbar ab Apache 2.0.33

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.

AddOutputFilterByType DEFLATE text/html text/plain

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.

<Location /cgi-bin/>
Options Includes
AddOutputFilterByType INCLUDES;DEFLATE text/html
</Location>

Hinweis:

Die Aktivierung von Filtern mittels AddOutputFilterByType kann in einigen F�llen ganz oder teilweise fehlschlagen. Beispielsweise werden keine Filter angewendet, wenn der MIME-Type nicht bestimmt werden kann und auf die Einstellung der DefaultType-Anweisung zur�ckf�llt, selbst wenn die DefaultType-Einstellung die gleiche ist.

Wenn Sie jedoch sicherstellen wollen, dass der Filter angewendet wird, sollten Sie den Content-Type z.B. mit AddType oder ForceType der Ressource explizit zuordnen. Das Setzen des Content-Types innerhalb eines (nicht-nph) CGI-Skriptes funktioniert ebenfalls zuverl�ssig.

Die Typ-gebundenen Ausgabefilter werden niemals auf Proxy-Anfragen angewendet.

Siehe auch

top

AllowEncodedSlashes-Direktive

Beschreibung:Legt fest, ob kodierte Pfadtrennzeichen in URLs durchgereicht werden d�rfen
Syntax:AllowEncodedSlashes On|Off
Voreinstellung:AllowEncodedSlashes Off
Kontext:Serverkonfiguration, Virtual Host
Status:Core
Modul:core
Kompatibilit�t:Verf�gbar ab Apache 2.0.46

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.

Anmerkung

Das Erlauben von Schr�gstrichen impliziert nicht deren Dekodierung. Vorkommen von %2F oder %5C (nur auf entsprechenden Systemen) werden unver�ndert in der ansonsten dekodierten URL belassen.

Siehe auch

top

AllowOverride-Direktive

Beschreibung:Direktiven-Typen, die in .htaccess-Dateien erlaubt sind.
Syntax:AllowOverride All|None|Direktiven-Typ [Direktiven-Typ] ...
Voreinstellung:AllowOverride All
Kontext:Verzeichnis
Status:Core
Modul:core

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.

Nun in <Directory>-Abschnitten verf�gbar

AllowOverride ist nur in <Directory>-Abschnitten g�ltig, die ohne regul�re Ausdr�ke definiert wurden, nicht in <Location>-, <DirectoryMatch>- oder <Files>-Abschnitten.

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:

AllowOverride AuthConfig Indexes

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

top

AuthName-Direktive

Beschreibung:Autorisierungsbereich zur Verwendung in der HTTP-Authentisierung
Syntax:AuthName auth-Bereich
Kontext:Verzeichnis, .htaccess
AllowOverride:AuthConfig
Status:Core
Modul:core

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:

AuthName "Top Secret"

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

Siehe auch

top

AuthType-Direktive

Beschreibung:Art der Authentisierung
Syntax:AuthType Basic|Digest
Kontext:Verzeichnis, .htaccess
AllowOverride:AuthConfig
Status:Core
Modul:core

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

top

CGIMapExtension-Direktive

Beschreibung:Technik zur Bestimmung des Interpreters f�r CGI-Skripte
Syntax:CGIMapExtension CGI-Pfad .Endung
Kontext:Verzeichnis, .htaccess
AllowOverride:FileInfo
Status:Core
Modul:core
Kompatibilit�t:ausschlie�lich NetWare

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.

top

ContentDigest-Direktive

Beschreibung:Aktiviert die Generierung von Content-MD5 HTTP-Response-Headern
Syntax:ContentDigest On|Off
Voreinstellung:ContentDigest Off
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:Options
Status:Core
Modul:core

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:

Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==

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.

top

DefaultType-Direktive

Beschreibung:MIME-Content-Type, der gesendet wird, wenn der Server den Typ nicht auf andere Weise ermitteln kann.
Syntax:DefaultType MIME-Type
Voreinstellung:DefaultType text/plain
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:FileInfo
Status:Core
Modul:core

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:

DefaultType image/gif

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.

top

<Directory>-Direktive

Beschreibung:Umschlie�t eine Gruppe von Direktiven, die nur auf das genannte Verzeichnis des Dateisystems und Unterverzeichnisse angewendet werden
Syntax:<Directory Verzeichnispfad> ... </Directory>
Kontext:Serverkonfiguration, Virtual Host
Status:Core
Modul:core

<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:

<Directory /usr/local/httpd/htdocs>
Options Indexes FollowSymLinks
</Directory>

Seien Sie vorsichtig mit den Verzeichnispfad-Argumenten. Sie m�ssen buchst�blich mit dem Dateisystempfad �bereinstimmen, den der Apache f�r den Zugriff auf die Dateien verwendet. Direktiven, die f�r ein bestimmtes Verzeichnis gelten, gelten nicht f�r Dateien in dem Verzeichnis, auf die �ber einen anderen Pfad zugegriffen wird, wie z.B. �ber verschiedene symbolische Links.

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

<Directory ~ "^/www/.*/[0-9]{3}">

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:

<Directory />
AllowOverride None
</Directory>

<Directory /home/>
AllowOverride FileInfo
</Directory>

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

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

<Directory ~ abc$>
# ... hier die Direktiven ...
</Directory>

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

<Directory />
Order Deny,Allow
Deny from All
</Directory>

�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

top

<DirectoryMatch>-Direktive

Beschreibung:Umschlie�t eine Gruppe von Direktiven, die auf Verzeichnisse des Dateisystems und ihre Unterverzeichnisse abgebildet werden, welche auf einen regul�ren Ausdruck passen
Syntax:<DirectoryMatch regex> ... </DirectoryMatch>
Kontext:Serverkonfiguration, Virtual Host
Status:Core
Modul:core

<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

<DirectoryMatch "^/www/(.+/)?[0-9]{3}">

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

Siehe auch

top

DocumentRoot-Direktive

Beschreibung:Verzeichnis, welches den Haupt-Dokumentenbaum bildet, der im Web sichtbar ist.
Syntax:DocumentRoot Verzeichnis
Voreinstellung:DocumentRoot /usr/local/apache/htdocs
Kontext:Serverkonfiguration, Virtual Host
Status:Core
Modul:core

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:

DocumentRoot /usr/web

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

top

EnableMMAP-Direktive

Beschreibung:Verwende Memory-Mapping, um Dateien w�hrend der Auslieferung zu lesen
Syntax:EnableMMAP On|Off
Voreinstellung:EnableMMAP On
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:FileInfo
Status:Core
Modul:core

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 Serverkonfigurationen, die f�r dieses Problem anf�llig sind, sollten Sie das Memory-Mapping f�r auszuliefernde Dateien deaktivieren, indem Sie schreiben:

EnableMMAP Off

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

<Directory "/pfad-zu-den-nfs-dateien"> EnableMMAP Off </Directory>

top

EnableSendfile-Direktive

Beschreibung:Verwende die sendfile-Unterst�tzung des Kernels, um Dateien an den Client auszuliefern
Syntax:EnableSendfile On|Off
Voreinstellung:EnableSendfile On
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:FileInfo
Status:Core
Modul:core
Kompatibilit�t:Verf�gbar ab Apache Version 2.0.44

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:

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

EnableSendfile Off

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

<Directory "/pfad-zu-den-nfs-dateien"> EnableSendfile Off </Directory>

top

ErrorDocument-Direktive

Beschreibung:Das, was der Server im Fehlerfall an den Client zur�ckgibt
Syntax:ErrorDocument Fehlercode Dokument
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:FileInfo
Status:Core
Modul:core
Kompatibilit�t:Die Syntax der Anf�hrungszeichen bei Textnachrichten hat sich im Apache 2.0 ge�ndert

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:

ErrorDocument 500 http://foo.example.com/cgi-bin/tester
ErrorDocument 404 /cgi-bin/falsche_urls.pl
ErrorDocument 401 /info_zur_anmeldung.html
ErrorDocument 403 "Der Zugriff ist nicht erlaubt."

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.

ErrorDocument 404 /cgi-bin/bad_urls.pl

<Directory /web/docs>
ErrorDocument 404 default
</Directory>

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

top

ErrorLog-Direktive

Beschreibung:Ablageort, an dem der Server Fehler protokolliert
Syntax: ErrorLog Dateiname|syslog[:facility]
Voreinstellung:ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows and OS/2)
Kontext:Serverkonfiguration, Virtual Host
Status:Core
Modul:core

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.

Beispiel

ErrorLog /var/log/httpd/error_log

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.

Beispiel

ErrorLog "|/usr/local/bin/httpd_errors"

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.

Beispiel

ErrorLog syslog:user

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.

Anmerkung

Bei der Eingabe eines Dateipfads auf nicht-Unix-Plattformen sollte darauf geachtet werden, nur (Vorw�rts-)Schr�gstriche zu verwenden, auch wenn die Plattform r�ckw�rts gerichtete Schr�gstriche (Backslashes) erlaubt. Im Allgemeinen ist es eine gute Idee, innerhalb der Konfigurationsdateien immer Vorw�rts-Schr�gstriche zu verwenden.

Siehe auch

top

FileETag-Direktive

Beschreibung:Dateiattribute, die zur Erstellung des HTTP-Response-Headers ETag verwendet werden
Syntax:FileETag Komponente ...
Voreinstellung:FileETag INode MTime Size
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:FileInfo
Status:Core
Modul:core

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.

top

<Files>-Direktive

Beschreibung:Enth�lt Direktiven, die sich nur auf passende Dateinamen beziehen
Syntax:<Files Dateiname> ... </Files>
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:All
Status:Core
Modul:core

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

<Files ~ "\.(gif|jpe?g|png)$">

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

top

<FilesMatch>-Direktive

Beschreibung:Enth�lt Direktiven, die f�r Dateinamen gelten, die auf einen regul�ren Ausdruck passen
Syntax:<FilesMatch regex> ... </FilesMatch>
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:All
Status:Core
Modul:core

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

<FilesMatch "\.(gif|jpe?g|png)$">

auf die gebr�uchlichsten Grafikformate im Internet passen.

Siehe auch

top

ForceType-Direktive

Beschreibung:Erzwingt die Auslieferung aller passendenden Dateien mit dem angegebenen MIME-Content-Type
Syntax:ForceType MIME-Type|None
Kontext:Verzeichnis, .htaccess
AllowOverride:FileInfo
Status:Core
Modul:core
Kompatibilit�t:Wurde im Apache 2.0 in den Core verschoben

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:

ForceType image/gif

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:

# erzwinge image/gif f�r alle Dateien:
<Location /images>
ForceType image/gif
</Location>

# hier jedoch normale MIME-Type-Zuordnungen:
<Location /images/mixed>
ForceType None
</Location>

top

HostnameLookups-Direktive

Beschreibung:Aktiviert DNS-Lookups auf Client-IP-Adressen
Syntax:HostnameLookups On|Off|Double
Voreinstellung:HostnameLookups Off
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis
Status:Core
Modul:core

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.

top

IdentityCheck-Direktive

Beschreibung:Erm�glicht die Protokollierung der Identit�t des entfernten Anwenders nach RFC1413
Syntax:IdentityCheck On|Off
Voreinstellung:IdentityCheck Off
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis
Status:Core
Modul:core

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.

top

<IfDefine>-Direktive

Beschreibung:Schlie�t Direktiven ein, die nur ausgef�hrt werden, wenn eine Testbedingung beim Start wahr ist
Syntax:<IfDefine [!]Parametername> ... </IfDefine>
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:All
Status:Core
Modul:core

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:

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:

httpd -DReverseProxy ...

# httpd.conf
<IfDefine ReverseProxy>
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_module modules/libproxy.so
</IfDefine>

top

<IfModule>-Direktive

Beschreibung:Schlie�t Direktiven ein, die abh�ngig vom Vorhandensein oder Fehlen eines speziellen Moduls ausgef�hrt werden
Syntax:<IfModule [!]Modulname> ... </IfModule>
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:All
Status:Core
Modul:core

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:

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.

top

Include-Direktive

Beschreibung:F�gt andere Konfigurationsdateien innerhalb der Server-Konfigurationsdatei ein
Syntax:Include Dateiname|Verzeichnis
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis
Status:Core
Modul:core
Kompatibilit�t:Die Platzhalter-Suche ist verf�gbar seit 2.0.41

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:

Include /usr/local/apache2/conf/ssl.conf
Include /usr/local/apache2/conf/vhosts/*.conf

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

Include conf/ssl.conf
Include conf/vhosts/*.conf

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

root@host# apachectl configtest
Processing config file: /usr/local/apache2/conf/ssl.conf
Processing config file: /usr/local/apache2/conf/vhosts/vhost1.conf
Processing config file: /usr/local/apache2/conf/vhosts/vhost2.conf
Syntax OK

Siehe auch

top

KeepAlive-Direktive

Beschreibung:Aktiviert persistente HTTP-Verbindungen
Syntax:KeepAlive On|Off
Voreinstellung:KeepAlive On
Kontext:Serverkonfiguration, Virtual Host
Status:Core
Modul:core

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

top

KeepAliveTimeout-Direktive

Beschreibung:Zeitspanne, die der Server w�hrend persistenter Verbindungen auf nachfolgende Anfragen wartet
Syntax:KeepAliveTimeout Sekunden
Voreinstellung:KeepAliveTimeout 15
Kontext:Serverkonfiguration, Virtual Host
Status:Core
Modul:core

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.

top

<Limit>-Direktive

Beschreibung:Beschr�nkt die eingeschlossenen Zugriffskontrollen auf bestimmte HTTP-Methoden
Syntax:<Limit Methode [Methode] ... > ... </Limit>
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:All
Status:Core
Modul:core

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:

<Limit POST PUT DELETE>
Require valid-user
</Limit>

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.

Bei Zugriffsbeschr�nkungen ist ein <LimitExcept>-Abschnitt stets einem <Limit>-Abschnitt vorzuziehen, da ein <LimitExcept>-Abschnitt vor allen m�glichen Methoden sch�tzt.
top

<LimitExcept>-Direktive

Beschreibung:Beschr�nkt Zugriffskontrollen auf alle HTTP-Methoden au�er den genannten
Syntax:<LimitExcept Methode [Methode] ... > ... </LimitExcept>
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:All
Status:Core
Modul:core

<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:

<LimitExcept POST GET>
Require valid-user
</LimitExcept>

top

LimitInternalRecursion-Direktive

Beschreibung:Bestimmt die maximale Anzahl interner Umleitungen und verschachtelter Unteranfragen
Syntax:LimitInternalRecursion Zahl [Zahl]
Voreinstellung:LimitInternalRecursion 10
Kontext:Serverkonfiguration, Virtual Host
Status:Core
Modul:core
Kompatibilit�t:Verf�gbar ab Apache 2.0.47

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.

Beispiel

LimitInternalRecursion 5

top

LimitRequestBody-Direktive

Beschreibung:Begrenzt die Gesamtgr��e des vom Client gesendeten HTTP-Request-Body
Syntax:LimitRequestBody Bytes
Voreinstellung:LimitRequestBody 0
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:All
Status:Core
Modul:core

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:

LimitRequestBody 102400

top

LimitRequestFields-Direktive

Beschreibung:Begrenzt die Anzahl der HTTP-Request-Header, die vom Client entgegengenommen werden
Syntax:LimitRequestFields Anzahl
Voreinstellung:LimitRequestFields 100
Kontext:Serverkonfiguration
Status:Core
Modul:core

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:

LimitRequestFields 50

top

LimitRequestFieldSize-Direktive

Beschreibung:Begrenzt die L�nge des vom Client gesendeten HTTP-Request-Headers
Syntax:LimitRequestFieldsize Bytes
Voreinstellung:LimitRequestFieldsize 8190
Kontext:Serverkonfiguration
Status:Core
Modul:core

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:

LimitRequestFieldSize 4094

Unter normalen Umst�nden sollte die Voreinstellung nicht ver�ndert werden.
top

LimitRequestLine-Direktive

Beschreibung:Begrenzt die L�nge der vom Client entgegengenommenen HTTP-Anfragezeile
Syntax:LimitRequestLine Bytes
Voreinstellung:LimitRequestLine 8190
Kontext:Serverkonfiguration
Status:Core
Modul:core

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:

LimitRequestLine 4094

Unter normalen Umst�nden sollte die Voreinstellung nicht ver�ndert werden.
top

LimitXMLRequestBody-Direktive

Beschreibung:Begrenzt die Gr��e eines XML-basierten Request-Bodys
Syntax:LimitXMLRequestBody Bytes
Voreinstellung:LimitXMLRequestBody 1000000
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:All
Status:Core
Modul:core

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:

LimitXMLRequestBody 0

top

<Location>-Direktive

Beschreibung:Wendet die enthaltenen Direktiven nur auf die entsprechenden URLs an
Syntax:<Location URL-Pfad|URL> ... </Location>
Kontext:Serverkonfiguration, Virtual Host
Status:Core
Modul:core

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.

Wann sollte<Location> verwendet werden

Verwenden Sie <Location>, um Anweisungen auf Inhalte anzuwenden, die au�erhalb des Dateisystems abgelegt sind. Benutzen Sie <Directory> und <Files> f�r Inhalte, die innerhalb des Dateisystems abgelegt sind. Eine Ausnahme bildet <Location />, welches ein einfacher Weg ist, um eine Konfiguration auf den gesamten Server anzuwenden.

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

<Location ~ "/(extra|special)/data">

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:

<Location /status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from .foo.com
</Location>

Anmerkung zu / (Schr�gstrich, Slash)

Das Slash-Zeichen hat eine besondere Bedeutung, je nachdem, wo es in der URL erscheint. Manche werden sein Verhalten vom Dateisystem gewohnt sein, wo mehrere aufeinanderfolgende Schr�gstriche h�ufig zu einem Schr�gstrich zusammengefa�t werden (d.h. /home///foo ist das gleiche wie /home/foo). Im URL-Raum ist dies nicht notwendigerweise genauso. Bei der Direktive <LocationMatch> und der <Location>-Version mit regul�ren Ausdr�cken m�ssen Sie explizit mehrere Schr�gstriche angeben, wenn Sie genau dies beabsichtigen.

Beispielsweise w�rde <LocationMatch ^/abc> auf die angeforderte URL /abc passen, nicht aber auf //abc. Die Direktive <Location> (ohne regul�re Ausdr�cke) verh�lt sich �hnlich, wenn sie f�r Proxy-Anfragen verwendet wird. Wenn <Location> (ohne regul�re Ausdr�cke) jedoch f�r nicht-Proxy-Anfragen verwendet wird, werden stillscheigend mehrere Schr�chstriche mit mit einem einzigen Schr�gstrich gleichgesetzt. Geben Sie beispielsweise <Location /abc/def> an und die Anfrage lautet auf /abc//def, dann greift die Anweisung.

Siehe auch

top

<LocationMatch>-Direktive

Beschreibung:Wendet die enthaltenen Direktiven nur auf URLs an, die auf regul�re Ausdr�cke passen
Syntax:<LocationMatch regex> ... </LocationMatch>
Kontext:Serverkonfiguration, Virtual Host
Status:Core
Modul:core

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

<LocationMatch "/(extra|special)/data">

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

Siehe auch

top

LogLevel-Direktive

Beschreibung:Steuert die Ausf�hrlichkeit des Fehlerprotokolls
Syntax:LogLevel Level
Voreinstellung:LogLevel warn
Kontext:Serverkonfiguration, Virtual Host
Status:Core
Modul:core

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:

Level Beschreibung Beispiel
emerg Notfall - das System ist unbenutzbar. "Child cannot open lock file. Exiting" (Anm.d.�.: "Kindprozess kann die Lock-Datei nicht �ffnen. Beende Programm")
alert Ma�nahmen m�ssen unverz�glich ergriffen werden. "getpwuid: couldn't determine user name from uid" (Anm.d.�.: "getpwuid: kann keinen Benutzernamen aus der UID ermitteln")
crit Kritischer Zustand. "socket: Failed to get a socket, exiting child" (Anm.d.�.: "socket: Socket-Zuweisung fehlgeschlagen, beende Kindprozess")
error Fehlerbedingung. "Premature end of script headers" (Anm.d.�.: "Vorzeitiges Ende der Skript-Header")
warn Warnung. "child process 1234 did not exit, sending another SIGHUP" (Anm.d.�.: "Kindprozess 1234 nicht beendet, sende ein weiteres SIGHUP")
notice Normaler, aber signifikanter Zustand. "httpd: caught SIGBUS, attempting to dump core in ..." (Anm.d.�.: "httpd: SIGBUS empfangen, versuche Speicherabbild nach ... zu schreiben")
info Information. "Server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers)..." (Anm.d.�.: "Server scheint besch�ftigt zu sein, (m�glicherweise m�ssen Sie StartServers oder Min/MaxSpareServers erh�hen)")
debug Debug-Level-Nachrichten "Opening config file ..." (Anm.d.�.: "�ffne Konfigurationsdatei ...")

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:

LogLevel notice

Hinweis

Beim Protokollieren in eine regul�re Datei k�nnen Nachrichten des Levels notice nicht unterdr�ckt werden und werden daher immer protokolliert. Dies trifft allerdings nicht zu wenn mittels syslog protokolliert wird.

top

MaxKeepAliveRequests-Direktive

Beschreibung:Anzahl der Anfragen, die bei einer persistenten Verbindung zul�ssig sind
Syntax:MaxKeepAliveRequests Anzahl
Voreinstellung:MaxKeepAliveRequests 100
Kontext:Serverkonfiguration, Virtual Host
Status:Core
Modul:core

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:

MaxKeepAliveRequests 500

top

NameVirtualHost-Direktive

Beschreibung:Bestimmt eine IP-Adresse f�r den Betrieb namensbasierter virtueller Hosts
Syntax:NameVirtualHost Adresse[:Port]
Kontext:Serverkonfiguration
Status:Core
Modul:core

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.:

NameVirtualHost 111.22.33.44

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.

Anmerkung

Beachten Sie, dass der "Hauptserver" und jeder _default_-Server niemals bei einer Anfrage an einer NameVirtualHost-IP-Adresse bedient wird (es sei denn, Sie geben aus irgendwelchen Gr�nden NameVirtualHost an, definieren dann aber keine VirtualHosts f�r diese Adresse).

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

NameVirtualHost 111.22.33.44:8080

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

NameVirtualHost [fe80::a00:20ff:fea7:ccea]:8080

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

NameVirtualHost *

Argument der Direktive <VirtualHost>

Beachten Sie, dass das Argument der <VirtualHost>-Anweisung exakt auf das Argument der NameVirtualHost-Anweisung passen muss.

NameVirtualHost 1.2.3.4
<VirtualHost 1.2.3.4>
# ...
</VirtualHost>

Siehe auch

top

Options-Direktive

Beschreibung:Definiert, welche Eigenschaften oder Funktionen in einem bestimmten Verzeichnis verf�gbar sind
Syntax:Options [+|-]Option [[+|-]Option] ...
Voreinstellung:Options All
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:Options
Status:Core
Modul:core

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 -

<Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>

<Directory /web/docs/spec>
Options Includes
</Directory>

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

<Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>

<Directory /web/docs/spec>
Options +Includes -Indexes
</Directory>

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

Anmerkung

Die Verwendung von -IncludesNOEXEC oder -Includes deaktiviert Server Side Includes unabh�ngig von der vorigen Einstellung vollst�ndig.

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

top

Require-Direktive

Beschreibung:W�hlt die authentisierten Benutzer aus, die auf eine Ressource zugreifen k�nnen
Syntax:Require Name [Name] ...
Kontext:Verzeichnis, .htaccess
AllowOverride:AuthConfig
Status:Core
Modul:core

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:

AuthType Basic
AuthName "Gesch�tzte Ressource"
AuthUserFile /web/users
AuthGroupFile /web/groups
Require group admin

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

top

RLimitCPU-Direktive

Beschreibung:Begrenzt den CPU-Verbrauch von Prozessen, die von Apache-Kindprozessen gestartet wurden
Syntax:RLimitCPU Sekunden|max [Sekunden|max]
Voreinstellung:unbestimmt; verwendet die Voreinstellung des Systems
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:All
Status:Core
Modul:core

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

top

RLimitMEM-Direktive

Beschreibung:Begrenzt den Speicherverbrauch von Prozessen, die von Apache-Kindprozessen gestartet wurden
Syntax:RLimitMEM Bytes|max [Bytes|max]
Voreinstellung:unbestimmt; verwendet die Voreinstellung des Systems
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:All
Status:Core
Modul:core

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

top

RLimitNPROC-Direktive

Beschreibung:Begrenzt die Anzahl der Prozesse, die von Prozessen gestartet werden k�nnen, der ihrerseits von Apache-Kinprozessen gestartet wurden
Syntax:RLimitNPROC Zahl|max [Zahl|max]
Voreinstellung:unbestimmt; verwendet die Voreinstellung des Systems
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:All
Status:Core
Modul:core

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.

Anmerkung

Wenn CGI-Prozesse nicht unter anderen Benutzerkennungen als der User-ID des Webservers laufen, dann beschr�nkt diese Direktive die Anzahl der Prozesse, die der Server selbst erstellen kann. Kennzeichen einer solchen Situation sind cannot fork-Meldungen (Anm.d.�.: kann nicht abspalten) in der Datei error_log.

Siehe auch

top

Satisfy-Direktive

Beschreibung:Zusammenspiel von rechnerbasierter Zugriffskontrolle und Benutzerauthentisierung
Syntax:Satisfy Any|All
Voreinstellung:Satisfy All
Kontext:Verzeichnis, .htaccess
AllowOverride:AuthConfig
Status:Core
Modul:core
Kompatibilit�t:Wird seit Version 2.0.51 von <Limit> und <LimitExcept> beeinflusst

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:

Require valid-user
Allow from 192.168.1
Satisfy Any

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

Siehe auch

top

ScriptInterpreterSource-Direktive

Beschreibung:Methode zur Ermittlung des Interpreters von CGI-Skripten
Syntax:ScriptInterpreterSource Registry|Registry-Strict|Script
Voreinstellung:ScriptInterpreterSource Script
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:FileInfo
Status:Core
Modul:core
Kompatibilit�t:ausschlie�lich Win32; Die Option Registry-Strict ist verf�gbar seit Apache 2.0.

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:

#!C:/Perl/bin/perl.exe

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

#!perl

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.

Sicherheit

Seien Sie vorsichtig, wenn Sie ScriptInterpreterSource Registry bei Verzeichnissen verwenden, auf die eine ScriptAlias-Anweisung zeigt, denn der Apache wird versuchen, jede Datei innerhalb des Verzeichnisses auszuf�hren. Die Einstellung Registry kann unerw�nschte Programmaufrufe bei Dateien verursachen, die �blicherweise nicht ausgef�hrt werden. Auf den meisten Windows-Systemen beispielsweise startet der voreingestellte �ffnen-Befehl f�r .htm-Dateien den Microsoft Internet Explorer, so dass jede HTTP-Anfrage nach einer existierenden .htm-Datei im Skript-Verzeichnis den Browser auf dem Server im Hintergrund starten w�rde. Dies ist leichte Art und Weise, Ihr System binnen etwa einer Minute zum Absturz zu bringen.

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.

top

ServerAdmin-Direktive

Beschreibung:E-Mail-Adresse, die der Server in Fehlermeldungen einf�gt, welche an den Client gesendet werden
Syntax:ServerAdmin E-Mail-Adresse
Kontext:Serverkonfiguration, Virtual Host
Status:Core
Modul:core

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.

ServerAdmin [email protected]

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

top

ServerAlias-Direktive

Beschreibung:Alternativer Name f�r einen Host, der verwendet wird, wenn Anfragen einem namensbasierten virtuellen Host zugeordnet werden
Syntax:ServerAlias Hostname [Hostname] ...
Kontext:Virtual Host
Status:Core
Modul:core

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

<VirtualHost *>
ServerName server.domain.com
ServerAlias server server2.domain.com server2
# ...
</VirtualHost>

Siehe auch

top

ServerName-Direktive

Beschreibung:Rechnername und Port, die der Server dazu verwendet, sich selbst zu identifizieren
Syntax:ServerName voll-qualifizierter-Domainname[:port]
Kontext:Serverkonfiguration, Virtual Host
Status:Core
Modul:core
Kompatibilit�t:Diese Direktive l�st in Version 2.0 die Funktionalit�t der Direktive Port aus Version 1.3 ab.

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:

ServerName www.example.com:80

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

top

ServerPath-Direktive

Beschreibung:Veralteter URL-Pfad f�r einen namensbasierten virtuellen Host, auf den von einem inkompatiblen Browser zugegriffen wird
Syntax:ServerPath URL-Pfad
Kontext:Virtual Host
Status:Core
Modul:core

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

top

ServerRoot-Direktive

Beschreibung:Basisverzeichnis der Serverinstallation
Syntax:ServerRoot Verzeichnis
Voreinstellung:ServerRoot /usr/local/apache
Kontext:Serverkonfiguration
Status:Core
Modul:core

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.

Beispiel

ServerRoot /home/httpd

Siehe auch

top

ServerSignature-Direktive

Beschreibung:Konfiguriert die Fu�zeile von servergenerierten Dokumenten
Syntax:ServerSignature On|Off|EMail
Voreinstellung:ServerSignature Off
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:All
Status:Core
Modul:core

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

top

ServerTokens-Direktive

Beschreibung:Konfiguriert den HTTP-Response-Header Server
Syntax:ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full
Voreinstellung:ServerTokens Full
Kontext:Serverkonfiguration
Status:Core
Modul:core

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

top

SetHandler-Direktive

Beschreibung:Erzwingt die Verarbeitung aller passenden Dateien durch einen Handler
Syntax:SetHandler Handlername|None
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:FileInfo
Status:Core
Modul:core
Kompatibilit�t:Seit Apache 2.0 im Core

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:

SetHandler imap-file

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:

<Location /status>
SetHandler server-status
</Location>

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

Siehe auch

top

SetInputFilter-Direktive

Beschreibung:Bestimmt die Filter, die Client-Anfragen und POST-Eingaben verarbeiten
Syntax:SetInputFilter Filter[;Filter...]
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:FileInfo
Status:Core
Modul:core

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

top

SetOutputFilter-Direktive

Beschreibung:Bestimmt die Filter, die Antworten des Servers verarbeiten
Syntax:SetOutputFilter Filter[;Filter...]
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:FileInfo
Status:Core
Modul:core

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.

<Directory /www/data/>
SetOutputFilter INCLUDES
</Directory>

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

top

TimeOut-Direktive

Beschreibung:Zeitspanne, die der Server auf verschiedene Ereignisse wartet, bevor er die Anfrage abbricht
Syntax:TimeOut Sekunden
Voreinstellung:TimeOut 300
Kontext:Serverkonfiguration
Status:Core
Modul:core

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.

top

UseCanonicalName-Direktive

Beschreibung:Bestimmt, wie der Server seinen eigenen Namen und Port ermittelt
Syntax:UseCanonicalName On|Off|DNS
Voreinstellung:UseCanonicalName On
Kontext:Serverkonfiguration, Virtual Host, Verzeichnis
Status:Core
Modul:core

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.

Warnung

Wenn CGI-Skripte Vermutungen aufgrund des Wertes von SERVER_NAME anstellen, k�nnen sie durch diese Option fehlschlagen. Clients steht es im Wesentlichen frei, einen Wert f�r den Hostnamen anzugeben, wie er will. Wenn das CGI-Skript SERVER_NAME jedoch lediglich dazu verwendet, selbstreferenzierende URLs zu erstellen, sollte das gerade noch in Ordnung sein.

Siehe auch

top

<VirtualHost>-Direktive

Beschreibung:Enth�lt Direktiven, die nur auf bestimmte Hostnamen oder IP-Adressen angewendet werden
Syntax:<VirtualHost Adresse[:Port] [Adresse[:Port]] ...> ... </VirtualHost>
Kontext:Serverkonfiguration
Status:Core
Modul:core

<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:

Beispiel

<VirtualHost 10.1.2.3>
ServerAdmin [email protected]
DocumentRoot /www/docs/host.foo.com
ServerName host.foo.com
ErrorLog logs/host.foo.com-error_log
TransferLog logs/host.foo.com-access_log
</VirtualHost>

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

<VirtualHost [fe80::a00:20ff:fea7:ccea]>
ServerAdmin [email protected]
DocumentRoot /www/docs/host.example.com
ServerName host.example.com
ErrorLog logs/host.example.com-error_log
TransferLog logs/host.example.com-access_log
</VirtualHost>

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).

Anmerkung

Die Verwendung von <VirtualHost> beeinflusst nicht, an welchen Adressen der Apache lauscht. Sie m�ssen mit Listen sicherstellen, dass der Apache an der richtigen Adresse lauscht.

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.)

Sicherheit

Lesen Sie das Dokument Sicherheitshinweise f�r Details, warum Ihre Sicherheit gef�hrdet sein kann, wenn das Verzeichnis, in dem Protokolldateien gespeichert werden, f�r jemanden anderes als den Benutzer beschreibbar ist, der den Server gestartet hat.

Siehe auch

Verf�gbare Sprachen:  de  |  en  |  ja