Apache-Kernfunktionen

+ +

Beschreibung:	Ständig verfügbare Kernfunktionen des Apache HTTP +Servers
Status:	Core

Direktiven

AcceptPathInfo
AccessFileName
AddDefaultCharset
AddOutputFilterByType
AllowOverride
AuthName
AuthType
CGIMapExtension
ContentDigest
DefaultType
<Directory>
<DirectoryMatch>
DocumentRoot
EnableMMAP
EnableSendfile
ErrorDocument
ErrorLog
FileETag
<Files>
<FilesMatch>
ForceType
HostnameLookups
IdentityCheck
<IfDefine>
<IfModule>
Include
KeepAlive
KeepAliveTimeout
<Limit>
<LimitExcept>
LimitRequestBody
LimitRequestFields
LimitRequestFieldSize
LimitRequestLine
LimitXMLRequestBody
<Location>
<LocationMatch>
LogLevel
MaxKeepAliveRequests
NameVirtualHost
Options
Require
RLimitCPU
RLimitMEM
RLimitNPROC
Satisfy
ScriptInterpreterSource
ServerAdmin
ServerAlias
ServerName
ServerPath
ServerRoot
ServerSignature
ServerTokens
SetHandler
SetInputFilter
SetOutputFilter
TimeOut
UseCanonicalName
<VirtualHost>

+ +

AcceptPathInfo-Direktive

+ + + + + + + + + +

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

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

+ +

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

+ +

Die drei möglichen Argumente für die Direktive + AcceptPathInfo sind:

+ +

Off: Eine Anfrage wird nur dann akzeptiert, + wenn sie exakt auf ein existierendes Verzeichnis (oder eine Datei) + abgebildet werden kann. Daher würde eine Anfrage mit einer nach dem + tatsächlichen Dateinamen angehängten Pfadangabe, wie + /test/here.html/more im obigen Beispiel, den Fehler + 404 NOT FOUND (Anm.d.Ü.: nicht gefunden) + zurückgeben.
On: Eine Anfrage wird akzeptiert, wenn eine vorangestellte Pfadangabe + auf ein existierendes Verzeichnis abgebildet werden kann. Das + obige Beispiel /test/here.html/more wird akzeptiert, + wenn /test/here.html auf eine gültige Datei + zeigt.
Default: Die Behandlung von Anfragen mit angehängten Pfadangaben + wird von dem für die Anfrage verantwortlichen Handler bestimmt. Der Core-Handler + für gewöhnliche Dateien weist PATH_INFO-Zugriffe + standardmäßig zurück. Handler, die Skripte bedienen, + wie z.B. cgi-script und + isapi-isa, sind im Allgemeinen darauf + voreingestellt, PATH_INFO zu akzeptieren.

+ +

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

+ +

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

+ + +

AccessFileName-Direktive

+ + + + + + + +

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

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

+ +

+ AccessFileName .acl +

+ +

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

+ +

+ <Directory /> + + AllowOverride None + + </Directory> +

+ +

deaktiviert wurden.

+ +

Siehe auch

AddDefaultCharset-Direktive

+ + + + + + + + +

Beschreibung:	Standard-Zeichenkodierung für Antworten ohne +explizit angegebene Zeichenkodierung +
Syntax:	`AddDefaultCharset On\|Off\|Zeichenkodierung`
Voreinstellung:	`AddDefaultCharset Off`
Kontext:	Serverkonfiguration, Virtual Host, Verzeichnis, .htaccess
AllowOverride:	FileInfo
Status:	Core
Modul:	core

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

+ +

+ AddDefaultCharset utf-8 +

+ +

AddOutputFilterByType-Direktive

+ + + + + + + + +

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

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

+ +

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

+ +

+ AddOutputFilterByType DEFLATE text/html text/plain +

+ +

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

+ +

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

+ +

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

+ +

Hinweis:

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

+ +

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

+ +

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

+ +

Siehe auch

AllowOverride-Direktive

+ + + + + + + +

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

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

+ +

Nun in <Directory>-Abschnitten verfügbar

+ AllowOverride ist nur in <Directory>-Abschnitten + gültig, nicht in <Location>- oder <Files>-Abschnitten. +

+ +

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

+ +

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

+ +

Der Direktiven-Typ kann eine der folgenden + Anweisungsgruppen sein.

+ +

AuthConfig: + Erlaubt die Verwendung von Autorisierungs-Anweisungen (AuthDBMGroupFile, + AuthDBMUserFile, + AuthGroupFile, + AuthName, + AuthType, AuthUserFile, Require usw.).
FileInfo: + Erlaubt die Verwendung von Direktiven zur Steuerung der + Dokumenttypen (DefaultType, ErrorDocument, ForceType, LanguagePriority, + SetHandler, SetInputFilter, SetOutputFilter, und + mod_mime-Direktiven Add* und Remove* + usw.).
Indexes: + Erlaubt die Verwendung von Direktiven zur Steuerung von + Verzeichnisindizes (AddDescription, + AddIcon, AddIconByEncoding, + AddIconByType, + DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName + usw.).
Limit: + Erlaubt die Verwendung von Direktiven zur Steuerung des + Zugriffs von Hosts (Allow, Deny und Order).
Options: + Erlaubt die Verwendung von Direktiven zur Steuerung spezieller + Verzeichniseigenschaften (Options + und XBitHack).

+ +

Beispiel:

+ +

+ AllowOverride AuthConfig Indexes +

+ +

Siehe auch

AuthName-Direktive

+ + + + + + + +

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

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

+ +

Beispiel:

+ +

+ AuthName "Top Secret" +

+ +

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

+ +

Siehe auch

Authentisierung, Autorisierung und + Zugriffskontrolle

AuthType-Direktive

+ + + + + + + +

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

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

+ +

Siehe auch

Authentisierung, Autorisierung und + Zugriffskontrolle

CGIMapExtension-Direktive

+ + + + + + + + + +

Beschreibung:	Technik zur Bestimmung des Interpreters für +CGI-Skripte
Syntax:	`CGIMapExtension CGI-Pfad .Endung`
Voreinstellung:	`None`
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.

+ +

ContentDigest-Direktive

+ + + + + + + + +

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

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

+ +

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

+ +

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

+ +

+ Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA== +

+ +

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

+ +

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

+ +

DefaultType-Direktive

+ + + + + + + + +

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

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

+ +

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

+ +

+ DefaultType image/gif +

+ +

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

+ +

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

+ +

<Directory>-Direktive

+ + + + + + +

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

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

+ <Directory /> + + AllowOverride None + + </Directory> + + <Directory /home/> + + AllowOverride FileInfo + + </Directory> +

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

ändern und anschließend für + Verzeichnisse überschreiben, die Sie verfügbar machen + wollen. Für weitere Einzelheiten lesen Sie bitte + die Seite zu den Sicherheitshinweisen.

+ +

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

+ +

Siehe auch

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

<DirectoryMatch>-Direktive

+ + + + + + +

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

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

+ +

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

+ +

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

+ +

Siehe auch

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

DocumentRoot-Direktive

+ + + + + + + +

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

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

+ +

+ DocumentRoot /usr/web +

+ +

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

+ +

DocumentRoot sollte ohne einen + Schrägstrich am Ende angegeben werden.

+ +

Siehe auch

URLs auf das Dateisystem +abbilden

EnableMMAP-Direktive

+ + + + + + + + +

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

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

+ +

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

+ +

Bei einigen Multiprozessorsystemen kann Memory-Mapping die + Performance von httpd reduzieren.
Bei einem per NFS eingebundenen DocumentRoot kann httpd mit einem + Segmentierungsfehler (Anm.d.Ü.: ein sogenannter "segmentation + fault") abstürzen, wenn eine Datei gelöscht oder + gekürzt wird, während httpd sie im Speicher + abbildet.

+ +

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

+ +

+ EnableMMAP Off +

+ +

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

+ +

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

+ +

EnableSendfile-Direktive

+ + + + + + + + + +

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

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

+ +

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

+ +

Einige Plattformen besitzen u.U. eine fehlerhafte + sendfile-Unterstützung, die das Erstellungssystem nicht erkennt, + insbesondere wenn die Binärdateien auf einem anderen Rechner erstellt + und auf eine solche Maschine mit fehlerhafter sendfile-Unterstützung + übertragen wurden.
Bei einem über das Netzwerk eingebundenen DocumentRoot (z.B. NFS oder SMB) ist der + Kernel möglicherweise nicht in der Lage, die Netzwerkdatei + über seinen eigenen Cache zu bedienen.

+ +

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

+ +

+ EnableSendfile Off +

+ +

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

+ +

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

+ +

ErrorDocument-Direktive

+ + + + + + + + +

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

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

Siehe auch

Dokumentation zu individuellen +Fehlermeldungen

ErrorLog-Direktive

+ + + + + + + +

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

Die Direktive ErrorLog bestimmt den Namen + der Datei, in welcher der Server alle auftretenden Fehler protokolliert. + Wenn Dateiname nicht absolut ist (im Allgemeinen: nicht mit + einem Schrägstrich (/) beginnt), wird er relativ zu ServerRoot betrachtet.

+ +

Beispiel

+ ErrorLog /var/log/httpd/error_log +

+ +

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

+ +

Beispiel

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

+ +

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

+ +

Beispiel

+ ErrorLog syslog:user +

+ +

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

+ +

Siehe auch

LogLevel
Apache-Log-Dateien

FileETag-Direktive

+ + + + + + + + +

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

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

+ +

INode: Die I-Node-Nummer wird in die Berechnung mit einbezogen
MTime: Datum und Uhrzeit der letzten Änderung werden mit einbezogen
Size: Die Anzahl der Bytes in der Datei wird mit einbezogen
All: Alle verfügbaren Angaben werden verwendet. Die ist + gleichbedeutend mit: +
FileETag INode MTime Size
None: Es wird keine ETag-Angabe in die Antwort eingefügt, + wenn dem Dokument eine Datei zugrundeliegt.

+ +

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

+ +

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

+ +

<Files>-Direktive

+ + + + + + + +

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

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

Siehe auch

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

<FilesMatch>-Direktive

+ + + + + + + +

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

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

+ +

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

+ +

auf die gebräuchlichsten Grafikformate im Internet passen.

+ +

Siehe auch

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

ForceType-Direktive

+ + + + + + + + +

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

+ +

HostnameLookups-Direktive

+ + + + + + + +

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

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

+ +

Unabhängig von der Einstellung wird ein Double-Reverse-Lookup + durchgeführt, wenn mod_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 + Offlassen. Das Hilfsprogramm logresolve, das + standardmäßig in das Unterverzeichnis bin + Ihres Installationsverzeichnisses kompiliert wird, kann dazu verwendet + werden, um offline Hostnamen zu protokollierten IP-Adressen + nachzuschlagen.

+ +

IdentityCheck-Direktive

+ + + + + + + +

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

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

+ +

Der Information sollte außer für eine rudimentäre + Benutzerverfolgung in keinster Weise vertraut werden.

+ +

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

+ +

<IfDefine>-Direktive

+ + + + + + + +

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

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

+ +

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

+ +

Parametername
!Parametername

+ +

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

+ +

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

+ +

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

+ +

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

+ +

<IfModule>-Direktive

+ + + + + + + +

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

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

+ +

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

+ +

Modulname
!Modulname

+ +

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

+ +

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

+ +

<IfModule>-Container können + inneinander verschachtelt werden, um einfache Multi-Modul-Tests + durchzuführen.

+ +

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

+ +

Include-Direktive

+ + + + + + + +

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 (d.h., er + beginnt mit einem Schrägstrich) sein oder relativ zum ServerRoot-Verzeichnis angegeben werden.

+ +

Beispiele:

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

Siehe auch

apachectl

KeepAlive-Direktive

+ + + + + + + +

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

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

+ +

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

+ +

Siehe auch

MaxKeepAliveRequests

KeepAliveTimeout-Direktive

+ + + + + + + +

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

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

+ +

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

+ +

<Limit>-Direktive

+ + + + + + + +

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

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

+ +

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

+ +

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

+ +

Sie können eine oder mehrere der folgenden Methoden angeben: + GET, POST, PUT, DELETE, + CONNECT, OPTIONS, TRACE, + 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.

+ +

<LimitExcept>-Direktive

+ + + + + + + +

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

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

+ +

Beispiel:

+ +

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

+ + +

LimitRequestBody-Direktive

+ + + + + + + + +

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

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

+ +

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

+ +

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

+ +

+ LimitRequestBody 102400 +

+ + +

LimitRequestFields-Direktive

+ + + + + + + +

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

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

+ +

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

+ +

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

+ +

Beispiel:

+ +

+ LimitRequestFields 50 +

+ + +

LimitRequestFieldSize-Direktive

+ + + + + + + +

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

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

+ +

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

+ +

Beispiel:

+ +

+ LimitRequestFieldSize 4094 +

+ +

Unter normalen Umständen sollte die Voreinstellung nicht + verändert werden.

+ +

LimitRequestLine-Direktive

+ + + + + + + +

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

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

+ +

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

+ +

Beispiel:

+ +

+ LimitRequestLine 4094 +

+ +

Unter normalen Umständen sollte die Voreinstellung nicht + verändert werden.

+ +

LimitXMLRequestBody-Direktive

+ + + + + + + + +

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

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

+ +

Beispiel:

+ +

+ LimitXMLRequestBody 0 +

+ + +

<Location>-Direktive

+ + + + + + +

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

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

+ +

Beachten Sie, dass URLs keineswegs mit dem Dateisystem + übereinstimmen müssen. Um es nochmal zu betonen, + <Location> operiert vollständig + außerhalb des Dateisystems.

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

Anmerkung zu / (Schrägstrich, Slash)

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

+ +

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

+ +

Siehe auch

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

<LocationMatch>-Direktive

+ + + + + + +

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

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

+ +

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

+ +

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

+ +

Siehe auch

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

LogLevel-Direktive

+ + + + + + + +

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 +

+ +

MaxKeepAliveRequests-Direktive

+ + + + + + + +

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

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

+ +

Beispiel:

+ +

+ MaxKeepAliveRequests 500 +

+ +

NameVirtualHost-Direktive

+ + + + + + +

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

Die Direktive NameVirtualHost ist erforderlich, + wenn Sie namensbasierte Virtual-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 Virtual-Hosts entgegennimmt. Das ist üblicherweise + die Adresse, zu der die Namen Ihrer namensbasierten Virtual-Hosts + aufgelöst werden. Falls eine Firewall oder ein anderer Proxy die + Anfrage in Empfang nimmt und Sie zu einer weiteren IP-Adresse des Servers + weiterleitet, müssen Sie die IP-Adresse der physikalischen + Schnittstelle der Maschine angeben, welche die Anfragen bedient. + Wenn Sie mehrere namensbasierte Hosts an verschiedenen Adressen + betreiben, wiederholen Sie einfach die Anweisung für jede + Adresse.

+ +

Anmerkung

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

+ +

Optional können Sie die Nummer eines Ports angeben, an dem + namensbasierte Virtual-Hosts verwendet werden sollen. Beispiel:

+ +

+ NameVirtualHost 111.22.33.44:8080 +

+ +

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

+ +

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

+ +

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

+ +

+ NameVirtualHost * +

+ +

Argument der Direktive `<VirtualHost>`

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

+ +

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

+ +

Siehe auch

Virtual-Host-Dokumentation

Options-Direktive

+ + + + + + + + +

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

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

+ +

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

+ +

All: Alle Optionen außer MultiViews. Dies ist + die Voreinstellung.
ExecCGI: Die Ausführung von CGI-Skripts ist erlaubt.
FollowSymLinks: Der Server folgt symbolischen Links in diesem Verzeichnis. +
+
Auch wenn der Server symbolischen Links folgt, bedeutet dies + nicht, dass der zum Abgleich gegen <Directory>-Abschnitte verwendete Pfadname + wechselt.
+
Beachten Sie auch, dass diese Option innerhalb eines + <Location>-Abschnitts + ignoriert wird.
+
Includes: + Server Side Includes sind erlaubt.
IncludesNOEXEC: Server Side Includes sind erlaubt, #exec cmd + und #exec cgi sind jedoch deaktiviert. Es ist aber noch + möglich, CGI-Skripte aus + ScriptAlias-Verzeichnissen mittels + #include virtual einzubinden.
Indexes: Wenn eine URL, die auf ein Verzeichnis zeigt, in dem sich keine durch + DirectoryIndex definierte Indexdatei + (z.B. index.html) befindet, dann liefert der Server + eine formatierte Auflistung des Verzeichnisses zurück.
MultiViews: "MultiViews" sind erlaubt (siehe Content-Negotiation).
SymLinksIfOwnerMatch: Der Server folgt nur symbolischen Links, bei denen die Zieldatei + bzw. das Zielverzeichnis der gleichen Benutzerkennung gehört, wie + der Link.
+ Achtung: diese Option wird innerhalb eines + <Location>-Abschnitts + ignoriert.

+ +

Wenn mehrere Options auf ein Verzeichnis + angewandt werden, dann greift normalerweise die + spezifischste Option (Anm.d.Ü.: Gemeint ist die zuletzt + ausgeführte Option.). Wenn jedoch allen Optionen + der Options-Anweisung eines der Zeichen + + oder - vorangestellt wird, werden die Optionen + zusammengemischt. Jede Option mit vorangestelltem + wird + zu den momentan gültigen Optionen hinzugefügt und jede Option + mit vorangestelltem - wird aus den derzeit gültigen + Optionen entfernt.

+ +

So wird zum Beispiel ohne die Zeichen + und + -

+ +

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

+ +

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

+ +

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

+ +

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

+ +

Anmerkung

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

+ +

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

+ +

Require-Direktive

+ + + + + + + +

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

Die Direktive wählt aus, welche authentisierten Benutzer auf ein + Verzeichnis zugreifen dürfen. Folgende Syntax ist erlaubt:

+ +

Require user User-ID [User-ID] + ...: Nur die genannten Benutzer dürfen auf die Ressource + zugreifen.
Require group Gruppenname [Gruppenname] + ...: Nur Benutzer der genannten Gruppen dürfen auf die + Ressource zugreifen.
Require valid-user: Alle gültigen Benutzer dürfen auf die Ressource + zugreifen.

+ +

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

+ +

+ AuthType Basic + AuthName "geschütztes Verzeichnis" + AuthUserFile /web/users + AuthGroupFile /web/groups + Require group admin +

+ +

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

+ +

Siehe auch

Satisfy
mod_authz_host

RLimitCPU-Direktive

+ + + + + + + + +

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

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

+ +

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

+ +

CPU-Ressourcenbegrenzung wird in Sekunden pro Prozess + ausgedrückt.

+ +

Siehe auch

RLimitMEM
RLimitNPROC

RLimitMEM-Direktive

+ + + + + + + + +

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

+ +

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

+ +

Siehe auch

RLimitCPU
RLimitNPROC

RLimitNPROC-Direktive

+ + + + + + + + +

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

+ +

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

+ +

Prozessbegrenzungen steuern die Anzahl der Prozesse pro Benutzer.

+ +

Anmerkung

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

+ +

Siehe auch

RLimitMEM
RLimitCPU

Satisfy-Direktive

+ + + + + + + + +

Beschreibung:	Zusammenspiel von rechnerbasierter Zugriffskontrolle und +Benutzerauthentisierung
Syntax:	`Satisfy Any\|All`
Voreinstellung:	`Satisfy All`
Kontext:	Verzeichnis, .htaccess
AllowOverride:	AuthConfig
Status:	Core
Modul:	core

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

+ +

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

+ +

+ Require valid-user + Allow from 192.168.1 + Satisfy Any +

+ +

Siehe auch

Allow
Require

ScriptInterpreterSource-Direktive

+ + + + + + + + + +

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

Die Direktive wird dazu verwendet, zu steuern, wie der Apache + den Interpreter zur Ausführung von CGI-Skripten findet. Die + voreingestellte Methode ist, den Interpreter zu verwenden, auf den + die #!-Zeile im Skript zeigt.

+ +

Die Einstellung ScriptInterpreterSource Registry + veranlaßt eine Suche in der Windows-Registrierungsdatenbank und + verwendet die Endung der Skript-Datei (z.B. .pl) als + Suchargument.

+ +

Die Option Registry-Strict, die neu im Apache 2.0 + ist, macht das gleiche wie Registry, führt jedoch eine + strengere Suche in der Registrierungsdatenbank durch.

+ +

ServerAdmin-Direktive

+ + + + + + +

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

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

+ +

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

+ +

+ ServerAdmin www-admin@foo.example.com +

+ +

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

+ +

ServerAlias-Direktive

+ + + + + + +

Beschreibung:	Alternativer Name für einen Host, der verwendet wird, wenn +Anfragen einem namensbasierten Virtual-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 Virtual-Hosts.

+ +

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

+ +

Siehe auch

Virtual-Host-Dokumentation des +Apache

ServerName-Direktive

+ + + + + + + +

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

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

+ +

+ ServerName www.example.com:80 +

+ +

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

+ +

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

+ +

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

+ +

Siehe auch

ServerPath-Direktive

+ + + + + + +

Beschreibung:	Veralteter URL-Pfad für einen namensbasierten +Virtual-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 Virtual-Hosts fest.

+ +

Siehe auch

Virtual-Host-Dokumentation des +Apache

ServerRoot-Direktive

+ + + + + + + +

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

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

+ +

Beispiel

+ ServerRoot /home/httpd +

+ +

Siehe auch

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

ServerSignature-Direktive

+ + + + + + + + +

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

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

+ +

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

+ +

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

+ +

Siehe auch

ServerTokens

ServerTokens-Direktive

+ + + + + + + +

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

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

+ +

ServerTokens Prod[uctOnly]: Der Server sendet (z.B.): Server: + Apache
ServerTokens Major: Der Server sendet (z.B.): Server: + Apache/2
ServerTokens Minor: Der Server sendet (z.B.): Server: + Apache/2.0
ServerTokens Min[imal]: Der Server sendet (z.B.): Server: + Apache/2.0.41
ServerTokens OS: Der Server sendet (z.B.): Server: Apache/2.0.41 + (Unix)
ServerTokens Full (oder nicht angegeben): Der Server sendet (z.B.): Server: Apache/2.0.41 + (Unix) PHP/4.2.2 MyMod/1.2

+ +

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

+ +

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

+ +

Siehe auch

ServerSignature

SetHandler-Direktive

+ + + + + + + + +

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

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

+ +

+ SetHandler imap-file +

+ +

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

+ +

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

+ +

Siehe auch

AddHandler

SetInputFilter-Direktive

+ + + + + + + +

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

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

+ +

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

+ +

Siehe auch

Filter-Dokumentation

SetOutputFilter-Direktive

+ + + + + + + +

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

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

+ +

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

+ +

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

+ +

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

+ +

Siehe auch

Filter-Dokumentation

TimeOut-Direktive

+ + + + + + + +

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

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

+ +

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

+ +

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

+ +

UseCanonicalName-Direktive

+ + + + + + + +

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

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

+ +

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

+ +

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

+ +

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

+ +

Warnung

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

+ +

Siehe auch

ServerName
Listen

<VirtualHost>-Direktive

+ + + + + + +

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

<VirtualHost> und + </VirtualHost> werden dazu verwendet, eine Gruppe + von Direktiven zusammenzufassen, die nur auf einen bestimmten Virtual-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 Virtual-Hosts + empfängt, dann benutzt er die im + <VirtualHost>-Container enthaltenen + Konfigurationsanweisungen. Adresse kann sein:

+ +

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

+ +

Beispiel

+ <VirtualHost 10.1.2.3> + + ServerAdmin webmaster@host.foo.com + DocumentRoot /www/docs/host.foo.com + ServerName host.foo.com + ErrorLog logs/host.foo.com-error_log + TransferLog logs/host.foo.com-access_log + + </VirtualHost> +

+ +

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

+ +

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

+ +

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

+ +

Anmerkung

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

+ +

Bei der Verwendung IP-basierter Virtual-Hosts kann der spezielle + Name _default_ benutzt werden. In diesem Fall weist + der Apache jede IP-Adresse diesem Virtual-Host zu, die nicht explizit in + einem anderen Virtual-Host angegeben ist. Falls kein Virtual-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 _default_-Virtual-Host verwendet. + Lesen Sie für weitere Details die Dokumentation zu namensbasierten Virtual-Hosts.)

+ +

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

+ +

Sicherheit

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

+ +

Siehe auch

Virtual-Host-Dokumentation des + Apache
Probleme bezüglich DNS und + Apache
Bestimmen, welche Adressen und Ports + der Apache verwendet
Wie die Abschnitte <Directory>, + <Location> und <Files> arbeiten für eine + Erläuterung, wie diese verschiedenen Abschnitte miteinander + kombiniert werden, wenn eine Anfrage empfangen wird

Apache-Kernfunktionen

Direktiven

AcceptPathInfo-Direktive

AccessFileName-Direktive

Siehe auch

AddDefaultCharset-Direktive

AddOutputFilterByType-Direktive

Hinweis:

Siehe auch

AllowOverride-Direktive

Nun in <Directory>-Abschnitten verfügbar

Siehe auch

AuthName-Direktive

Siehe auch

AuthType-Direktive

Siehe auch

CGIMapExtension-Direktive

ContentDigest-Direktive

DefaultType-Direktive

<Directory>-Direktive

Siehe auch

<DirectoryMatch>-Direktive

Siehe auch

DocumentRoot-Direktive

Siehe auch

EnableMMAP-Direktive

EnableSendfile-Direktive

ErrorDocument-Direktive

Siehe auch

ErrorLog-Direktive

Beispiel

Beispiel

Beispiel

Siehe auch

FileETag-Direktive

<Files>-Direktive

Siehe auch

<FilesMatch>-Direktive

Siehe auch

ForceType-Direktive

HostnameLookups-Direktive

IdentityCheck-Direktive

<IfDefine>-Direktive

<IfModule>-Direktive

Include-Direktive

Siehe auch

KeepAlive-Direktive

Siehe auch

KeepAliveTimeout-Direktive

<Limit>-Direktive

<LimitExcept>-Direktive

LimitRequestBody-Direktive

LimitRequestFields-Direktive

LimitRequestFieldSize-Direktive

LimitRequestLine-Direktive

LimitXMLRequestBody-Direktive

<Location>-Direktive

Anmerkung zu / (Schrägstrich, Slash)

Siehe auch

<LocationMatch>-Direktive

Siehe auch

LogLevel-Direktive

MaxKeepAliveRequests-Direktive

NameVirtualHost-Direktive

Anmerkung

Argument der Direktive <VirtualHost>

Siehe auch

Options-Direktive

Anmerkung

Require-Direktive

Siehe auch

RLimitCPU-Direktive

Siehe auch

RLimitMEM-Direktive

Siehe auch

RLimitNPROC-Direktive

Anmerkung

Siehe auch

Satisfy-Direktive

Siehe auch

Argument der Direktive `<VirtualHost>`