Apache HTTP Server Version 2.5
Beschreibung: | Ständig verfügbare Kernfunktionen des Apache HTTP Servers |
---|---|
Status: | Core |
Beschreibung: | Konfiguriert Optimierungen für lauschende Sockets bestimmter Protokolle |
---|---|
Syntax: | AcceptFilter Protokoll Filter |
Kontext: | Serverkonfiguration |
Status: | Core |
Modul: | core |
Kompatibilität: | Verfügbar ab Apache 2.1.5 |
Diese Direktive aktiviert betriebssystemspezifische Optimierungen
für lauschende Sockets anhand des Protokolltyps. Der grundlegende
Ansatz ist, dass der Kernel das Socket nicht an den Serverprozess
übergibt, bis entweder Daten verfügbar sind oder eine komplette
HTTP-Anfrage zwischengespeichert wurde. Derzeit werden
ausschließlich die Accept-Filter von FreeBSD und das primitivere
TCP_DEFER_ACCEPT
von Linux unterstützt.
Die Standardeinstellungen für FreeBSD sind:
AcceptFilter http httpready
AcceptFilter https dataready
Der httpready
-Accept-Filter puffert komplette
HTTP-Anfragen auf Kernelebene. Sobald eine Anfrage vollständig
vorliegt, schickt der Kernel sie an den Server weiter. Bitte schlagen Sie
in der accf_http(9)-Manpage für weitere Details nach. HTTPS-Anfragen
sind verschlüsselt. Daher wird dafür nur der accf_data(9)-Filter verwendet.
Die Standardeinstellungen für Linux sind:
AcceptFilter http data
AcceptFilter https data
TCP_DEFER_ACCEPT
unter Linux unterstützt keine
Zwischenspeicherung von HTTP-Anfragen. Jeder andere Wert als
none
aktiviert TCP_DEFER_ACCEPT
auf dem
Lauschsocket. Mehr Details finden Sie in der tcp(7)-Manpage von Linux.
Wenn Sie none
als Argument verwenden, werden alle
Accept-Filter für das Protokoll abgeschaltet. Das ist sinnvoll
für Protokolle, bei denen der Server zuerst Daten senden muss,
wie zum Beispiel nntp
:
AcceptFilter nttp none
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
/test/here.html/more
im obigen Beispiel, den Fehler
404 NOT FOUND (Anm.d.Ü.: nicht gefunden)
zurückgeben.On
/test/here.html/more
wird akzeptiert,
wenn /test/here.html
auf eine gültige Datei
zeigt.Default
PATH_INFO
-Zugriffe
standardmäßig zurück. Handler, die Skripte bedienen,
wie z.B. cgi-script und
isapi-handler, 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>
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.
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.
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.
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.
Beschreibung: | Direktiven-Typen, die in .htaccess -Dateien
erlaubt sind. |
---|---|
Syntax: | AllowOverride All|None|Direktiven-Typ
[Direktiven-Typ] ... |
Voreinstellung: | AllowOverride None (2.3.9 und später), AllowOverride All (2.3.8 und früher) |
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.
AllowOverride
ist nur in <Directory>
-Abschnitten
gültig, die ohne reguläre Ausdrücke 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.
AuthDBMGroupFile
,
AuthDBMUserFile
,
AuthGroupFile
,
AuthName
,
AuthType
, AuthUserFile
, Require
usw.).DefaultType
, ErrorDocument
, ForceType
, LanguagePriority
,
SetHandler
, SetInputFilter
, SetOutputFilter
, und
mod_mime
-Direktiven Add* und Remove*
usw.), Metadaten (Header
, RequestHeader
, SetEnvIf
, SetEnvIfNoCase
, BrowserMatch
, CookieExpires
, CookieDomain
, CookieStyle
, CookieTracking
, CookieName
),
mod_rewrite
-Direktiven RewriteEngine
, RewriteOptions
, RewriteBase
, RewriteCond
, RewriteRule
) und
Action
aus
mod_actions
.
AddDescription
,
AddIcon
, AddIconByEncoding
,
AddIconByType
,
DefaultIcon
, DirectoryIndex
,
FancyIndexing
, HeaderName
, IndexIgnore
, IndexOptions
, ReadmeName
usw.).Allow
, Deny
und Order
).Options
und XBitHack
). Sie
können mit einem Gleichheitszeichen gefolgt von einer
kommaseparierten Liste (ohne Leerzeichen) angeben, welche Optionen mit
der Options
-Direktive gesetzt
werden dürfen.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.
Beschreibung: | Individual directives that are allowed in
.htaccess files |
---|---|
Syntax: | AllowOverrideList None|directive
[directive-type] ... |
Voreinstellung: | AllowOverrideList None |
Kontext: | Verzeichnis |
Status: | Core |
Modul: | core |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
Beschreibung: | Set the minimum filter type eligible for asynchronous handling |
---|---|
Syntax: | AsyncFilter request|connection|network |
Voreinstellung: | AsyncFilter request |
Kontext: | Serverkonfiguration, Virtual Host |
Status: | Core |
Modul: | core |
Kompatibilität: | Only available from Apache 2.5.0 and later. |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
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.
Beschreibung: | Enables passing HTTP authorization headers to scripts as CGI variables |
---|---|
Syntax: | CGIPassAuth On|Off |
Voreinstellung: | CGIPassAuth Off |
Kontext: | Verzeichnis, .htaccess |
AllowOverride: | AuthConfig |
Status: | Core |
Modul: | core |
Kompatibilität: | Available in Apache HTTP Server 2.4.13 and later |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
Beschreibung: | Controls how some CGI variables are set |
---|---|
Syntax: | CGIVar variable rule |
Kontext: | Verzeichnis, .htaccess |
AllowOverride: | FileInfo |
Status: | Core |
Modul: | core |
Kompatibilität: | Available in Apache HTTP Server 2.4.21 and later |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
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. RFC2616
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.
Beschreibung: | Base directory for the server run-time files |
---|---|
Syntax: | DefaultRuntimeDir directory-path |
Voreinstellung: | DefaultRuntimeDir DEFAULT_REL_RUNTIMEDIR (logs/) |
Kontext: | Serverkonfiguration |
Status: | Core |
Modul: | core |
Kompatibilität: | Available in Apache 2.4.2 and later |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
ServerRoot
Beschreibung: | Base directory for the persistent state files |
---|---|
Syntax: | DefaultStateDir directory-path |
Voreinstellung: | DefaultStateDir DEFAULT_REL_STATEDIR (state/) |
Kontext: | Serverkonfiguration |
Status: | Core |
Modul: | core |
Kompatibilität: | Available in Apache 2.5.1 and later |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
ServerRoot
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.
Beschreibung: | Define the existence of a variable |
---|---|
Syntax: | Define Parametername |
Kontext: | Serverkonfiguration |
Status: | Core |
Modul: | core |
Equivalent zum übergeben von Parametername mittels des
-D
Arguments an httpd
.
Diese Directive kann verwendet werden, um die Nutzung von <IfDefine>
Sectionen umzuschalten, ohne die
-D
Argumentente in etwaigen Start-Skripten ändern
zu müssen.
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:
AllowOverride None
an
(deaktiviere .htaccess
-Dateien).AllowOverride FileInfo
(auf das Verzeichnis /home
) an.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.
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.
<Directory>
für eine Beschreibung, wie reguläre Ausdrücke mit
normalen <Directory>
-Anweisungen
vermischt werden.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
. Wenn das Verzeichnis nicht
absolut angegeben ist, wird es relativ zu ServerRoot
betrachtet.
DocumentRoot
sollte ohne einen
Schrägstrich am Ende angegeben werden.
Beschreibung: | Contains directives that apply only if the condition of a
previous <If> or
<ElseIf> section is not
satisfied by a request at runtime |
---|---|
Syntax: | <Else> ... </Else> |
Kontext: | Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess |
AllowOverride: | All |
Status: | Core |
Modul: | core |
Kompatibilität: | Nested conditions are evaluated in 2.4.26 and later |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
<If>
<ElseIf>
<If>
,
<ElseIf>
, and
<Else>
are applied last.Beschreibung: | Contains directives that apply only if a condition is satisfied
by a request at runtime while the condition of a previous
<If> or
<ElseIf> section is not
satisfied |
---|---|
Syntax: | <ElseIf expression> ... </ElseIf> |
Kontext: | Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess |
AllowOverride: | All |
Status: | Core |
Modul: | core |
Kompatibilität: | Nested conditions are evaluated in 2.4.26 and later |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
<If>
<Else>
<If>
,
<ElseIf>
, and
<Else>
are applied last.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:
httpd
reduzieren.DocumentRoot
kann httpd
mit
einem Speicherzugriffsfehler (Anm.d.Ü.: ein so genannter "segmentation
fault") abstürzen, wenn eine Datei gelöscht oder
gekürzt wird, während httpd
sie im Speicher
abbildet.Bei Serverkonfigurationen, die für dieses Problem anfällig sind, sollten Sie das Memory-Mapping für auszuliefernde Dateien deaktivieren, indem Sie schreiben:
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>
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:
DocumentRoot
(z.B. NFS oder SMB) ist der
Kernel möglicherweise nicht in der Lage, die Netzwerkdatei
über seinen eigenen Cache zu bedienen.sendfile
in Verbindung mit bestimmten Netzwerkkarten und IPv6
TCP-Checksummenfehler aus.Bei Serverkonfigurationen, die für dieses Problam anfällig sind, sollten die diese Funktion deaktivieren, indem Sie schreiben:
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>
Beachten Sie bitte, dass die verzeichnisbasierte und
.htaccess-Konfiguration von EnableSendfile
nicht vom mod_cache_disk
-Modul unterstützt wird.
Nur die globale Konfiguration von EnableSendfile
wird vom Modul beachtet.
Beschreibung: | Abort configuration parsing with a custom error message |
---|---|
Syntax: | Error message |
Kontext: | Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess |
AllowOverride: | All |
Status: | Core |
Modul: | core |
Kompatibilität: | 2.3.9 and later |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
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:
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 Webpfaden mit einem Schrägstrich
(/) beginnen (relativ zum DocumentRoot
-Verzeichnis) oder eine vollständige 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 der spezielle Wert default
angegeben
werden, um die schlichte, hartkodierte Nachricht des Apache zu verwenden.
Es wird normalerweise nicht benötigt, doch default
stellt die einfach, im Apache hartkodierte Meldung in Konfigurationen
wieder her, die ansonsten von einem existierenden (Anm.d.Ü.: zuvor
konfigurierten) ErrorDocument
erben
würden.
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 verfügbar.
Obwohl die meisten Fehlermeldungen überschrieben werden
können, werden unter bestimmten Umständen die internen
Meldungen ungeachtet der Einstellung der ErrorDocument
-Direktive verwendet. Insbesondere bei
einer fehlerhaften Anfrage werden der normale Bearbeitungsprozess sofort
beendet und die interne Meldung zurückgegeben. Das ist notwendig, um
Sicherheitsprobleme zu vermeiden, die auf Grund fehlerhafter Anfragen
entstehen.
In Versionen vor 2.0 wurden Meldungen durch ein einzelnes vorangestelltes Anführungszeichen (") erkannt.
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.
Wenn Dateiname nicht absolut ist, wird er relativ zu ServerRoot
betrachtet.
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.
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.
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.
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.
Beschreibung: | Format specification for error log entries |
---|---|
Syntax: | ErrorLogFormat [connection|request] format |
Kontext: | Serverkonfiguration, Virtual Host |
Status: | Core |
Modul: | core |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
Beschreibung: | Keep track of extended status information for each request |
---|---|
Syntax: | ExtendedStatus On|Off |
Voreinstellung: | ExtendedStatus Off[*] |
Kontext: | Serverkonfiguration |
Status: | Core |
Modul: | core |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
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:
FileETag INode MTime Size
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
.
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.
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.
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>
Beschreibung: | Directory to write gmon.out profiling data to. |
---|---|
Syntax: | GprofDir /tmp/gprof/|/tmp/gprof/% |
Kontext: | Serverkonfiguration, Virtual Host |
Status: | Core |
Modul: | core |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
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_authz_host
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 von
protokollierten IP-Adressen nachzuschlagen.
Beschreibung: | Modify restrictions on HTTP Request Messages |
---|---|
Syntax: | HttpProtocolOptions [Strict|Unsafe] [RegisteredMethods|LenientMethods]
[Allow0.9|Require1.0] |
Voreinstellung: | HttpProtocolOptions Strict LenientMethods Allow0.9 |
Kontext: | Serverkonfiguration, Virtual Host |
Status: | Core |
Modul: | core |
Kompatibilität: | 2.2.32 or 2.4.24 and later |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
Beschreibung: | Contains directives that apply only if a condition is satisfied by a request at runtime |
---|---|
Syntax: | <If expression> ... </If> |
Kontext: | Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess |
AllowOverride: | All |
Status: | Core |
Modul: | core |
Kompatibilität: | Nested conditions are evaluated in 2.4.26 and later |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
<ElseIf>
<Else>
<If>
,
<ElseIf>
, and
<Else>
are applied last.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:
!
ParameternameIm 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>
Beschreibung: | Encloses directives that are processed conditional on the presence or absence of a specific directive |
---|---|
Syntax: | <IfDirective [!]directive-name> ...
</IfDirective> |
Kontext: | Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess |
AllowOverride: | All |
Status: | Core |
Modul: | core |
Kompatibilität: | Available in 2.4.34 and later |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
Beschreibung: | Encloses directives that will be processed only if file exists at startup |
---|---|
Syntax: | <IfFile [!]parameter-name> ...
</IfFile> |
Kontext: | Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess |
AllowOverride: | All |
Status: | Core |
Modul: | core |
Kompatibilität: | Available in 2.4.34 and later |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
Beschreibung: | Schließt Direktiven ein, die abhängig vom Vorhandensein oder Fehlen eines speziellen Moduls ausgeführt werden |
---|---|
Syntax: | <IfModule [!]Modulname|Modulbezeichner>
... </IfModule> |
Kontext: | Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess |
AllowOverride: | All |
Status: | Core |
Modul: | core |
Kompatibilität: | Modulbezeichner sind ab Version 2.1 verfügbar. |
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:
!
ModulIm ersten Fall werden die Direktiven zwischen der Start- und
Endemarkierung nur ausgeführt, das Modul namens
Modul 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 Modul nicht
enthalten ist.
Das Argument Modul kann entweder der Modulbezeichner oder
der Dateiname des Moduls zum Zeitpunkt seiner Kompilierung sein.
rewrite_module
beispielsweise ist der Bezeichner und
mod_rewrite.c
ist der Dateiname. 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.
Beschreibung: | Encloses directives that are processed conditional on the presence or absence of a specific section directive |
---|---|
Syntax: | <IfSection [!]section-name> ...
</IfSection> |
Kontext: | Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess |
AllowOverride: | All |
Status: | Core |
Modul: | core |
Kompatibilität: | Available in 2.4.34 and later |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
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
Beschreibung: | Includes other configuration files from within the server configuration files |
---|---|
Syntax: | IncludeOptional file-path|directory-path|wildcard |
Kontext: | Serverkonfiguration, Virtual Host, Verzeichnis |
Status: | Core |
Modul: | core |
Kompatibilität: | Available in 2.3.6 and later. Not existent file paths without wildcards do not cause SyntaxError after 2.4.30 |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
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.
Beschreibung: | Zeitspanne, die der Server während persistenter Verbindungen auf nachfolgende Anfragen wartet |
---|---|
Syntax: | KeepAliveTimeout Sekunden |
Voreinstellung: | KeepAliveTimeout 5 |
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.
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.
<LimitExcept>
-Container sollte immer einem <Limit>
-Container vorgezogen
werden, da <LimitExcept>
einen Schutz gegen beliebige Methoden bietet.
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>
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.
LimitInternalRecursion 5
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
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
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 an, die in einem HTTP-Header erlaubt sind.
Die Direktive LimitRequestFieldsize
erlaubt es
dem Serveradministrator, die maximale Größe eines
HTTP-Request-Headers zu verringern oder erhöhen. 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.
SPNEGO-Authentisierungs-Header können bis zu 12392 Bytes lang
sein.
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
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 fest, die in der HTTP-Anfragezeile erlaubt sind.
Die Direktive LimitRequestLine
erlaubt es dem
Serveradministrator, die maximale Größe der
HTTP-Anfragezeile zu verringern oder erhöhen. 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
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
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.
<Location>
verwendet werdenVerwenden 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>
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.
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.
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
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.
Beschreibung: | Override the verbosity of the ErrorLog for certain clients |
---|---|
Syntax: | LogLevel ipaddress[/prefixlen]
[module:]level [module:level] ...
|
Voreinstellung: | unset |
Kontext: | Serverkonfiguration, Virtual Host |
Status: | Core |
Modul: | core |
Kompatibilität: | Available in Apache HTTP Server 2.5.0 and later |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
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
Beschreibung: | Number of overlapping ranges (eg: 100-200,150-300 ) allowed before returning the complete
resource |
---|---|
Syntax: | MaxRangeOverlaps default | unlimited | none | number-of-ranges |
Voreinstellung: | MaxRangeOverlaps 20 |
Kontext: | Serverkonfiguration, Virtual Host, Verzeichnis |
Status: | Core |
Modul: | core |
Kompatibilität: | Available in Apache HTTP Server 2.3.15 and later |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
Beschreibung: | Number of range reversals (eg: 100-200,50-70 ) allowed before returning the complete
resource |
---|---|
Syntax: | MaxRangeReversals default | unlimited | none | number-of-ranges |
Voreinstellung: | MaxRangeReversals 20 |
Kontext: | Serverkonfiguration, Virtual Host, Verzeichnis |
Status: | Core |
Modul: | core |
Kompatibilität: | Available in Apache HTTP Server 2.3.15 and later |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
Beschreibung: | Number of ranges allowed before returning the complete resource |
---|---|
Syntax: | MaxRanges default | unlimited | none | number-of-ranges |
Voreinstellung: | MaxRanges 200 |
Kontext: | Serverkonfiguration, Virtual Host, Verzeichnis |
Status: | Core |
Modul: | core |
Kompatibilität: | Available in Apache HTTP Server 2.3.15 and later |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
Beschreibung: | Controls whether the server merges consecutive slashes in URLs. |
---|---|
Syntax: | MergeSlashes ON|OFF |
Voreinstellung: | MergeSlashes ON |
Kontext: | Serverkonfiguration, Virtual Host |
Status: | Core |
Modul: | core |
Kompatibilität: | Added in 2.5.1 |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
Beschreibung: | Determines whether trailers are merged into headers |
---|---|
Syntax: | MergeTrailers [on|off] |
Voreinstellung: | MergeTrailers off |
Kontext: | Serverkonfiguration, Virtual Host |
Status: | Core |
Modul: | core |
Kompatibilität: | 2.4.11 and later |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
Beschreibung: | Configures mutex mechanism and lock file directory for all or specified mutexes |
---|---|
Syntax: | Mutex mechanism [default|mutex-name] ... [OmitPID] |
Voreinstellung: | Mutex default |
Kontext: | Serverkonfiguration |
Status: | Core |
Modul: | core |
Kompatibilität: | Available in Apache HTTP Server 2.3.4 and later |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
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.
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
VirtualHost
s 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 [2001:db8::a00:20ff:fea7:ccea]:8080
Um an allen Schnittstellen Anfragen zu empfangen, können Sie
*
als Argument verwenden.
NameVirtualHost *
<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>
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
MultiViews
. Dies ist
die Voreinstellung.ExecCGI
mod_cgi
verwenden, ist erlaubt.FollowSymLinks
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
mod_include
bereitgestellt
werden, sind erlaubt.IncludesNOEXEC
#exec cmd
und #exec cgi
sind jedoch deaktiviert. Es ist aber noch
möglich, CGI-Skripte aus
ScriptAlias
-Verzeichnissen mittels
#include virtual
einzubinden.Indexes
DirectoryIndex
definierte
Indexdatei (z.B. index.html
) befindet, dann liefert
mod_autoindex
eine formatierte Auflistung des
Verzeichnisses zurück.MultiViews
mod_negotiation
erlaubt (siehe Content-Negotiation).SymLinksIfOwnerMatch
<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.
Die Vermischung von Optionen mit +
oder -
mit
Optionen ohne diese (Zeichen) ist keine gültige Syntax und führt
mit hoher Wahrscheinlichkeit zu unerwarteten Effekten.
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.
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.
Beschreibung: | Protocol for a listening socket |
---|---|
Syntax: | Protocol protocol |
Kontext: | Serverkonfiguration, Virtual Host |
Status: | Core |
Modul: | core |
Kompatibilität: | On Windows, only available from Apache 2.3.3 and later. |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
Beschreibung: | Protocols available for a server/virtual host |
---|---|
Syntax: | Protocols protocol ... |
Voreinstellung: | Protocols http/1.1 |
Kontext: | Serverkonfiguration, Virtual Host |
Status: | Core |
Modul: | core |
Kompatibilität: | Only available from Apache 2.4.17 and later. |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
Beschreibung: | Determines if order of Protocols determines precedence during negotiation |
---|---|
Syntax: | ProtocolsHonorOrder On|Off |
Voreinstellung: | ProtocolsHonorOrder On |
Kontext: | Serverkonfiguration, Virtual Host |
Status: | Core |
Modul: | core |
Kompatibilität: | Only available from Apache 2.4.17 and later. |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
Beschreibung: | Controls whether the REDIRECT_URL environment variable is fully qualified |
---|---|
Syntax: | QualifyRedirectURL On|Off |
Voreinstellung: | QualifyRedirectURL Off |
Kontext: | Serverkonfiguration, Virtual Host, Verzeichnis |
AllowOverride: | FileInfo |
Status: | Core |
Modul: | core |
Kompatibilität: | Directive supported in 2.4.18 and later. 2.4.17 acted as if 'QualifyRedirectURL On' was configured. |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
Beschreibung: | Allow to configure global/default options for regexes |
---|---|
Syntax: | RegexDefaultOptions [none] [+|-]option [[+|-]option] ... |
Voreinstellung: | RegexDefaultOptions DOTALL DOLLAR_ENDONLY |
Kontext: | Serverkonfiguration |
Status: | Core |
Modul: | core |
Kompatibilität: | Only available from Apache 2.4.30 and later. |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
Beschreibung: | Register non-standard HTTP methods |
---|---|
Syntax: | RegisterHttpMethod method [method [...]] |
Kontext: | Serverkonfiguration |
Status: | Core |
Modul: | core |
Kompatibilität: | Available in Apache HTTP Server 2.4.24 and later |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
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.
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.
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.
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
.
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 der Schlüssel zur Dateiendung oder
beide Unterschlüssel fehlen, dann verwendet der Apache die Option
Script
.
Seien Sie vorsichtig, ScriptInterpreterSource Registry
bei
Verzeichnissen zu verwenden, auf die eine ScriptAlias
-Anweisung zeigt, denn der
Apache versucht 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 im Hintergrund
starten würde. Dies ist eine wirksame Methode, 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 eingerichtet werden und schützt Ihr System so for
versehentlichen Programmaufrufen.
Beschreibung: | Determine if mod_status displays the first 63 characters of a request or the last 63, assuming the request itself is greater than 63 chars. |
---|---|
Syntax: | SeeRequestTail On|Off |
Voreinstellung: | SeeRequestTail Off |
Kontext: | Serverkonfiguration |
Status: | Core |
Modul: | core |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
Beschreibung: | E-Mail-Adresse, die der Server in Fehlermeldungen einfügt, welche an den Client gesendet werden |
---|---|
Syntax: | ServerAdmin E-Mail-Adresse|URL |
Kontext: | Serverkonfiguration, Virtual Host |
Status: | Core |
Modul: | core |
ServerAdmin
legt die Kontaktadresse fest,
die der Server in jede Fehlermeldung einfügt, die er an den
Client zurückschickt. Wenn httpd
das übergebene
Argument nicht als URL erkennt, nimmt er an, dess es sich um eine
E-Mail-Adresse handelt und stellt in Hyperlinks
mailto:
voran. Es ist jedoch sogar sinnvoll, eine
E-Mail-Adresse zu verwenden, da viele CGI-Skripte davon ausgehen. Wenn Sie
eine URL verwenden möchten, sollten Sie auf einem anderen unter Ihrer
Kontrolle stehenden Server verweisen. Andernfalls können Besucher Sie
im Fehlerfall möglicherweise nicht kontaktieren.
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!
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>
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 Port 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 Direktiven UseCanonicalName
und UseCanonicalPhysicalPort
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.
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.
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.
ServerRoot /home/httpd
httpd
-Option
-d
ServerRoot
-Verzeichnis richtig gesetzt werdenBeschreibung: | 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.
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]
Server:
Apache
ServerTokens Major
Server:
Apache/2
ServerTokens Minor
Server:
Apache/2.0
ServerTokens Min[imal]
Server:
Apache/2.0.41
ServerTokens OS
Server: Apache/2.0.41
(Unix)
ServerTokens Full
(oder nicht angegeben)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.
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.
Hinweis: SetHandler setzt die Standard-Handler außer Kraft und unterdrückt gewohnte Verhaltensweisen, wie beispielsweise die Behandlung von URLs, die auf einen Schrägstrich (/) enden als Verzeichnisse oder (die Auslieferung von) Index-Dateien.
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.
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.
Beschreibung: | Controls whether the server requires the requested hostname be listed enumerated in the virtual host handling the request |
---|---|
Syntax: | StrictHostCheck ON|OFF |
Voreinstellung: | StrictHostCheck OFF |
Kontext: | Serverkonfiguration, Virtual Host |
Status: | Core |
Modul: | core |
Kompatibilität: | Added in 2.5.1 |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
Beschreibung: | Zeitspanne, die der Server auf verschiedene Ereignisse wartet, bevor er die Anfrage abbricht |
---|---|
Syntax: | TimeOut Sekunden |
Voreinstellung: | TimeOut 60 |
Kontext: | Serverkonfiguration |
Status: | Core |
Modul: | core |
Die Direktive TimeOut
definiert derzeit die
Zeitspanne, die der Apache auf drei Dinge wartet:
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. Seit Apache 2.4 ist die Voreinstellung 60.
Beschreibung: | Legt das Verhalten von TRACE -Anfragen fest |
---|---|
Syntax: | TraceEnable [on|off|extended] |
Voreinstellung: | TraceEnable on |
Kontext: | Serverkonfiguration |
Status: | Core |
Modul: | core |
Kompatibilität: | Verfügbar ab Apache 1.3.34 und 2.0.55 |
Diese Direktive beeinflusst das Verhalten von TRACE
sowohl
für den Server selbst als auch mod_proxy
. Die
Voreinstellung TraceEnable on
erlaubt
TRACE
-Anfragen gemäß RFC 2616. Dort werden
nur Anfragen ohne Datenteil zugelassen. TraceEnable off
sorgt dafür, dass der Serverkern und mod_proxy
den
Fehler 405
(Zugriffsmethode nicht erlaubt) an den Client
senden.
Zu Test- und Diagnosezwecken können Sie auch
nicht-standardkonforme Anfragen mit Datenteil erlauben, indem Sie die
Direktive TraceEnable extended
verwenden. Der Server (als
Ursprungsserver) beschränkt den Anfrageinhalt auf 64k. (Wenn
Transfer-Encoding: chunked
benutzt wird, können
weitere 8k für die Chunk-Kopfzeilen verwendet werden.) Der
Server selbst reflektiert dann die vollständigen HTTP- und
Chunk-Kopfzeilen in seiner Antwort. Die Einschränkung auf 64k gilt
nicht, wenn der Server als Proxy arbeitet.
Beschreibung: | Undefine the existence of a variable |
---|---|
Syntax: | UnDefine parameter-name |
Kontext: | Serverkonfiguration, Virtual Host |
Status: | Core |
Modul: | core |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.
Beschreibung: | Bestimmt, wie der Server seinen eigenen Namen und Port ermittelt |
---|---|
Syntax: | UseCanonicalName On|Off|DNS |
Voreinstellung: | UseCanonicalName Off |
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.
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.
Beschreibung: | Bestimmt, wie der Server seinen eigenen Namen und Port ermittelt |
---|---|
Syntax: | UseCanonicalPhysicalPort On|Off |
Voreinstellung: | UseCanonicalPhysicalPort Off |
Kontext: | Serverkonfiguration, Virtual Host, Verzeichnis |
Status: | Core |
Modul: | core |
In vielen Situationen muss der Apache eine
selbstreferenzierende URL zusammenbauen, d.h. eine URL, die auf
den selben Server zurück verweist. Wenn der Apache für die
UseCanonicalName
-Direktive den Port
bestimmt, wird mit UseCanonicalPhysicalPort On
die
tatsächlich für die Anfrage verwendete physische Portnummer
in Betracht gezogen. Mit UseCanonicalPhysicalPort Off
verläßt sich der Apache nur auf die Konfiguration, um eine
gültige Portnummer zu bestimmen und läßt die
physische Portnummer außer acht.
Wenn der physische Port verwendet wird, ist die Reihenfolge wie
folgt:
UseCanonicalName On
Servername
angegebene PortUseCanonicalName Off | DNS
Host:
-Header gewonnen wurdeServername
angegebene PortBei UseCanonicalPhysicalPort Off
werden die physischen
Ports aus der Suchreihe entfernt.
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:
*
, welches nur in Kombination mit
NameVirtualHost *
verwendet wird, um allen IP-Adressen
zu entsprechen._default_
, die nur mit IP-basierten
virtuellen Hosts verwendet wird, um nicht zugewiesene IP-Adressen
aufzufangen.
<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 [2001:db8::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).
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 virtuellen 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-Adressen 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 virtuell 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.)
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.
Beschreibung: | Warn from configuration parsing with a custom message |
---|---|
Syntax: | Warning message |
Kontext: | Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess |
AllowOverride: | All |
Status: | Core |
Modul: | core |
Kompatibilität: | 2.5 and later |
Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.