core
Ständig verfügbare Kernfunktionen des Apache HTTP Servers
Core
AcceptPathInfo
Ressourcen lassen angehängte Pfadangaben zu
AcceptPathInfo On|Off|Default
AcceptPathInfo Default
server config
virtual host
directory
.htaccess
FileInfo
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 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>
AccessFileName
Name der dezentralen Konfigurationsdateien
AccessFileName Dateiname [Dateiname] ...
AccessFileName .htaccess
server config
virtual host

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.

AllowOverride
Konfigurationsdateien
.htaccess-Dateien
AddDefaultCharset
Standard-Zeichenkodierung für Antworten ohne explizit angegebene Zeichenkodierung
AddDefaultCharset On|Off|Zeichenkodierung
AddDefaultCharset Off
server config
virtual host
directory
.htaccess
FileInfo

Die Direktive gibt den Namen der Zeichenkodierung an, die jeder Antwort hinzugefügt wird, welche in den HTTP-Headern keinen Parameter zum Content-Type enthält. Dies überschreibt jede Zeichenkodierung, die mittels `META`-Tag im Dokument angegeben ist. Die Angabe von `AddDefaultCharset Off` deaktiviert die Funktion. `AddDefaultCharset On` ermöglicht es, mit der Direktive die Apache-interne Standard-Zeichenkodierung `iso-8859-1` vorzuschreiben. Sie können auch angeben, dass eine andere Zeichenkodierung verwendet werden soll. Zum Beispiel:

AddDefaultCharset utf-8
AddOutputFilterByType
einen Ausgabefilter einem bestimmten MIME-Type zuordnen
AddOutputFilterByType Filter[;Filter...] MIME-Type [MIME-Type] ...
server config
virtual host
directory
.htaccess
FileInfo
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.

AddOutputFilter
SetOutputFilter
Filter
AllowEncodedSlashes
Legt fest, ob kodierte Pfadtrennzeichen in URLs durchgereicht werden dürfen
AllowEncodedSlashes On|Off
AllowEncodedSlashes Off
server config
virtual host
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.

AcceptPathInfo
AllowOverride
Direktiven-Typen, die in `.htaccess`-Dateien erlaubt sind.
AllowOverride All|None|Direktiven-Typ [Direktiven-Typ] ...
AllowOverride All
directory

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, nicht in Location- 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
AccessFileName
Konfigurationsdateien
.htaccess-Dateien
AuthName
Autorisierungsbereich zur Verwendung in der HTTP-Authentisierung
AuthName auth-Bereich
directory
.htaccess
AuthConfig

Die Direktive legt den Namen des Autorisierungsbereiches 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.

Authentisierung, Autorisierung und Zugriffskontrolle
AuthType
Art der Authentisierung
AuthType Basic|Digest
directory
.htaccess
AuthConfig

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.

Authentisierung, Autorisierung und Zugriffskontrolle
CGIMapExtension
Technik zur Bestimmung des Interpreters für CGI-Skripte
CGIMapExtension CGI-Pfad .Endung
directory
.htaccess
FileInfo
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.

ContentDigest
Aktiviert die Generierung von `Content-MD5` HTTP-Response-Headern
ContentDigest On|Off
ContentDigest Off
server config
virtual host
directory
.htaccess
Options
Experimental

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

DefaultType
MIME-Content-Type, der gesendet wird, wenn der Server den Typ nicht auf andere Weise ermitteln kann.
DefaultType MIME-Type
DefaultType text/plain
server config
virtual host
directory
.htaccess
FileInfo

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.

Directory
Umschließt eine Gruppe von Direktiven, die nur auf das genannte Verzeichnis des Dateisystems und Unterverzeichnisse angewendet werden
<Directory Verzeichnispfad> ... </Directory>
server config
virtual host

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

- 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

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

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
Umschließt eine Gruppe von Direktiven, die auf Verzeichnisse des Dateisystems und ihre Unterverzeichnisse abgebildet werden, welche auf einen regulären Ausdruck passen
<DirectoryMatch regex> ... </DirectoryMatch>
server config
virtual host

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.

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
Verzeichnis, welches den Haupt-Dokumentenbaum bildet, der im Web sichtbar ist.
DocumentRoot Verzeichnis
DocumentRoot /usr/local/apache/htdocs
server config
virtual host

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.

URLs auf das Dateisystem abbilden
EnableMMAP
Verwende Memory-Mapping, um Dateien während der Auslieferung zu lesen
EnableMMAP On|Off
EnableMMAP On
server config
virtual host
directory
.htaccess
FileInfo

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 Segmentierungsfehler ein sogenannter "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:

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>
EnableSendfile
Verwende die sendfile-Unterstützung des Kernels, um Dateien an den Client auszuliefern
EnableSendfile On|Off
EnableSendfile On
server config
virtual host
directory
.htaccess
FileInfo
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:

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

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>
ErrorDocument
Das, was der Server im Fehlerfall an den Client zurückgibt
ErrorDocument Fehlercode Dokument
server config
virtual host
directory
.htaccess
FileInfo
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."

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.

Dokumentation zu individuellen Fehlermeldungen
ErrorLog
Ablageort, an dem der Server Fehler protokolliert
ErrorLog Dateiname|syslog[:facility]
ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows and OS/2)
server config
virtual host

Die Direktive ErrorLog bestimmt den Namen der Datei, in welcher der Server alle auftretenden Fehler protokolliert. Wenn Dateiname nicht absolut ist (im Allgemeinen: nicht mit einem Schrägstrich (/) beginnt), 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.

LogLevel
Apache-Log-Dateien
FileETag
Dateiattribute, die zur Erstellung des HTTP-Response-Headers ETag verwendet werden
FileETag Komponente ...
FileETag INode MTime Size
server config
virtual host
directory
.htaccess
FileInfo

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
Enthält Direktiven, die sich nur auf passende Dateinamen beziehen
<Files Dateiname> ... </Files>
server config
virtual host
directory
.htaccess
All

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.

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
Enthält Direktiven, die für Dateinamen gelten, die auf einen regulären Ausdruck passen
<FilesMatch regex> ... </FilesMatch>
server config
virtual host
directory
.htaccess
All

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.

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
Erzwingt die Auslieferung aller passendenden Dateien mit dem angegebenen MIME-Content-Type
ForceType MIME-Type|None
directory
.htaccess
FileInfo
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>
HostnameLookups
Aktiviert DNS-Lookups auf Client-IP-Adressen
HostnameLookups On|Off|Double
HostnameLookups Off
server config
virtual host
directory

Diese Direktive aktiviert die DNS-Abfrage 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 `Off`lassen. Das Hilfsprogramm logresolve, das standardmäßig in das Unterverzeichnis `bin` Ihres Installationsverzeichnisses kompiliert wird, kann dazu verwendet werden, um offline Hostnamen zu protokollierten IP-Adressen nachzuschlagen.

IdentityCheck
Ermöglicht die Protokollierung der Identität des entfernten Anwenders nach RFC1413
IdentityCheck On|Off
IdentityCheck Off
server config
virtual host
directory

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
Schließt Direktiven ein, die nur ausgeführt werden, wenn eine Testbedingung beim Start wahr ist
<IfDefine [!]Parametername> ... </IfDefine>
server config
virtual host
directory
.htaccess
All

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:

httpd -DReverseProxy ...
# httpd.conf
<IfDefine ReverseProxy>
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_module modules/libproxy.so
</IfDefine>
IfModule
Schließt Direktiven ein, die abhängig vom Vorhandensein oder Fehlen eines speziellen Moduls ausgeführt werden
<IfModule [!]Modulname> ... </IfModule>
server config
virtual host
directory
.htaccess
All

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
Fügt andere Konfigurationsdateien innerhalb der Server-Konfigurationsdatei ein
Include Dateiname|Verzeichnis
server config
virtual host
directory
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 (d.h., er beginnt mit einem Schrägstrich) 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
apachectl
KeepAlive
Aktiviert persistente HTTP-Verbindungen
KeepAlive On|Off
KeepAlive On
server config
virtual host

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.

MaxKeepAliveRequests
KeepAliveTimeout
Zeitspanne, die der Server während persistenter Verbindungen auf nachfolgende Anfragen wartet
KeepAliveTimeout Sekunden
KeepAliveTimeout 15
server config
virtual host

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
Beschränkt die eingeschlossenen Zugriffskontrollen auf bestimmte HTTP-Methoden
<Limit Methode [Methode] ... > ... </Limit>
server config
virtual host
directory
.htaccess
All

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.

LimitExcept
Beschränkt Zugriffskontrollen auf alle HTTP-Methoden außer den genannten
<LimitExcept Methode [Methode] ... > ... </LimitExcept>
server config
virtual host
directory
.htaccess
All

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>
LimitInternalRecursion
Bestimmt die maximale Anzahl interner Umleitungen und verschachtelter Unteranfragen
LimitInternalRecursion Zahl [Zahl]
LimitInternalRecursion 10
server config
virtual host
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 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
LimitRequestBody
Begrenzt die Gesamtgröße des vom Client gesendeten HTTP-Request-Body
LimitRequestBody Bytes
LimitRequestBody 0
server config
virtual host
directory
.htaccess
All

Die Direktive gibt die Anzahl der Bytes zwischen 0 (unbegrenzt) und 2147483647 (2GB) an, die im Request-Body (Datenteil der Anfrage) erlaubt sind. Die Voreinstellung wird durch die Konstante `DEFAULT_LIMIT_REQUEST_BODY` (`0` bei der Auslieferung) zur Kompilierungszeit gesetzt.

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
LimitRequestFields
Begrenzt die Anzahl der HTTP-Request-Header, die vom Client entgegengenommen werden
LimitRequestFields Anzahl
LimitRequestFields 100
server config

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
LimitRequestFieldSize
Begrenzt die Länge des vom Client gesendeten HTTP-Request-Headers
LimitRequestFieldsize Bytes
LimitRequestFieldsize 8190
server config

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.

LimitRequestLine
Begrenzt die Länge der vom Client entgegengenommenen HTTP-Anfragezeile
LimitRequestLine Bytes
LimitRequestLine 8190
server config

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.

LimitXMLRequestBody
Begrenzt die Größe eines XML-basierten Request-Bodys
LimitXMLRequestBody Bytes
LimitXMLRequestBody 1000000
server config
virtual host
directory
.htaccess
All

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
Location
Wendet die enthaltenen Direktiven nur auf die entsprechenden URLs an
<Location URL-Pfad|URL> ... </Location>
server config
virtual host

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

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
Wendet die enthaltenen Direktiven nur auf URLs an, die auf reguläre Ausdrücke passen
<LocationMatch regex> ... </LocationMatch>
server config
virtual host

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.

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
Steuert die Ausführlichkeit des Fehlerprotokolls
LogLevel Level
LogLevel warn
server config
virtual host

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" "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" "getpwuid: kann keinen Benutzernamen aus der UID ermitteln"
`crit` | Kritischer Zustand. | "socket: Failed to get a socket, exiting child" "socket: Socket-Zuweisung fehlgeschlagen, beende Kindprozess"
`error` | Fehlerbedingung. | "Premature end of script headers" "Vorzeitiges Ende der Skript-Header"
`warn` | Warnung. | "child process 1234 did not exit, sending another SIGHUP" "Kindprozess 1234 nicht beendet, sende ein weiteres SIGHUP"
`notice` | Normaler, aber signifikanter Zustand. | "httpd: caught SIGBUS, attempting to dump core in ..." "httpd: SIGBUS empfangen, versuche Speicherabbild nach ... zu schreiben"
`info` | Information. | "Server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers)..." "Server scheint beschäftigt zu sein, (möglicherweise müssen Sie StartServers oder Min/MaxSpareServers erhöhen)"
`debug` | Debug-Level-Nachrichten | "Opening config file ..." "Ö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.

MaxKeepAliveRequests
Anzahl der Anfragen, die bei einer persistenten Verbindung zulässig sind
MaxKeepAliveRequests Anzahl
MaxKeepAliveRequests 100
server config
virtual host

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
NameVirtualHost
Bestimmt eine IP-Adresse für den Betrieb namensbasierter virtueller Hosts
NameVirtualHost Adresse[:Port]
server config

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>
Dokumentation zu virtuellen Hosts
Options
Definiert, welche Eigenscahften oder Funktionen in einem bestimmten Verzeichnis verfügbar sind
Options [+|-]Option [[+|-]Option] ...
Options All
server config
virtual host
directory
.htaccess
Options

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

Require
Wählt die authentisierten Benutzer aus, die auf eine Ressource zugreifen können
Require Name [Name] ...
directory
.htaccess
AuthConfig

Die Direktive wählt aus, welche authentisierten Benutzer auf ein Verzeichnis 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ütztes Verzeichnis"
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.

Satisfy
mod_access
RLimitCPU
Begrenzt den CPU-Verbrauch von Prozessen, die von Apache-Kindprozessen gestartet wurden
RLimitCPU Sekunden|max [Sekunden|max]
unbestimmt; verwendet die Voreinstellung des Systems
server config
virtual host
directory
.htaccess
All

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.

RLimitMEM
RLimitNPROC
RLimitMEM
Begrenzt den Speicherverbrauch von Prozessen, die von Apache-Kindprozessen gestartet wurden
RLimitMEM Bytes|max [Bytes|max]
unbestimmt; verwendet die Voreinstellung des Systems
server config
virtual host
directory
.htaccess
All

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.

RLimitCPU
RLimitNPROC
RLimitNPROC
Begrenzt die Anzahl der Prozesse, die von Prozessen gestartet werden können, der ihrerseits von Apache-Kinprozessen gestartet wurden
RLimitNPROC Zahl|max [Zahl|max]
unbestimmt; verwendet die Voreinstellung des Systems
server config
virtual host
directory
.htaccess
All

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 `kann nicht abspalten` in der Datei `error_log`.

RLimitMEM
RLimitCPU
Satisfy
Zusammenspiel von rechnerbasierter Zugriffskontrolle und Benutzerauthentisierung
Satisfy Any|All
Satisfy All
directory
.htaccess
AuthConfig

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
Allow
Require
ScriptInterpreterSource
Methode zur Ermittlung des Interpreters von CGI-Skripten
ScriptInterpreterSource Registry|Registry-Strict|Script
ScriptInterpreterSource Script
server config
virtual host
directory
.htaccess
FileInfo
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.

ServerAdmin
E-Mail-Adresse, die der Server in Fehlermeldungen einfügt, welche an den Client gesendet werden
ServerAdmin E-Mail-Adresse
server config
virtual host

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 www-admin@foo.example.com

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

ServerAlias
Alternativer Name für einen Host, der verwendet wird, wenn Anfragen einem namensbasierten virtuellen Host zugeordnet werden
ServerAlias Hostname [Hostname] ...
virtual host

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>
Apache-Dokumentation zu virtuellen Hosts
ServerName
Rechnername und Port, die der Server dazu verwendet, sich selbst zu identifizieren
ServerName voll-qualifizierter-Domainname[:port]
server config
virtual host
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 im Servernamen 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.

Probleme bezüglich DNS und Apache
Apache-Dokumentation zu virtuellen Hosts
UseCanonicalName
NameVirtualHost
ServerAlias
ServerPath
Veralteter URL-Pfad für einen namensbasierten virtuellen Host, auf den von einem inkompatiblen Browser zugegriffen wird
ServerPath URL-Pfad
virtual host

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

Apache-Dokumentation zu virtuellen Hosts
ServerRoot
Basisverzeichnis der Serverinstallation
ServerRoot Verzeichnis
ServerRoot /usr/local/apache
server config

Die Direktive ServerRoot bestimmt das Verzeichnis, in dem der Server installiert ist. Üblicherweise enthält es die Unterverzeichnisse `conf/` und `logs/`. Relative Pfadangaben für andere Konfigurationsdateien werden relativ zu diesem Verzeichnis betrachtet.

# Beispiel

ServerRoot /home/httpd
Die `httpd`-Option `-d`
Sicherheitshinweise für Informationen, wie die Rechte auf das ServerRoot-Verzeichnis richtig gesetzt werden
ServerSignature
Konfiguriert die Fußzeile von servergenerierten Dokumenten
ServerSignature On|Off|EMail
ServerSignature Off
server config
virtual host
directory
.htaccess
All

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.

ServerTokens
ServerTokens
Konfiguriert den HTTP-Response-Header `Server`
ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full
ServerTokens Full
server config

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.

ServerSignature
SetHandler
Erzwingt die Verarbeitung aller passenden Dateien durch einen Handler
SetHandler Handlername|None
server config
virtual host
directory
.htaccess
FileInfo
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.

AddHandler
SetInputFilter
Bestimmt die Filter, die Client-Anfragen und POST-Eingaben verarbeiten
SetInputFilter Filter[;Filter...]
server config
virtual host
directory
.htaccess
FileInfo

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.

Filter-Dokumentation
SetOutputFilter
Bestimmt die Filter, die Antworten des Servers verarbeiten
SetOutputFilter Filter[;Filter...]
server config
virtual host
directory
.htaccess
FileInfo

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.

Filter-Dokumentation
TimeOut
Zeitspanne, die der Server auf verschiedene Ereignisse wartet, bevor er die Anfrage abbricht
TimeOut Sekunden
TimeOut 300
server config

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
Bestimmt, wie der Server seinen eigenen Namen und Port ermittelt
UseCanonicalName On|Off|DNS
UseCanonicalName On
server config
virtual host
directory

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

ServerName
Listen
VirtualHost
Enthält Direktiven, die nur auf bestimmte Hostnamen oder IP-Adressen angewendet werden
<VirtualHost Adresse[:Port] [Adresse[:Port]] ...> ... </VirtualHost>
server config

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.

# Beispiel

<VirtualHost 10.1.2.3>
ServerAdmin webmaster@host.foo.com
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 webmaster@host.example.com
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.

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