core.xml.de revision f4cbda69df0490c6deaacb8d04f103d200ddd183
<?xml version="1.0"?>
<!-- English Revision: 344972:1555569 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<modulesynopsis metafile="core.xml.meta">
<name>core</name>
<description>Ständig verfügbare Kernfunktionen des Apache HTTP
Servers</description>
<status>Core</status>
<directivesynopsis>
<name>AcceptFilter</name>
<description>Konfiguriert Optimierungen für lauschende Sockets bestimmter
Protokolle</description>
<syntax>AcceptFilter <var>Protokoll</var> <var>Filter</var></syntax>
<contextlist><context>server config</context></contextlist>
<compatibility>Verfügbar ab Apache 2.1.5</compatibility>
<usage>
<p>Diese Direktive aktiviert betriebssystemspezifische Optimierungen
für lauschende Sockets anhand des Protokolltyps. Der grundlegende
Ansatz ist, dass der Kernel das Socket nicht an den Serverprozess
übergibt, bis entweder Daten verfügbar sind oder eine komplette
HTTP-Anfrage zwischengespeichert wurde. Derzeit werden
ausschließlich die <a
>Accept-Filter von FreeBSD</a> und das primitivere
<code>TCP_DEFER_ACCEPT</code> von Linux unterstützt.</p>
<p>Die Standardeinstellungen für FreeBSD sind:</p>
<example>
AcceptFilter http httpready<br />
AcceptFilter https dataready
</example>
<p>Der <code>httpready</code>-Accept-Filter puffert komplette
HTTP-Anfragen auf Kernelebene. Sobald eine Anfrage vollständig
vorliegt, schickt der Kernel sie an den Server weiter. Bitte schlagen Sie
in der <a
>accf_http(9)</a>-Manpage für weitere Details nach. HTTPS-Anfragen
sind verschlüsselt. Daher wird dafür nur der <a
>accf_data(9)</a>-Filter verwendet.</p>
<p>Die Standardeinstellungen für Linux sind:</p>
<example>
AcceptFilter http data<br />
AcceptFilter https data
</example>
<p><code>TCP_DEFER_ACCEPT</code> unter Linux unterstützt keine
Zwischenspeicherung von HTTP-Anfragen. Jeder andere Wert als
<code>none</code> aktiviert <code>TCP_DEFER_ACCEPT</code> auf dem
Lauschsocket. Mehr Details finden Sie in der <a
>tcp(7)</a>-Manpage von Linux.</p>
<p>Wenn Sie <code>none</code> als Argument verwenden, werden alle
Accept-Filter für das Protokoll abgeschaltet. Das ist sinnvoll
für Protokolle, bei denen der Server zuerst Daten senden muss,
wie zum Beispiel <code>nntp</code>:</p>
<example>AcceptFilter nttp none</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>AcceptPathInfo</name>
<description>Ressourcen lassen angehängte Pfadangaben zu</description>
<syntax>AcceptPathInfo On|Off|Default</syntax>
<default>AcceptPathInfo Default</default>
<contextlist><context>server config</context>
<context>virtual host</context><context>directory</context>
<context>.htaccess</context></contextlist>
<override>FileInfo</override>
<compatibility>Verfügbar ab Apache 2.0.30</compatibility>
<usage>
<p>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 <code>PATH_INFO</code>
verfügbar gemacht werden.</p>
<p>Nehmen wir beispielsweise an, dass <code>/test/</code> auf ein
enthält. Dann wird bei Anfragen nach
als <code>PATH_INFO</code> ermittelt.</p>
<p>Die drei möglichen Argumente für die Direktive
<directive>AcceptPathInfo</directive> sind:</p>
<dl>
<dt><code>Off</code></dt><dd>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
404 NOT FOUND <transnote>nicht gefunden</transnote>
zurückgeben.</dd>
<dt><code>On</code></dt>
<dd>Eine Anfrage wird akzeptiert, wenn eine vorangestellte Pfadangabe
auf ein existierendes Verzeichnis abgebildet werden kann. Das
zeigt.</dd>
<dt><code>Default</code></dt>
<dd>Die Behandlung von Anfragen mit angehängten Pfadangaben
wird von dem für die Anfrage verantwortlichen <a
href="/handler.html">Handler</a> bestimmt. Der Core-Handler
für gewöhnliche Dateien weist <code>PATH_INFO</code>-Zugriffe
standardmäßig zurück. Handler, die Skripte bedienen,
voreingestellt, <code>PATH_INFO</code> zu akzeptieren.</dd>
</dl>
<p>Das eigentliche Ziel von <code>AcceptPathInfo</code> ist es, Ihnen
das Überschreiben der Voreinstellung der Handler bezüglich
der Akzeptanz oder Ablehnung von <code>PATH_INFO</code> zu erlauben.
Eine solche Änderung ist zum Beispiel notwendig, wenn Sie einen
href="mod_include.html">INCLUDES</a> verwenden, um Inhalte
abhängig von <code>PATH_INFO</code> zu generieren. Der
Core-Handler würde die Anfrage normalerweise abweisen. Verwenden
Sie die folgende Konfiguration, um dennoch solch ein Skript zu
ermöglichen.</p>
<example>
<Files "mypaths.shtml"><br />
<indent>
Options +Includes<br />
SetOutputFilter INCLUDES<br />
AcceptPathInfo On<br />
</indent>
</Files>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>AccessFileName</name>
<description>Name der dezentralen Konfigurationsdateien</description>
<syntax>AccessFileName <var>Dateiname</var> [<var>Dateiname</var>] ...</syntax>
<default>AccessFileName .htaccess</default>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p>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 <a href="#allowoverride">erlaubt sind</a>.
Beispiel:</p>
<example>
AccessFileName .acl
</example>
<p>Vor der Rücksendung des Dokuments
einlesen, solange diese nicht mit</p>
<example>
<Directory /><br />
<indent>
AllowOverride None<br />
</indent>
</Directory>
</example>
<p>deaktiviert wurden.</p>
</usage>
<seealso><directive module="core">AllowOverride</directive></seealso>
</directivesynopsis>
<directivesynopsis>
<name>AddDefaultCharset</name>
<description>Standard-Charset-Parameter, der bei Antworten vom Content-Type
</description>
<syntax>AddDefaultCharset On|Off|<var>Zeichenkodierung</var></syntax>
<default>AddDefaultCharset Off</default>
<contextlist><context>server config</context>
<context>virtual host</context><context>directory</context>
<context>.htaccess</context></contextlist>
<override>FileInfo</override>
<usage>
<p>Die Direktive gibt einen Standardwert für den Charset-Paramter des
Medientyps (den Namen einer Zeichencodierung) an, der einer Antwort
genau dann hinzugefügt wird, wenn der Content-Type der Antwort entweder
mittels <code>META</code>-Element im Datenteil der Antwort angegebene
Charset überschreiben. Das genaue Verhalten hängt jedoch oft von
der Client-Konfiguration des Benutzers ab. Die Einstellung
<code>AddDefaultCharset Off</code> deaktiviert diese Funktionalität.
<code>AddDefaultCharset On</code> aktiviert die Standard-Zeichenkodierung
<code>iso-8859-1</code>. Jeder andere Wert wird als die zu verwendende
<var>Zeichenkodierung</var> aufgefaßt, die eines der bei <a
href="http://www.iana.org/assignments/character-sets">IANA registrierten
Charset-Werte</a> zur Verwendung in MIME-Medientypen sein sollte. Zum
Beispiel:</p>
<example>
AddDefaultCharset utf-8
</example>
<p><directive>AddDefaultCharset</directive> sollte nur verwendet werden,
wenn von allen Textressourcen, für die es gilt, bekannt ist, dass sie
in dieser Zeichkodierung vorliegen, oder wenn es zu unbequem ist, ihre
Zeichenkodierung indivuell zu benennen. Ein solches Beispiel ist das
Hinzufügen des Charset-Parameters zu Ressourcen, die generierte
Inhalte enthalten. Ein Beispiel sind CGI-Skript-Altlasten, die aufgrund von
in die Ausgabe integrierten Daten, die durch den Benutzer übermittelt
wurden, gegen Cross-Site-Scripting-Angriffe verwundbar sind. Eine bessere
Lösung wäre jedoch, diese Skripte zu korrigieren (oder zu
löschen), da die Angabe einer Standard-Zeichencodierung keine
Anwender schützt, die in ihrem Browser die Funktion zur
automatischen Erkennung der Zeichenkodierung aktiviert haben.</p>
</usage>
<seealso><directive module="mod_mime">AddCharset</directive></seealso>
</directivesynopsis>
<directivesynopsis>
<name>AddOutputFilterByType</name>
<description>einen Ausgabefilter einem bestimmten MIME-Type
zuordnen</description>
<syntax>AddOutputFilterByType <var>Filter</var>[;<var>Filter</var>...]
<var>MIME-Type</var> [<var>MIME-Type</var>] ...</syntax>
<contextlist><context>server config</context>
<context>virtual host</context><context>directory</context>
<context>.htaccess</context></contextlist>
<override>FileInfo</override>
<compatibility>Verfügbar ab Apache 2.0.33</compatibility>
<usage>
<p>Die Direktive aktiviert für eine Anfrage abhängig vom
<glossary>MIME-Type</glossary> der Antwort einen bestimmten
<p>Das folgende Beispiel verwendet den Filter <code>DEFLATE</code>,
der von <module>mod_deflate</module> angeboten wird. Er komprimiert
gekennzeichnet ist, (gleichgültig, ob statisch oder dynamisch)
bevor sie an den Client gesendet wird.</p>
<example>
</example>
<p>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
<directive>AddOutputFilterByType</directive>-Direktive für
jeden von diesen Filtern zu verwenden.</p>
<p>Die folgende Konfiguration sorgt dafür, dass alle
sind, zuerst vom <code>INCLUDES</code>-Filter und dann vom
<code>DEFLATE</code>-Filter verarbeitet werden.</p>
<example>
<Location /cgi-bin/><br />
<indent>
Options Includes<br />
</indent>
</Location>
</example>
<note type="warning"><title>Hinweis:</title>
<p>Die Aktivierung von Filtern mittels
<directive>AddOutputFilterByType</directive> kann in einigen
Fällen ganz oder teilweise fehlschlagen. Beispielsweise
werden keine Filter angewendet, wenn der <glossary>MIME-Type</glossary>
nicht bestimmt werden kann und auf die Einstellung der <directive
module="core">DefaultType</directive>-Anweisung zurückfällt,
selbst wenn die <directive
module="core">DefaultType</directive>-Einstellung die gleiche ist.</p>
<p>Wenn Sie jedoch sicherstellen wollen, dass der Filter
angewendet wird, sollten Sie den Content-Type z.B. mit
<directive module="mod_mime">AddType</directive> oder
<directive module="core">ForceType</directive> der Ressource
explizit zuordnen. Das Setzen des Content-Types innerhalb
eines (nicht-nph) CGI-Skriptes funktioniert ebenfalls
zuverlässig.</p>
<p>Die Typ-gebundenen Ausgabefilter werden niemals auf
Proxy-Anfragen angewendet.</p>
</note>
</usage>
<seealso><directive module="mod_mime">AddOutputFilter</directive></seealso>
<seealso><directive module="core">SetOutputFilter</directive></seealso>
</directivesynopsis>
<directivesynopsis>
<name>AllowEncodedSlashes</name>
<description>Legt fest, ob kodierte Pfadtrennzeichen in URLs durchgereicht
werden dürfen</description>
<syntax>AllowEncodedSlashes On|Off</syntax>
<default>AllowEncodedSlashes Off</default>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<compatibility>Verfügbar ab Apache 2.0.46</compatibility>
<usage>
<p>Die <directive>AllowEncodedSlashes</directive>-Direktive erlaubt die
Verwendung von URLs, welche kodierte Pfadtrennzeichen (<code>%2F</code>
für <code>/</code> und auf entsprechenden Systemen zusätzlich
<code>%5C</code> für <code>\</code>) enthalten. Normalerweise werden
derartige URLs mit einem 404-Fehler (Nicht gefunden) abgewiesen.</p>
<p><directive>AllowEncodedSlashes</directive> <code>On</code> ist
vor allem in Verbindung mit <code>PATH_INFO</code> hilfreich.</p>
<note><title>Anmerkung</title>
<p>Das Erlauben von Schrägstrichen impliziert <em>nicht</em> deren
<em>Dekodierung</em>. Vorkommen von <code>%2F</code> oder <code>%5C</code>
(<em>nur</em> auf entsprechenden Systemen) werden unverändert in der
ansonsten dekodierten URL belassen.</p>
</note>
</usage>
<seealso><directive module="core">AcceptPathInfo</directive></seealso>
</directivesynopsis>
<directivesynopsis>
<name>AllowOverride</name>
<description>Direktiven-Typen, die in <code>.htaccess</code>-Dateien
erlaubt sind.</description>
<syntax>AllowOverride All|None|<var>Direktiven-Typ</var>
[<var>Direktiven-Typ</var>] ...</syntax>
<default>AllowOverride None (2.3.9 und später), AllowOverride All (2.3.8 und früher)</default>
<contextlist><context>directory</context></contextlist>
<usage>
<p>Wenn der Server eine <code>.htaccess</code>-Datei (wie durch
<directive module="core">AccessFileName</directive> definiert)
findet, muss er wissen, welche in der Datei angegebenen Direktiven
frühere Konfigurationsanweisungen überschreiben
dürfen.</p>
<note><title>Nur in <Directory>-Abschnitten verfügbar</title>
<directive>AllowOverride</directive> ist nur in <directive
type="section" module="core">Directory</directive>-Abschnitten
gültig, die ohne reguläre Ausdrücke definiert wurden, nicht
in <directive type="section" module="core">Location</directive>-,
<directive module="core" type="section">DirectoryMatch</directive>- oder
<directive type="section" module="core">Files</directive>-Abschnitten.
</note>
<p>Wenn diese Anweisung auf <code>None</code> gesetzt wird, dann
werden <a href="#accessfilename">.htaccess</a>-Dateien komplett
ignoriert. In diesem Fall wird der Server nicht einmal versuchen,
die <code>.htaccess</code>-Dateien im Dateisystem zu lesen.</p>
<p>Wenn diese Anweisung auf <code>All</code> gesetzt wird, dann
ist jede Direktive in den <code>.htaccess</code>-Dateien erlaubt,
.htaccess besitzt.</p>
<p>Der <var>Direktiven-Typ</var> kann eine der folgenden
Anweisungsgruppen sein.</p>
<dl>
<dt>AuthConfig</dt>
<dd>
Erlaubt die Verwendung von Autorisierungs-Anweisungen (<directive
module="mod_authz_dbm">AuthDBMGroupFile</directive>,
<directive module="mod_authn_dbm">AuthDBMUserFile</directive>,
<directive module="mod_authz_groupfile">AuthGroupFile</directive>,
<directive module="mod_authn_core">AuthName</directive>,
<directive module="mod_authn_core">AuthType</directive>, <directive
module="mod_authn_file">AuthUserFile</directive>, <directive
module="mod_authz_core">Require</directive> <em>usw.</em>).</dd>
<dt>FileInfo</dt>
<dd>
Erlaubt die Verwendung von Direktiven zur Steuerung der
Dokumenttypen (<directive
module="core">DefaultType</directive>, <directive
module="core">ErrorDocument</directive>, <directive
module="core">ForceType</directive>, <directive
module="mod_negotiation">LanguagePriority</directive>,
<directive module="core">SetHandler</directive>, <directive
module="core">SetInputFilter</directive>, <directive
module="core">SetOutputFilter</directive>, und
<module>mod_mime</module>-Direktiven Add* und Remove*
<em>usw.</em>), Metadaten (<directive
module="mod_headers">Header</directive>, <directive
module="mod_headers">RequestHeader</directive>, <directive
module="mod_setenvif">SetEnvIf</directive>, <directive
module="mod_setenvif">SetEnvIfNoCase</directive>, <directive
module="mod_setenvif">BrowserMatch</directive>, <directive
module="mod_usertrack">CookieExpires</directive>, <directive
module="mod_usertrack">CookieDomain</directive>, <directive
module="mod_usertrack">CookieStyle</directive>, <directive
module="mod_usertrack">CookieTracking</directive>, <directive
module="mod_usertrack">CookieName</directive>),
<module>mod_rewrite</module>-Direktiven <directive
module="mod_rewrite">RewriteEngine</directive>, <directive
module="mod_rewrite">RewriteOptions</directive>, <directive
module="mod_rewrite">RewriteBase</directive>, <directive
module="mod_rewrite">RewriteCond</directive>, <directive
module="mod_rewrite">RewriteRule</directive>) und
<directive module="mod_actions">Action</directive> aus
<module>mod_actions</module>.
</dd>
<dt>Indexes</dt>
<dd>
Erlaubt die Verwendung von Direktiven zur Steuerung von
Verzeichnisindizes (<directive
module="mod_autoindex">AddDescription</directive>,
<directive module="mod_autoindex">AddIcon</directive>, <directive
module="mod_autoindex">AddIconByEncoding</directive>,
<directive module="mod_autoindex">AddIconByType</directive>,
<directive module="mod_autoindex">DefaultIcon</directive>, <directive
module="mod_dir">DirectoryIndex</directive>, <a
<code>FancyIndexing</code></a>, <directive
module="mod_autoindex">HeaderName</directive>, <directive
module="mod_autoindex">IndexIgnore</directive>, <directive
module="mod_autoindex">IndexOptions</directive>, <directive
module="mod_autoindex">ReadmeName</directive>
<em>usw.</em>).</dd>
<dt>Limit</dt>
<dd>
Erlaubt die Verwendung von Direktiven zur Steuerung des
Zugriffs von Hosts (<directive
module="mod_access_compat">Allow</directive>, <directive
module="mod_access_compat">Deny</directive> und <directive
module="mod_access_compat">Order</directive>).</dd>
<dt>Options[=<var>Option</var>,...]</dt>
<dd>
Erlaubt die Verwendung von Direktiven zur Steuerung spezieller
Verzeichniseigenschaften (<directive module="core">Options</directive>
und <directive module="mod_include">XBitHack</directive>). Sie
können mit einem Gleichheitszeichen gefolgt von einer
kommaseparierten Liste (ohne Leerzeichen) angeben, welche Optionen mit
der <directive module="core">Options</directive>-Direktive gesetzt
werden dürfen.</dd>
</dl>
<p>Beispiel:</p>
<example>
AllowOverride AuthConfig Indexes
</example>
<p>Im obigen Beispiel erzeugen alle Direktiven einen internal server
error <transnote>Server-interner Fehler</transnote>, die weder der
Gruppe <code>AuthConfig</code> noch der Gruppe <code>Indexes</code>
angehören.</p>
</usage>
<seealso><directive module="core">AccessFileName</directive></seealso>
</directivesynopsis>
<directivesynopsis>
<name>AuthName</name>
<description>Autorisierungsbereich zur Verwendung in der
HTTP-Authentisierung</description>
<syntax>AuthName <var>auth-Bereich</var></syntax>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
<usage>
<p>Die Direktive legt den Namen des Autorisierungsbereiches
<transnote>Der Autorisierungsbereich wird auch Realm genannt.</transnote>
für ein Verzeichnis fest. Dieser Realm wird dem Client mitgeteilt,
damit der Anwender weiß, welchen Benutzernamen und welches Passwort
er zu übermitteln hat. <directive>AuthName</directive> 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 <directive
module="core">AuthType</directive> und <directive
module="core">Require</directive> sowie von
Direktiven wie <directive module="mod_authn_file">AuthUserFile</directive>
und <directive module="mod_authz_groupfile">AuthGroupFile</directive>
begleitet werden.</p>
<p>Beispiel:</p>
<example>
AuthName "Top Secret"
</example>
<p>Die <code>AuthName</code> übergebene Zeichenkette ist das,
was in dem von den meisten Browsern angebotenen Passwort-Dialog
angezeigt wird.</p>
</usage>
<seealso><a
Zugriffskontrolle</a></seealso>
</directivesynopsis>
<directivesynopsis>
<name>AuthType</name>
<description>Art der Authentisierung</description>
<syntax>AuthType Basic|Digest</syntax>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
<usage>
<p>Die Direktive wählt die Art der Benutzer-Authentisierung
für ein Verzeichnis aus. Derzeit sind lediglich <code>Basic</code>
und <code>Digest</code> implementiert.
Um zu funktionieren, muss die Anweisung von den Direktiven <directive
module="core">AuthName</directive> und <directive
module="core">Require</directive> sowie von
Direktiven wie <directive module="mod_authn_file">AuthUserFile</directive>
und <directive module="mod_authz_groupfile">AuthGroupFile</directive>
begleitet werden.</p>
</usage>
Zugriffskontrolle</a></seealso>
</directivesynopsis>
<directivesynopsis>
<name>CGIMapExtension</name>
<description>Technik zur Bestimmung des Interpreters für
CGI-Skripte</description>
<syntax>CGIMapExtension <var>CGI-Pfad</var> <var>.Endung</var></syntax>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>FileInfo</override>
<compatibility>ausschließlich NetWare</compatibility>
<usage>
<p>Die Direktive wird zur Steuerung verwendet, wie Apache
den Interpreter ermittelt, der zur Ausführung von
CGI-Skripten verwendet wird. Beispielsweise bestimmt die Angabe
alle CGI-Scripte mit der Endung <code>.foo</code> an den
FOO-Interpreter übergeben werden.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ContentDigest</name>
<description>Aktiviert die Generierung von <code>Content-MD5</code>
HTTP-Response-Headern</description>
<syntax>ContentDigest On|Off</syntax>
<default>ContentDigest Off</default>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>Options</override>
<status>Experimental</status>
<usage>
<p>Die Direktive aktiviert die Generierung von
<code>Content-MD5</code>-Headern, wie sie in RFC1864 bzw. RFC2616
definiert sind.</p>
<p>MD5 ist ein Algorithmus zur Berechnung eines "Datenextrakts"
(zuweilen "Fingerabdruck" genannt) <transnote>Der "Datenextrakt" wird im
Englischen als "message digest" oder "fingerprint" bezeichnet.</transnote>
aus beliebig langen Daten. Es gilt als zuverlässig, dass
Veränderungen an den Daten sich in Veränderungen des
Extrakts wiederspiegeln.</p>
<p>Der <code>Content-MD5</code>-Header bietet eine
End-to-End-Integritätsprüfung (MIC) <transnote>MIC steht für
"message integrity check".</transnote> 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:</p>
<example>
Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==
</example>
<p>Beachten Sie bitte, dass dies Performanceprobleme auf Ihrem
System verursachen kann, da der Extrakt bei jeder Anfrage
berechnet wird (der Wert wird nicht zwischengespeichert).</p>
<p><code>Content-MD5</code> wird nur für Dokumente gesendet,
die von <module>core</module> bedient werden, nicht jedoch bei
Modulen. SSI-Dokumente, CGI-Skript-Ausgaben und Byte-Range-Antworten
besitzen diesen Header beispielsweise nicht.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>DefaultType</name>
<description>MIME-Content-Type, der gesendet wird, wenn der Server den Typ
nicht auf andere Weise ermitteln kann.</description>
<syntax>DefaultType <var>MIME-Type</var></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>FileInfo</override>
<usage>
<p>Es kann vorkommen, dass der Server ein Dokument ausliefern muss,
dessen Typ er nicht mit Hilfe seiner <glossary ref="mime-type"
>MIME-Type</glossary>-Zuordnungen bestimmen kann.</p>
<p>Der Server muss den Client über den Content-Type des
Dokumentes informieren. Daher verwendet er im Falle eines
unbekannten Typs die <code>DefaultType</code>-Einstellung.
Zum Beispiel:</p>
<example>
</example>
<p>wäre angemessen für ein Verzeichnis, das viele GIF-Bilder
enthält, deren Dateinamen nicht Endung <code>.gif</code>
besitzen.</p>
<p>Beachten Sie bitte, dass die Direktive anders als <directive
module="core">ForceType</directive> lediglich den Standard-MIME-Type
bestimmt. Alle anderen MIME-Type-Definitionen, einschließlich
Dateierweiterungen, die den Medien-Typ anzeigen können,
überschreiben diese Voreinstellung.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>Define</name>
<description>Define the existence of a variable</description>
<syntax>Define <var>Parametername</var></syntax>
<contextlist><context>server config</context></contextlist>
<usage>
<p>Equivalent zum übergeben von <var>Parametername</var> mittels des
<code>-D</code> Arguments an <program>httpd</program>.</p>
<p>Diese Directive kann verwendet werden, um die Nutzung von <directive module="core"
type="section">IfDefine</directive> Sectionen umzuschalten, ohne die
<code>-D</code> Argumentente in etwaigen Start-Skripten ändern
zu müssen.</p>
</usage>
</directivesynopsis>
<directivesynopsis type="section">
<name>Directory</name>
<description>Umschließt eine Gruppe von Direktiven, die nur auf
das genannte Verzeichnis des Dateisystems und Unterverzeichnisse angewendet
werden</description>
<syntax><Directory <var>Verzeichnispfad</var>>
... </Directory></syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p><directive type="section">Directory</directive> und
<code></Directory></code> 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.
<var>Verzeichnispfad</var> 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 <transnote>sogenannte wild-cards</transnote> entspricht
<code>?</code> einem einzelnen Zeichen und <code>*</code> einer
Zeichenkette beliebiger Länge. Sie können auch auch
<code>[]</code>-Zeichenbereiche verwenden. Keiner der Platzhalter
entspricht dem Zeichen "/". Daher passt <code><Directory
<code><Directory /home/*/public_html></code> jedoch tut es.
Beispiel:</p>
<example>
<indent>
Options Indexes FollowSymLinks<br />
</indent>
</Directory>
</example>
<note>
<p>Seien Sie vorsichtig mit den <var>Verzeichnispfad</var>-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.</p>
</note>
<p>Erweiterte <glossary ref="regex"
>reguläre Ausdrücke</glossary> können ebenfalls
verwendet werden, indem das Zeichen <code>~</code> hinzugefügt
wird. Beispielsweise würde</p>
<example>
<Directory ~ "^/www/.*/[0-9]{3}">
</example>
<p>auf Verzeichnisse in <code>/www/</code> passen, die aus drei
Zahlen bestehen.</p>
<p>Wenn mehrere <directive type="section">Directory</directive>-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 <a href="#accessfilename">.htaccess</a>-Dateien, angewendet.
Beispiel:</p>
<example>
<Directory /><br />
<indent>
AllowOverride None<br />
</indent>
</Directory><br />
<br />
<Directory /home/><br />
<indent>
AllowOverride FileInfo<br />
</indent>
</Directory>
</example>
sind die einzelnen Schritte:</p>
<ul>
<li>Wende die Direktive <code>AllowOverride None</code> an
(deaktiviere <code>.htaccess</code>-Dateien).</li>
<li>Wende die Direktive <code>AllowOverride FileInfo</code>
(auf das Verzeichnis <code>/home</code>) an.</li>
<li>Wende jede <code>FileInfo</code>-Direktive aus
</ul>
<p>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</p>
<example>
<Directory ~ abc$><br />
<indent>
# ... hier die Direktiven ...<br />
</indent>
</Directory>
</example>
<p>der Abschnitt mit dem regulären Ausdruck nicht
berücksichtigt, bis alle normalen
<directive type="section">Directory</directive>-Abschnitte und
<code>.htaccess</code>-Dateien angewendet wurden. Dann erst wird
abgeglichen und der entsprechende <directive
type="section">Directory</directive>-Abschnitt angewendet.</p>
<p><strong>Beachten Sie bitte, dass der vom Apache voreingestellte
Zugriff für <code><Directory /></code>
<code>Allow from All</code> 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</strong></p>
<example>
<Directory /><br />
<indent>
Order Deny,Allow<br />
Deny from All<br />
</indent>
</Directory>
</example>
<p><strong>ändern und anschließend für
Verzeichnisse überschreiben, die Sie verfügbar machen
<em>wollen</em>. Für weitere Einzelheiten lesen Sie bitte
die Seite zu den <a
<p>Die Verzeichnisabschnitte erscheinen in der Datei
type="section">Directory</directive>-Direktiven dürfen nicht
ineinander verschachtelt werden oder innerhalb von <directive module="core"
type="section">Limit</directive>- oder <directive module="core"
type="section">LimitExcept</directive>-Abschnitten auftauchen.</p>
</usage>
<Location> und <Files> arbeiten</a> für eine
Erläuterung, wie diese verschiedenen Abschnitte miteinander
kombiniert werden, wenn eine Anfrage empfangen wird</seealso>
</directivesynopsis>
<directivesynopsis type="section">
<name>DirectoryMatch</name>
<description>Umschließt eine Gruppe von Direktiven, die auf
Verzeichnisse des Dateisystems und ihre Unterverzeichnisse abgebildet
werden, welche auf einen regulären Ausdruck passen</description>
<syntax><DirectoryMatch <var>regex</var>>
... </DirectoryMatch></syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p><directive type="section">DirectoryMatch</directive> und
<code></DirectoryMatch></code> werden dazu verwendet, eine
Gruppe von Direktiven zusammenzufassen, die nur für das
genannte Verzeichnis und dessen Unterverzeichnisse gelten, genauso
wie bei <directive module="core" type="section">Directory</directive>.
Als Argument dient jedoch ein <glossary ref="regex">regulärer
Ausdruck</glossary>. Beispielsweise würde</p>
<example>
<DirectoryMatch "^/www/.*/[0-9]{3}">
</example>
<p>auf Verzeichnisse in <code>/www/</code> passen, die aus drei
Zeichen bestehen.</p>
</usage>
<seealso><directive type="section" module="core">Directory</directive>
für eine Beschreibung, wie reguläre Ausdrücke mit
normalen <directive type="section">Directory</directive>-Anweisungen
vermischt werden.</seealso>
<Location> und <Files> arbeiten</a> für eine
Erläuterung, wie diese verschiedenen Abschnitte miteinander
kombiniert werden, wenn eine Anfrage empfangen wird</seealso>
</directivesynopsis>
<directivesynopsis>
<name>DocumentRoot</name>
<description>Verzeichnis, welches den Haupt-Dokumentenbaum bildet, der im
Web sichtbar ist.</description>
<syntax>DocumentRoot <var>Verzeichnis</var></syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p>Die Direktive setzt das Verzeichnis, von dem aus
<program>httpd</program> Dateien ausliefert. Sofern nicht eine Direktive
wie <directive module="mod_alias">Alias</directive> greift, hängt
der Server Pfade aus der angeforderten URL an das Wurzelverzeichnis
an, um den Pfad zum Dokument zu bilden. Beispiel:</p>
<example>
</example>
<p>Damit bezieht sich ein Zugriff auf
absolut angegeben ist, wird es relativ zu <directive
module="core">ServerRoot</directive> betrachtet.</p>
<p><directive>DocumentRoot</directive> sollte ohne einen
Schrägstrich am Ende angegeben werden.</p>
</usage>
abbilden</a></seealso>
</directivesynopsis>
<directivesynopsis>
<name>EnableMMAP</name>
<description>Verwende Memory-Mapping, um Dateien während der
Auslieferung zu lesen</description>
<syntax>EnableMMAP On|Off</syntax>
<default>EnableMMAP On</default>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>FileInfo</override>
<usage>
<p>Die Direktive steuert, ob <program>httpd</program> 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 <module>mod_include</module> serverseitig
analysierten Datei --, dann verwendet der Apache standardmäßig
Memory-Mapping für diese Datei, sofern das Betriebssystem es
unterstützt.</p>
<p>Memory-Mapping bedeutet zuweilen eine Performanceverbesserung.
In einigen Umgebungen ist es jedoch besser, Memory-Mapping zu
deaktivieren, um Problemen während des Betriebs vorzubeugen:</p>
<ul>
<li>Bei einigen Multiprozessorsystemen kann Memory-Mapping die
Performance von <program>httpd</program> reduzieren.</li>
<li>Bei einem per NFS eingebundenen <directive
module="core">DocumentRoot</directive> kann <program>httpd</program> mit
einem Speicherzugriffsfehler <transnote>ein so genannter "segmentation
fault"</transnote> abstürzen, wenn eine Datei gelöscht oder
gekürzt wird, während <program>httpd</program> sie im Speicher
abbildet.</li>
</ul>
<p>Bei Serverkonfigurationen, die für dieses Problem
anfällig sind, sollten Sie das Memory-Mapping für
auszuliefernde Dateien deaktivieren, indem Sie schreiben:</p>
<example>
EnableMMAP Off
</example>
<p>Bei per NFS eingebundenen Dateien kann diese Funktion
explizit für die störenden Dateien deaktiviert werden,
indem Sie angeben:</p>
<example>
<Directory "/pfad-zu-den-nfs-dateien">
<indent>
EnableMMAP Off
</indent>
</Directory>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>EnableSendfile</name>
<description>Verwende die sendfile-Unterstützung des Kernels, um
Dateien an den Client auszuliefern</description>
<syntax>EnableSendfile On|Off</syntax>
<default>EnableSendfile On</default>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>FileInfo</override>
<compatibility>Verfügbar ab Apache Version 2.0.44</compatibility>
<usage>
<p>Die Direktive steuert, ob <program>httpd</program> 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.</p>
<p>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:</p>
<ul>
<li>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.</li>
<li>Bei einem über das Netzwerk eingebundenen <directive
Kernel möglicherweise nicht in der Lage, die Netzwerkdatei
über seinen eigenen Cache zu bedienen.</li>
<li>Unter Linux löst die Verwendung von <code>sendfile</code>
in Verbindung mit bestimmten Netzwerkkarten und IPv6
TCP-Checksummenfehler aus.</li>
<li>Unter Linux auf Itanium-Systemen kommt sendfile unter Umständen
nicht mit Dateien größer als 2GB klar.</li>
</ul>
<p>Bei Serverkonfigurationen, die für dieses Problam
anfällig sind, sollten die diese Funktion deaktivieren, indem
Sie schreiben:</p>
<example>
EnableSendfile Off
</example>
<p>Bei per NFS oder SMB eingebundenen Dateien kann diese Funktion
explizit für die störenden Dateien deaktiviert werden, indem
Sie angeben:</p>
<example>
<Directory "/pfad-zu-den-nfs-dateien">
<indent>
EnableSendfile Off
</indent>
</Directory>
</example>
<p>Beachten Sie bitte, dass die verzeichnisbasierte und
.htaccess-Konfiguration von <directive>EnableSendfile</directive>
nicht vom <module>mod_cache_disk</module>-Modul unterstützt wird.
Nur die globale Konfiguration von <directive>EnableSendfile</directive>
wird vom Modul beachtet.
</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ErrorDocument</name>
<description>Das, was der Server im Fehlerfall an den Client
zurückgibt</description>
<syntax>ErrorDocument <var>Fehlercode</var> <var>Dokument</var></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>FileInfo</override>
<compatibility>Die Syntax der Anführungszeichen bei Textnachrichten hat
sich im Apache 2.0 geändert</compatibility>
<usage>
<p>Im Falle eines Problems oder Fehlers kann der Apache
konfiguriert werden, eine der vier Aktionen auszuführen:</p>
<ol>
<li>Ausgabe einer einfachen, hartkodierten Fehlermeldung</li>
<li>Ausgabe einer angepassten Meldung</li>
<li>Umleitung zu einem lokalen <var>URL-Pfad</var> der das
Problem bzw. den Fehler behandelt</li>
<li>Umleitung zu einer externen <var>URL</var>, die das Problem
bzw. den Fehler behandelt</li>
</ol>
<p>Die erste Option ist Voreinstellung, während die Optionen
2 bis 4 über die Direktive <directive>ErrorDocument</directive>
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.</p>
<p>URLs können bei lokalen Webpfaden mit einem Schrägstrich
(/) beginnen (relativ zum <directive module="core"
>DocumentRoot</directive>-Verzeichnis) oder eine vollständige URL
bilden, die der Client auflösen kann. Alternativ kann eine
Nachricht für die Anzeige im Browser angeboten werden. Beispiel:</p>
<example>
ErrorDocument 500 http://foo.example.com/cgi-bin/tester<br />
ErrorDocument 401 /info_zur_anmeldung.html<br />
ErrorDocument 403 "Der Zugriff ist nicht erlaubt."
</example>
<p>Außerdem kann der spezielle Wert <code>default</code> angegeben
werden, um die schlichte, hartkodierte Nachricht des Apache zu verwenden.
Es wird normalerweise nicht benötigt, doch <code>default</code>
stellt die einfach, im Apache hartkodierte Meldung in Konfigurationen
wieder her, die ansonsten von einem existierenden <transnote>zuvor
konfigurierten</transnote> <directive>ErrorDocument</directive> erben
würden.</p>
<example>
<indent>
ErrorDocument 404 default<br />
</indent>
</Directory>
</example>
<p>Wenn Sie eine <directive>ErrorDocument</directive>-Anweisung
angeben, die auf eine entfernte URL weist (d.h. irgendetwas mit der
Methode <code>http</code> 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
<code>ErrorDocument 401</code> 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. <strong>Deshalb müssen Sie sich auf ein lokales
Dokument beziehen, wenn Sie eine Anweisung <code>ErrorDocument
401</code> verwenden.</strong></p>
<p>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 <a
>Q294807</a> in der Microsoft Knowledgebase verfügbar.</p>
<p>Obwohl die meisten Fehlermeldungen überschrieben werden
können, werden unter bestimmten Umständen die internen
Meldungen ungeachtet der Einstellung der <directive module="core"
>ErrorDocument</directive>-Direktive verwendet. Insbesondere bei
einer fehlerhaften Anfrage werden der normale Bearbeitungsprozess sofort
beendet und die interne Meldung zurückgegeben. Das ist notwendig, um
Sicherheitsprobleme zu vermeiden, die auf Grund fehlerhafter Anfragen
entstehen.</p>
<p>In Versionen vor 2.0 wurden Meldungen durch ein einzelnes
vorangestelltes Anführungszeichen (") erkannt.</p>
</usage>
Fehlermeldungen</a></seealso>
</directivesynopsis>
<directivesynopsis>
<name>ErrorLog</name>
<description>Ablageort, an dem der Server Fehler protokolliert</description>
<syntax> ErrorLog <var>Dateiname</var>|syslog[:<var>facility</var>]</syntax>
OS/2)</default>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p>Die Direktive <directive>ErrorLog</directive> bestimmt den Namen
der Datei, in welcher der Server alle auftretenden Fehler protokolliert.
Wenn <var>Dateiname</var> nicht absolut ist, wird er relativ zu <directive
module="core">ServerRoot</directive> betrachtet.</p>
<example><title>Beispiel</title>
</example>
<p>Wenn der <var>Dateiname</var> 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.</p>
<example><title>Beispiel</title>
</example>
<p>Die Verwendung von <code>syslog</code> anstelle eines Dateinamens
aktiviert die Protokollierung mittels syslogd(8), sofern das System
es unterstützt. Als Voreinstellung wird der syslog-Typ (syslog
facility) <code>local7</code> verwendet, Sie können dies jedoch
auch überschreiben, indem Sie die Syntax
<code>syslog:<var>facility</var></code> verwenden, wobei
<var>facility</var> einer der Namen sein kann, die üblicherweise
in syslog(1) dokumentiert sind.</p>
<example><title>Beispiel</title>
ErrorLog syslog:user
</example>
<p>SICHERHEITSHINWEIS: Lesen Sie das Dokument <a
href="/misc/security_tips.html#serverroot">Sicherheitshinweise</a>
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.</p>
<note type="warning"><title>Anmerkung</title>
<p>Bei der Eingabe eines Dateipfads auf nicht-Unix-Plattformen sollte
darauf geachtet werden, nur (Vorwärts-)Schrägstriche zu
verwenden, auch wenn die Plattform rückwärts gerichtete
Schrägstriche (Backslashes) erlaubt. Im Allgemeinen ist es eine gute
Idee, innerhalb der Konfigurationsdateien immer
Vorwärts-Schrägstriche zu verwenden.</p>
</note>
</usage>
<seealso><directive module="core">LogLevel</directive></seealso>
</directivesynopsis>
<directivesynopsis>
<name>FileETag</name>
<description>Dateiattribute, die zur Erstellung des HTTP-Response-Headers
ETag verwendet werden</description>
<syntax>FileETag <var>Komponente</var> ...</syntax>
<default>FileETag INode MTime Size</default>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>FileInfo</override>
<usage>
<p>Wenn dem Dokument eine Datei zugrundeliegt, bestimmt die Direktive
<directive>FileETag</directive> die Dateiattribute, die zur Erstellung
des HTTP-Response-Headers <code>ETag</code> (Entity-Tag) verwendet
werden. (Der Wert von <code>ETag</code> wird bei der Cache-Verwaltung
zur Einsparung von Netzwerk-Bandbreite benutzt.) Im Apache 1.3.22 und
früher wurde der <code>ETag</code>-Wert <em>stets</em> aus
der I-Node, der Größe und dem Datum der letzten
Änderung (mtime) der Datei gebildet. Die Direktive
<directive>FileETag</directive> erlaubt es Ihnen, zu bestimmen,
welche dieser Eigenschaften -- falls überhaupt -- verwendet
werden sollen. Die gültigen Schlüsselworte lauten:</p>
<dl>
<dt><strong>INode</strong></dt>
<dd>Die I-Node-Nummer wird in die Berechnung mit einbezogen</dd>
<dt><strong>MTime</strong></dt>
<dd>Datum und Uhrzeit der letzten Änderung werden mit einbezogen</dd>
<dt><strong>Size</strong></dt>
<dd>Die Anzahl der Bytes in der Datei wird mit einbezogen</dd>
<dt><strong>All</strong></dt>
<dd>Alle verfügbaren Angaben werden verwendet. Die ist
gleichbedeutend mit:
<example>FileETag INode MTime Size</example></dd>
<dt><strong>None</strong></dt>
<dd>Es wird keine <code>ETag</code>-Angabe in die Antwort eingefügt,
wenn dem Dokument eine Datei zugrundeliegt.</dd>
</dl>
<p>Den Schlüsselwörtern <code>INode</code>, <code>MTime</code>
und <code>Size</code> kann entweder ein <code>+</code> oder ein
<code>-</code> 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.</p>
<p>Wenn die Konfiguration für ein Verzeichnis
<code>FileETag INode MTime Size</code> enthält
und die eines Unterverzeichnisses <code>FileETag -INode</code>,
dann ist die Einstellung für das Unterverzeichnis (die an
jedes Unter-Unterverzeichnis weitervererbt wird, welches dies nicht
überschreibt) äquivalent mit
<code>FileETag MTime Size</code>.</p>
</usage>
</directivesynopsis>
<directivesynopsis type="section">
<name>Files</name>
<description>Enthält Direktiven, die sich nur auf passende Dateinamen
beziehen</description>
<syntax><Files <var>Dateiname</var>> ... </Files></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<usage>
<p>Die Direktive <directive type="section">Files</directive>
begrenzt die Reichweite der enthaltenen Anweisungen auf Dateinamen.
Sie ist vergleichbar mit den Direktiven <directive
module="core" type="section">Directory</directive> und <directive
module="core" type="section">Location</directive>. Sie muss eine
passende <code></Files></code>-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. <directive
type="section">Files</directive>-Container werden, nachdem die
<directive module="core" type="section">Directory</directive>-Container
und <code>.htaccess</code>-Dateien gelesen sind, jedoch vor den
<directive type="section" module="core">Location</directive>-Containern,
in der Reihenfolge ihres Auftretens ausgeführt. Beachten Sie, dass
<directive type="section">Files</directive>-Anweisungen innerhalb von
<directive type="section" module="core">Directory</directive>-Containern
auftreten können, um den Teil des Dateisystems einzuschränken,
den sie betreffen.</p>
<p>Das Argument <var>Dateiname</var> kann einen Dateinamen oder eine
Zeichenkette mit Platzhaltern enthalten, wobei <code>?</code> auf ein
einzelnes Zeichen passt und <code>*</code> auf eine beliebige Folge von
Zeichen. Erweiterte <glossary ref="regex">reguläre
Ausdrücke</glossary> können ebenfalls verwendet werden, indem
das Zeichen <code>~</code> hinzugefügt wird. Beispielsweise
würde</p>
<example>
<Files ~ "\.(gif|jpe?g|png)$">
</example>
<p>auf die gebräuchlichsten Grafikformate im Internet passen.
<directive module="core" type="section">FilesMatch</directive> wird
jedoch bevorzugt.</p>
<p>Beachten Sie bitte, dass die <directive
type="section">Files</directive>-Container anders als <directive
type="section" module="core">Directory</directive>- und <directive
type="section" module="core">Location</directive>-Container innerhalb
von <code>.htaccess</code>-Dateien verwendet werden können.
Dies erlaubt den Anwendern auf Dateiebene die Kontrolle über ihre
eigenen Dateien.</p>
</usage>
<Location> und <Files> arbeiten</a> für eine
Erläuterung, wie diese verschiedenen Abschnitte miteinander
kombiniert werden, wenn eine Anfrage empfangen wird</seealso>
</directivesynopsis>
<directivesynopsis type="section">
<name>FilesMatch</name>
<description>Enthält Direktiven, die für Dateinamen gelten, die
auf einen regulären Ausdruck passen</description>
<syntax><FilesMatch <var>regex</var>> ... </FilesMatch></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<usage>
<p>Die Direktive <directive type="section">FilesMatch</directive>
begrenzt wie die Direktive <directive module="core"
type="section">Files</directive> die enthaltenen Anweisungen auf
Dateinamen. Sie akzeptiert jedoch <glossary ref="regex">reguläre
Ausdrücke</glossary>. Beispielsweise würde</p>
<example>
<FilesMatch "\.(gif|jpe?g|png)$">
</example>
<p>auf die gebräuchlichsten Grafikformate im Internet passen.</p>
</usage>
<Location> und <Files> arbeiten</a> für eine
Erläuterung, wie diese verschiedenen Abschnitte miteinander
kombiniert werden, wenn eine Anfrage empfangen wird</seealso>
</directivesynopsis>
<directivesynopsis>
<name>ForceType</name>
<description>Erzwingt die Auslieferung aller passendenden Dateien mit dem
angegebenen MIME-Content-Type</description>
<syntax>ForceType <var>MIME-Type</var>|None</syntax>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>FileInfo</override>
<compatibility>Wurde im Apache 2.0 in den Core verschoben</compatibility>
<usage>
<p>Wenn sie innerhalb einer <code>.htaccess</code>-Datei, eines
<directive type="section" module="core">Directory</directive>-,
<directive type="section" module="core">Location</directive>-
<directive type="section" module="core">Files</directive>-Containers
angegeben wird, erzwingt die Direktive die Auslieferung aller
entsprechenden Dateien mit dem Content-Type, der durch
<var>MIME-Type</var> definiert wurde. Wenn Sie zum Beispiel ein
Verzeichnis voller GIF-Dateien haben, die Sie nicht alle durch
<code>.gif</code> kennzeichnen wollen, können Sie angeben:</p>
<example>
</example>
<p>Beachten Sie bitte, dass die Direktive anders als <directive
module="core">DefaultType</directive> alle MIME-Type-Zuordnungen
überschreibt, einschließlich Dateiendungen, die einen
Medientyp bezeichnen könnten.</p>
<p>Sie können jede <directive>ForceType</directive>-Angabe
durch die Verwendung des Wertes <code>None</code> überschreiben:</p>
<example>
<Location /images><br />
<indent>
</indent>
</Location><br />
<br />
# hier jedoch normale MIME-Type-Zuordnungen:<br />
<indent>
ForceType None<br />
</indent>
</Location>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>HostnameLookups</name>
<description>Aktiviert DNS-Lookups auf Client-IP-Adressen</description>
<syntax>HostnameLookups On|Off|Double</syntax>
<default>HostnameLookups Off</default>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context></contextlist>
<usage>
<p>Diese Direktive aktiviert die DNS-Abfrage <transnote>ein sogenannter
DNS-Lookup</transnote>, so dass Hostnamen protokolliert (und in
Der Wert <code>Double</code> 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 <code>PARANOID</code>
genannt.)</p>
<p>Unabhängig von der Einstellung wird ein Double-Reverse-Lookup
durchgeführt, wenn <module>mod_authz_host</module> 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 <code>HostnameLookups Double</code> setzen. Wenn beispielsweise
nur <code>HostnameLookups On</code> 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 <code>REMOTE_HOST</code> übergeben,
egal ob das Doble-Reverse-Lookup fehlschlug oder nicht.</p>
<p>Die Voreinstellung ist <code>Off</code>, 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
<code>Off</code>lassen. Das Hilfsprogramm <program>
logresolve</program>, das standardmäßig in das
Unterverzeichnis <code>bin</code> Ihres Installationsverzeichnisses
kompiliert wird, kann dazu verwendet werden, um offline Hostnamen von
protokollierten IP-Adressen nachzuschlagen.</p>
</usage>
</directivesynopsis>
<directivesynopsis type="section">
<name>IfDefine</name>
<description>Schließt Direktiven ein, die nur ausgeführt werden,
wenn eine Testbedingung beim Start wahr ist</description>
<syntax><IfDefine [!]<var>Parametername</var>> ...
</IfDefine></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<usage>
<p>Der Container <code><IfDefine <var>Test</var>>...</IfDefine>
</code> wird dazu verwendet, Direktiven als bedingt zu kennzeichnen.
Die Direktiven innerhalb eines <directive
type="section">IfDefine</directive>-Abschnittes werden nur ausgeführt,
wenn <var>Test</var> wahr ist. Ist <var>Test</var> falsch, wird alles
zwischen der Start- und Endemarkierung ignoriert.</p>
<p>In der <directive type="section">IfDefine</directive>-Anweisung kann
<var>Test</var> eine von zwei Formen annehmen:</p>
<ul>
<li><var>Parametername</var></li>
<li><code>!</code><var>Parametername</var></li>
</ul>
<p>Im ersten Fall werden die Direktiven zwischen der Start- und
Endemarkierung nur ausgeführt, wenn der Parameter namens
<var>Parametername</var> definiert ist. Die zweite Form kehrt den
Test um und führt die Direktiven nur dann aus, wenn
<var>Parametername</var> <strong>nicht</strong> definiert ist.</p>
<p>Das Argument <var>Parametername</var> ist ein sogenanntes
"Define", das beim beim Start des Servers in der
<program>httpd</program>-Befehlszeile durch
<code>-D<var>Parameter</var></code> angegeben wird.</p>
<p><directive type="section">IfDefine</directive>-Container können
ineinander verschachtelt werden, um einfache Multi-Parameter-Tests
zu implementieren. Beispiel:</p>
<example>
httpd -DReverseProxy ...<br />
<br />
# httpd.conf<br />
<IfDefine ReverseProxy><br />
<indent>
</indent>
</IfDefine>
</example>
</usage>
</directivesynopsis>
<directivesynopsis type="section">
<name>IfModule</name>
<description>Schließt Direktiven ein, die abhängig vom
Vorhandensein oder Fehlen eines speziellen Moduls ausgeführt
werden</description>
<syntax><IfModule [!]<var>Modulname</var>|<var>Modulbezeichner</var>>
... </IfModule></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<compatibility>Modulbezeichner sind ab Version 2.1
verfügbar.</compatibility>
<usage>
<p>Der Container <code><IfModule
<var>Test</var>>...</IfModule></code> wird dazu verwendet,
Direktiven als abhängig von dem Vorhandensein eines speziellen
Moduls zu kennzeichnen. Die Direktiven innerhalb eines <directive
type="section">IfModule</directive>-Abschnitts werden nur
ausgeführt, wenn <var>Test</var> wahr ist. Ist <var>Test</var>
falsch, wird alles zwischen der Start- und Endemarkierung ignoriert.</p>
<p>In der <directive type="section">IfModule</directive>-Anweisung
kann <var>Test</var> eine von zwei Formen annehmen:</p>
<ul>
<li><var>Modul</var></li>
<li><code>!</code><var>Modul</var></li>
</ul>
<p>Im ersten Fall werden die Direktiven zwischen der Start- und
Endemarkierung nur ausgeführt, das Modul namens
<var>Modul</var> im Apache enthalten ist -- entweder einkompiliert
oder mittels <directive module="mod_so">LoadModule</directive>
dynamisch geladen. Die zweite Form dreht den Test um und führt die
Direktiven nur aus, wenn <var>Modul</var> <strong>nicht</strong>
enthalten ist.</p>
<p>Das Argument <var>Modul</var> kann entweder der Modulbezeichner oder
der Dateiname des Moduls zum Zeitpunkt seiner Kompilierung sein.
<code>rewrite_module</code> beispielsweise ist der Bezeichner und
Quelltext-Dateien besteht, verwenden Sie den Namen der Datei, welche die
Zeichenfolge <code>STANDARD20_MODULE_STUFF</code> enthält.</p>
<p><directive type="section">IfModule</directive>-Container können
inneinander verschachtelt werden, um einfache Multi-Modul-Tests
durchzuführen.</p>
<p>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 <directive
type="section">IfModule</directive>-Containern unterzubringen.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>Include</name>
<description>Fügt andere Konfigurationsdateien innerhalb der
Server-Konfigurationsdatei ein</description>
<syntax>Include <var>Dateiname</var>|<var>Verzeichnis</var></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context>
</contextlist>
<compatibility>Die Platzhalter-Suche ist verfügbar seit
2.0.41</compatibility>
<usage>
<p>Die Direktive erlaubt das Einfügen anderer Konfigurationsdateien
in die Konfigurationsdatei des Servers.</p>
<p>Shell-typische (<code>fnmatch()</code>) Platzhlaterzeichen können
dazu verwendet werden, mehrere Dateien auf einmal in alphabetischer
Reihenfolge einzufügen. Wenn <directive>Include</directive>
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
<program>httpd</program> scheitern lassen kann.</p>
<p>Der angegebene Dateiname kann ein absoluter Pfad sein oder relativ zum
<directive module="core">ServerRoot</directive>-Verzeichnis angegeben
werden.</p>
<p>Beispiele:</p>
<example>
</example>
<p>Oder Sie geben Pfade relativ zu Ihrem <directive
module="core">ServerRoot</directive>-Verzeichnis an:</p>
<example>
</example>
<p>Der Aufruf von <code>apachectl configtest</code> liefert eine Liste
der Dateien, die während des Konfigurations-Tests verarbeitet
werden:</p>
<example>
root@host# apachectl configtest<br />
Syntax OK
</example>
</usage>
<seealso><program>apachectl</program></seealso>
</directivesynopsis>
<directivesynopsis>
<name>KeepAlive</name>
<description>Aktiviert persistente HTTP-Verbindungen</description>
<syntax>KeepAlive On|Off</syntax>
<default>KeepAlive On</default>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
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 <code>KeepAlive On</code>.</p>
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.</p>
</usage>
<seealso><directive module="core">MaxKeepAliveRequests</directive></seealso>
</directivesynopsis>
<directivesynopsis>
<name>KeepAliveTimeout</name>
<description>Zeitspanne, die der Server während persistenter Verbindungen
auf nachfolgende Anfragen wartet</description>
<syntax>KeepAliveTimeout <var>Sekunden</var></syntax>
<default>KeepAliveTimeout 5</default>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p>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
<directive module="core">Timeout</directive> festgelegte Auszeit
angewendet.</p>
<p>Auf stark belasteten Servern kann ein hoher
<directive>KeepAliveTimeout</directive>-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.</p>
</usage>
</directivesynopsis>
<directivesynopsis type="section">
<name>Limit</name>
<description>Beschränkt die eingeschlossenen Zugriffskontrollen auf
bestimmte HTTP-Methoden</description>
<syntax><Limit <var>Methode</var> [<var>Methode</var>] ... > ...
</Limit></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<usage>
<p>Zugriffskontrollen gelten normalerweise für <strong>alle</strong>
Zugriffsmethoden, was normalerweise auch das gewünschte Verhalten ist.
<strong>Im Allgemeinen sollten Zugriffskontrollen nicht in einen
<directive type="section">Limit</directive>-Container gepackt
werden.</strong></p>
<p>Der Sinn der Direktive <directive type="section">Limit</directive>
ist es, den Effekt der Zugriffskontrollen auf die angegebenen
HTTP-Methoden zu beschränken. Bei allen anderen Methoden haben
die in der <directive type="section">Limit</directive>-Gruppe
enthaltenen Zugriffsbeschränkungen <strong>keine Wirkung</strong>.
Im folgenden Beispiel gilt die Zugriffskontrolle nur für die
Methoden <code>POST</code>, <code>PUT</code> und <code>DELETE</code>.
Alle anderen Methoden bleiben ungeschützt:</p>
<example>
<Limit POST PUT DELETE><br />
<indent>
Require valid-user<br />
</indent>
</Limit>
</example>
<p>Sie können eine oder mehrere der folgenden Methoden angeben:
<code>GET</code>, <code>POST</code>, <code>PUT</code>, <code>DELETE</code>,
<code>CONNECT</code>, <code>OPTIONS</code>,
<code>PATCH</code>, <code>PROPFIND</code>, <code>PROPPATCH</code>,
<code>MKCOL</code>, <code>COPY</code>, <code>MOVE</code>,
<code>LOCK</code> und <code>UNLOCK</code>. <strong>Die Methodennamen
unterscheiden zwischen Groß- und Kleinschreibung.</strong> Wenn
<code>GET</code> verwendet wird, sind <code>HEAD</code>-Anfragen
ebenfalls eingeschränkt. Die <code>TRACE</code>-Methode kann nicht
limitiert werden.</p>
<note type="warning">
Wenn es um Zugriffsbeschränkungen geht, sollte
ein <directive module="core" type="section"
>LimitExcept</directive>-Container sollte immer einem <directive
module="core" type="section">Limit</directive>-Container vorgezogen
werden, da <directive module="core" type="section">LimitExcept</directive>
einen Schutz gegen beliebige Methoden bietet.
</note>
</usage>
</directivesynopsis>
<directivesynopsis type="section">
<name>LimitExcept</name>
<description>Beschränkt Zugriffskontrollen auf alle HTTP-Methoden
außer den genannten</description>
<syntax><LimitExcept <var>Methode</var> [<var>Methode</var>] ... > ...
</LimitExcept></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<usage>
<p><directive type="section">LimitExcept</directive> und
<code></LimitExcept></code> werden dazu verwendet, eine Gruppe
von Anweisungen zur Zugriffskontrolle zusammenzufassen, die dann auf
jede HTTP-Methode angewendet werden, die <strong>nicht</strong>
als Argument angegeben ist. D.h. dies ist das Gegenteil des
<directive type="section" module="core">Limit</directive>-Containers
und kann zur Steuerung von Standard- und nicht-Standard-/unbekannten
Methoden verwendet werden. Für weitere Einzelheiten lesen Sie bitte
die Beschreibung zu <directive module="core"
type="section">Limit</directive>.</p>
<p>Beispiel:</p>
<example>
<LimitExcept POST GET><br />
<indent>
Require valid-user<br />
</indent>
</LimitExcept>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>LimitInternalRecursion</name>
<description>Bestimmt die maximale Anzahl interner Umleitungen und
verschachtelter Unteranfragen</description>
<syntax>LimitInternalRecursion <var>Zahl</var> [<var>Zahl</var>]</syntax>
<default>LimitInternalRecursion 10</default>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<compatibility>Verfügbar ab Apache 2.0.47</compatibility>
<usage>
<p>Eine interne Umleitung erfolgt beispielsweise, wenn die Direktive
<directive module="mod_actions">Action</directive> verwendet wird, welche
die Originalanfrage intern zu einem CGI-Skript weiterleitet. Eine
Unteranfrage <transnote>engl. Subrequest</transnote> ist ein Mechanismus des
Apache, um herauszufinden, was bei einer URI geschehen würde, wäre
Unteranfragen, um nach den Dateien zu suchen, die in der <directive
module="mod_dir">DirectoryIndex</directive>-Anweisung aufgeführt
sind.</p>
<p><directive>LimitInternalRecursion</directive> bewahrt den Server vor
einem Absturz, wenn er in eine Endlosschleife aus internen Umleitungen
oder Unteranfragen hineinläuft. Derartige Schleifen werden
gewöhnlich durch Fehlkonfiguration verursacht.</p>
<p>Die Direktive setzt zwei verschiedene Begrenzungen, welche je Anfrage
ausgewertet werden. Die erste <var>Zahl</var> bestimmt die maximale
Anzahl der Umleitungen, die aufeinander folgen dürfen. Die zweite
<var>Zahl</var> legt fest, wie tief Unteranfragen ineinander
verschachtelt werden dürfen. Wenn Sie lediglich eine <var>Zahl</var>
angeben, wird sie beiden Begrenzungen zugewiesen.</p>
<example><title>Beispiel</title>
LimitInternalRecursion 5
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>LimitRequestBody</name>
<description>Begrenzt die Gesamtgröße des vom Client gesendeten
HTTP-Request-Body</description>
<syntax>LimitRequestBody <var>Bytes</var></syntax>
<default>LimitRequestBody 0</default>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<usage>
<p>Die Direktive gibt die Anzahl der <var>Bytes</var> zwischen 0
(unbegrenzt) und 2147483647 (2GB) an, die im Request-Body (Datenteil der
Anfrage) erlaubt sind.</p>
<p>Die Direktive <directive>LimitRequestBody</directive> 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 <code>PUT</code>-Methode angewendet, dann muss der Wert mindestens
so groß sein wie irgendeine Darstellungsform, die der Server
für diese Ressource akzeptieren soll.</p>
<p>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.</p>
<p>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:</p>
<example>
LimitRequestBody 102400
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>LimitRequestFields</name>
<description>Begrenzt die Anzahl der HTTP-Request-Header, die vom Client
entgegengenommen werden</description>
<syntax>LimitRequestFields <var>Anzahl</var></syntax>
<default>LimitRequestFields 100</default>
<contextlist><context>server config</context></contextlist>
<usage>
<p><var>Anzahl</var> ist ein Integer-Wert (eine positive Ganzzahl)
zwischen 0 (unbegrenzt) und 32767. Die Voreinstellung wird durch die
Konstante <code>DEFAULT_LIMIT_REQUEST_FIELDS</code> (<code>100</code>
bei der Auslieferung) zur Kompilierungszeit gesetzt.</p>
<p>Die Direktive <directive>LimitRequestFields</directive> 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.</p>
<p>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.</p>
<p>Beispiel:</p>
<example>
LimitRequestFields 50
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>LimitRequestFieldSize</name>
<description>Begrenzt die Länge des vom Client gesendeten
HTTP-Request-Headers</description>
<syntax>LimitRequestFieldsize <var>Bytes</var></syntax>
<default>LimitRequestFieldsize 8190</default>
<contextlist><context>server config</context></contextlist>
<usage>
<p>Die Direktive gibt die Anzahl der <var>Bytes</var> an, die in einem
HTTP-Header erlaubt sind.</p>
<p>Die Direktive <directive>LimitRequestFieldsize</directive> erlaubt es
dem Serveradministrator, die maximale Größe eines
HTTP-Request-Headers zu verringern oder erhöhen. Für den Server
muss der Wert groß genug sein, um eine beliebige Headerzeile einer
normalen Client-Anfrage vorzuhalten. Die Größe variiert stark
zwischen den verschiedenen Client-Ausführungen, oft abhängig vom
Ausmaß, mit dem der Anwender die genaue
Content-Negotiation-Unterstützung seines Browsers konfiguriert hat.
SPNEGO-Authentisierungs-Header können bis zu 12392 Bytes lang
sein.</p>
<p>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.</p>
<p>Beispiel:</p>
<example>
LimitRequestFieldSize 4094
</example>
<note>Unter normalen Umständen sollte die Voreinstellung nicht
verändert werden.</note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>LimitRequestLine</name>
<description>Begrenzt die Länge der vom Client entgegengenommenen
HTTP-Anfragezeile</description>
<syntax>LimitRequestLine <var>Bytes</var></syntax>
<default>LimitRequestLine 8190</default>
<contextlist><context>server config</context></contextlist>
<usage>
<p>Die Direktive legt die Anzahl der <var>Bytes</var> fest, die in der
HTTP-Anfragezeile erlaubt sind.</p>
<p>Die Direktive <directive>LimitRequestLine</directive> erlaubt es dem
Serveradministrator, die maximale Größe der
HTTP-Anfragezeile zu verringern oder erhöhen. Da
die Anfragezeile aus der HTTP-Methode, der URI und der Protokollversion
besteht, bedeutet die <directive>LimitRequestLine</directive>-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
<code>GET</code>-Anfrage übergeben werden können.</p>
<p>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.</p>
<p>Beispiel:</p>
<example>
LimitRequestLine 4094
</example>
<note>Unter normalen Umständen sollte die Voreinstellung nicht
verändert werden.</note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>LimitXMLRequestBody</name>
<description>Begrenzt die Größe eines XML-basierten
Request-Bodys</description>
<syntax>LimitXMLRequestBody <var>Bytes</var></syntax>
<default>LimitXMLRequestBody 1000000</default>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context></contextlist>
<override>All</override>
<usage>
<p>Dies gibt die Grenze für die maximale Größe (in Bytes)
des XML-basierten Request-Bodys an. Der Wert <code>0</code> deaktiviert
diese Prüfung.</p>
<p>Beispiel:</p>
<example>
LimitXMLRequestBody 0
</example>
</usage>
</directivesynopsis>
<directivesynopsis type="section">
<name>Location</name>
<description>Wendet die enthaltenen Direktiven nur auf die entsprechenden
URLs an</description>
<syntax><Location
<var>URL-Pfad</var>|<var>URL</var>> ... </Location></syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p>Die Direktive <directive type="section">Location</directive>
begrenzt die Reichweite der enthaltenen Anweisungen auf URLs.
Sie ist der Direktive <directive type="section"
module="core">Directory</directive> ähnlich und startet einen
Abschnitt, der mit der Anweisung <code></Location></code>
abgeschlossen wird. <directive
type="section">Location</directive>-Container werden, nachdem die
<directive type="section" module="core">Directory</directive>-Container
und <code>.htaccess</code>-Dateien gelesen wurden, und nach den
<directive type="section" module="core">Files</directive>-Containern, in
der Reihenfolge ausgeführt, in der sie in der Konfigurationsdatei
erscheinen.</p>
<p><directive type="section">Location</directive>-Abschnitte operieren
vollständig außerhalb des Dateisystems. Dies hat mehrere
Konsequenzen. An Wichtigsten, <directive
type="section">Location</directive>-Anweisungen sollten nicht dafür
verwendet werden, den Zugriff zu Teilen des Dateisystems zu steuern. Da
mehrere unterschiedliche URLs auf die gleiche Stelle des Dateisystems
zeigen können, könnte eine solche Zugriffskontrolle u.U.
umgangen werden.</p>
<note><title>Wann sollte<directive
type="section">Location</directive> verwendet werden</title>
<p>Verwenden Sie <directive type="section">Location</directive>, um
Anweisungen auf Inhalte anzuwenden, die außerhalb des Dateisystems
abgelegt sind. Benutzen Sie <directive
type="section" module="core">Directory</directive> und <directive
type="section" module="core">Files</directive> für Inhalte, die
innerhalb des Dateisystems abgelegt sind. Eine Ausnahme bildet
<code><Location /></code>, welches ein einfacher Weg ist, um eine
Konfiguration auf den gesamten Server anzuwenden.</p>
</note>
<p>Für alle nicht-Proxy-Anfragen ist die entsprechende URL
ein URL-Pfad in der Form <code>/path/</code>. 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
werden.</p>
<p>Die URL kann Platzhalter verwenden. In einer Zeichenfolge mit
Platzhaltern entspricht <code>?</code> einem einzelnen Zeichen und
<code>*</code>einer beliebigen Zeichenfolge.</p>
<p>Erweiterte <glossary ref="regex">reguläre
Ausdrücke</glossary> können ebenfalls verwendet werden, indem
das Zeichen <code>~</code> hinzugefügt wird. Beispielsweise
würde</p>
<example>
<Location ~ "/(extra|special)/data">
</example>
type="section" module="core">LocationMatch</directive> verhält sich
genauso wie <directive type="section">Location</directive> mit
regulären Ausdrücken.</p>
<p>Die Funktionalität von <directive
type="section">Location</directive> ist insbesondere dann nützlich,
wenn sie mit der <directive module="core">SetHandler</directive>-Direktive
kombiniert wird. Um zum Beispiel Statusabfragen zu aktivieren, sie aber
schreiben:</p>
<example>
<Location /status><br />
<indent>
SetHandler server-status<br />
Order Deny,Allow<br />
Deny from all<br />
Allow from .foo.com<br />
</indent>
</Location>
</example>
<note><title>Anmerkung zu / (Schrägstrich, Slash)</title>
<p>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
genauso. Bei der Direktive <directive type="section"
module="core">LocationMatch</directive> und der <directive type="section"
>Location</directive>-Version mit regulären Ausdrücken
müssen Sie explizit mehrere Schrägstriche angeben, wenn Sie
genau dies beabsichtigen.</p>
<p>Beispielsweise würde <code><LocationMatch ^/abc></code>
auf die angeforderte URL <code>/abc</code> passen, nicht aber auf
<code>//abc</code>. Die Direktive <directive type="section"
>Location</directive> (ohne reguläre Ausdrücke) verhält
sich ähnlich, wenn sie für Proxy-Anfragen verwendet wird.
Wenn <directive type="section">Location</directive> (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
Anfrage lautet auf <code>/abc//def</code>, dann greift die Anweisung.</p>
</note>
</usage>
<Location> und <Files> arbeiten</a> für eine
Erläuterung, wie diese verschiedenen Abschnitte miteinander
kombiniert werden, wenn eine Anfrage empfangen wird</seealso>
</directivesynopsis>
<directivesynopsis type="section">
<name>LocationMatch</name>
<description>Wendet die enthaltenen Direktiven nur auf URLs an, die auf
reguläre Ausdrücke passen</description>
<syntax><LocationMatch
<var>regex</var>> ... </LocationMatch></syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p>Die Direktive <directive type="section">LocationMatch</directive>
begrenzt die Reichweite der enthaltenen Anweisungen in der gleichen Weise
wie <directive module="core" type="section">Location</directive> auf URLs.
Sie verwendet jedoch <glossary ref="regex">reguläre
Ausdrücke</glossary> als Argument anstelle einer einfachen
Zeichenkette. Beispielsweise würde</p>
<example>
<LocationMatch "/(extra|special)/data">
</example>
</usage>
<Location> und <Files> arbeiten</a> für eine
Erläuterung, wie diese verschiedenen Abschnitte miteinander
kombiniert werden, wenn eine Anfrage empfangen wird</seealso>
</directivesynopsis>
<directivesynopsis>
<name>LogLevel</name>
<description>Steuert die Ausführlichkeit des Fehlerprotokolls</description>
<syntax>LogLevel <var>Level</var></syntax>
<default>LogLevel warn</default>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p><directive>LogLevel</directive> stellt die Ausführlichkeit
der Nachrichten ein, die im Fehlerprotokoll aufgezeichnet werden (siehe
Direktive <directive module="core">ErrorLog</directive>). Die folgenden,
nach absteigender Aussagekraft sortierten <var>Level</var> sind
verfügbar:</p>
<table border="1">
<columnspec><column width=".2"/><column width=".3"/><column width=".5"/>
</columnspec>
<tr>
<th><strong>Level</strong> </th>
<th><strong>Beschreibung</strong> </th>
<th><strong>Beispiel</strong> </th>
</tr>
<tr>
<td><code>emerg</code> </td>
<td>Notfall - das System ist unbenutzbar.</td>
<td>"Child cannot open lock file. Exiting"
<transnote>"Kindprozess kann die Lock-Datei nicht öffnen.
Beende Programm"</transnote></td>
</tr>
<tr>
<td><code>alert</code> </td>
<td>Maßnahmen müssen unverzüglich ergriffen
werden.</td>
<td>"getpwuid: couldn't determine user name from uid"
<transnote>"getpwuid: kann keinen Benutzernamen aus der UID
ermitteln"</transnote></td>
</tr>
<tr>
<td><code>crit</code> </td>
<td>Kritischer Zustand.</td>
<td>"socket: Failed to get a socket, exiting child"
<transnote>"socket: Socket-Zuweisung fehlgeschlagen, beende
Kindprozess"</transnote></td>
</tr>
<tr>
<td><code>error</code> </td>
<td>Fehlerbedingung.</td>
<td>"Premature end of script headers"
<transnote>"Vorzeitiges Ende der Skript-Header"</transnote></td>
</tr>
<tr>
<td><code>warn</code> </td>
<td>Warnung.</td>
<td>"child process 1234 did not exit, sending another SIGHUP"
<transnote>"Kindprozess 1234 nicht beendet, sende ein weiteres
SIGHUP"</transnote></td>
</tr>
<tr>
<td><code>notice</code> </td>
<td>Normaler, aber signifikanter Zustand.</td>
<td>"httpd: caught SIGBUS, attempting to dump core in ..."
<transnote>"httpd: SIGBUS empfangen, versuche Speicherabbild nach ...
zu schreiben"</transnote></td>
</tr>
<tr>
<td><code>info</code> </td>
<td>Information.</td>
<td>"Server seems busy, (you may need to increase
StartServers, or Min/MaxSpareServers)..."
<transnote>"Server scheint beschäftigt zu sein,
(möglicherweise müssen Sie StartServers oder
</tr>
<tr>
<td><code>debug</code> </td>
<td>Debug-Level-Nachrichten</td>
<td>"Opening config file ..."
<transnote>"Öffne Konfigurationsdatei ..."</transnote></td>
</tr>
</table>
<p>Geben Sie einen bestimmten Level an, denn werden Nachrichten von
<code>LogLevel info</code> eingestellt ist, dann werden Nachrichten der
Log-Level <code>notice</code> und <code>warn</code> ebenso eingetragen.</p>
<p>Es wird empfohlen, mindestens den Level <code>crit</code> zu
verwenden.</p>
<p>Beispiel:</p>
<example>
LogLevel notice
</example>
<note><title>Hinweis</title>
<p>Beim Protokollieren in eine reguläre Datei können
Nachrichten des Levels <code>notice</code> nicht unterdrückt
werden und werden daher immer protokolliert. Dies trifft allerdings
nicht zu, wenn mittels <code>syslog</code> protokolliert wird.</p>
</note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>MaxKeepAliveRequests</name>
<description>Anzahl der Anfragen, die bei einer persistenten Verbindung
zulässig sind</description>
<syntax>MaxKeepAliveRequests <var>Anzahl</var></syntax>
<default>MaxKeepAliveRequests 100</default>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p>Die Direktive <directive>MaxKeepAliveRequests</directive>
begrenzt die Anzahl der Anfragen, die pro Verbindung zulässig sind,
wenn <directive module="core" >KeepAlive</directive> eingeschaltet ist.
Bei der Einstellung <code>0</code> sind unbegrenzt viele Anfragen
erlaubt. Wir empfehlen für diese Einstellung einen hohen Wert
für eine maximale Serverleistung.</p>
<p>Beispiel:</p>
<example>
MaxKeepAliveRequests 500
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>NameVirtualHost</name>
<description>Bestimmt eine IP-Adresse für den Betrieb namensbasierter
virtueller Hosts</description>
<syntax>NameVirtualHost <var>Adresse</var>[:<var>Port</var>]</syntax>
<contextlist><context>server config</context></contextlist>
<usage>
<p>Die Direktive <directive>NameVirtualHost</directive> ist erforderlich,
konfigurieren möchten.</p>
<p>Obwohl <var>Adresse</var> eine Hostname sein kann, wird empfohlen,
dass Sie stets eine IP-Adresse verwenden, z.B.:</p>
<example>
NameVirtualHost 111.22.33.44
</example>
<p>Mit der <directive>NameVirtualHost</directive>-Anweisung geben Sie
die IP-Adresse an, unter der der Server Anfragen für
namensbasierte virtuelle Hosts entgegennimmt. Das ist üblicherweise
die Adresse, zu der die Namen Ihrer namensbasierten virtuellen Hosts
aufgelöst werden. Falls eine Firewall oder ein anderer Proxy die
Anfrage in Empfang nimmt und Sie zu einer weiteren IP-Adresse des Servers
weiterleitet, müssen Sie die IP-Adresse der physikalischen
Schnittstelle der Maschine angeben, welche die Anfragen bedient.
Wenn Sie mehrere namensbasierte Hosts an verschiedenen Adressen
betreiben, wiederholen Sie einfach die Anweisung für jede
Adresse.</p>
<note><title>Anmerkung</title>
<p>Beachten Sie, dass der "Hauptserver" und jeder
<code>_default_</code>-Server <strong>niemals</strong> bei einer
Anfrage an einer <directive>NameVirtualHost</directive>-IP-Adresse
bedient wird (es sei denn, Sie geben aus irgendwelchen Gründen
<directive>NameVirtualHost</directive> an, definieren dann aber keine
<directive>VirtualHost</directive>s für diese Adresse).</p>
</note>
<p>Optional können Sie die Nummer eines Ports angeben, an dem
namensbasierte virtuelle Hosts verwendet werden sollen. Beispiel:</p>
<example>
NameVirtualHost 111.22.33.44:8080
</example>
<p>IPv6-Adressen müssen, wie im folgenden Beispiel angegeben, in
eckige Klammern eingeschlossen werden:</p>
<example>
NameVirtualHost [2001:db8::a00:20ff:fea7:ccea]:8080
</example>
<p>Um an allen Schnittstellen Anfragen zu empfangen, können Sie
<code>*</code> als Argument verwenden.</p>
<example>
NameVirtualHost *
</example>
<note><title>Argument der Direktive <directive
type="section">VirtualHost</directive></title>
<p>Beachten Sie, dass das Argument der <directive
type="section">VirtualHost</directive>-Anweisung exakt auf das Argument
der <directive>NameVirtualHost</directive>-Anweisung passen muss.</p>
<example>
NameVirtualHost 1.2.3.4<br />
<VirtualHost 1.2.3.4><br />
# ...<br />
</VirtualHost><br />
</example>
</note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>Options</name>
<description>Definiert, welche Eigenschaften oder Funktionen in einem
bestimmten Verzeichnis verfügbar sind</description>
<syntax>Options
[+|-]<var>Option</var> [[+|-]<var>Option</var>] ...</syntax>
<default>Options All</default>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>Options</override>
<usage>
<p>Die Direktive <directive>Options</directive> steuert, welche
Eigenschaften bzw. Funktionen in einem bestimmten Verzeichnis
verfügbar sind.</p>
<p><var>Option</var> kann auf <code>None</code> gesetzt werden, wobei
keine der besonderen Eigenschaften verfügbar sind, oder auf eines
oder mehrere der folgenden:</p>
<dl>
<dt><code>All</code></dt>
<dd>Alle Optionen außer <code>MultiViews</code>. Dies ist
die Voreinstellung.</dd>
<dt><code>ExecCGI</code></dt>
<dd>Die Ausführung von CGI-Skripten, welche <module>mod_cgi</module>
verwenden, ist erlaubt.</dd>
<dt><code>FollowSymLinks</code></dt>
<dd>Der Server folgt symbolischen Links in diesem Verzeichnis.
<note>
<p>Auch wenn der Server symbolischen Links folgt, bedeutet dies
<em>nicht</em>, dass der zum Abgleich gegen <directive type="section"
module="core">Directory</directive>-Abschnitte verwendete Pfadname
wechselt.</p>
<p>Beachten Sie auch, dass diese Option innerhalb eines
<directive type="section" module="core">Location</directive>-Abschnitts
<strong>ignoriert wird</strong>.</p>
</note></dd>
<dt><code>Includes</code></dt>
<dd>
Server Side Includes, die von <module>mod_include</module> bereitgestellt
werden, sind erlaubt.</dd>
<dt><code>IncludesNOEXEC</code></dt>
<dd>Server Side Includes sind erlaubt, <code>#exec cmd</code>
und <code>#exec cgi</code> sind jedoch deaktiviert. Es ist aber noch
möglich, CGI-Skripte aus
<directive module="mod_alias">ScriptAlias</directive>-Verzeichnissen mittels
<code>#include virtual</code> einzubinden.</dd>
<dt><code>Indexes</code></dt>
<dd>Wenn eine URL, die auf ein Verzeichnis zeigt, in dem sich keine durch
<directive module="mod_dir">DirectoryIndex</directive> definierte
<module>mod_autoindex</module> eine formatierte Auflistung des
Verzeichnisses zurück.</dd>
<dt><code>MultiViews</code></dt>
<dd>"MultiViews" sind bei der Verwendung von
<module>mod_negotiation</module> erlaubt (siehe <a
<dt><code>SymLinksIfOwnerMatch</code></dt>
<dd>Der Server folgt nur symbolischen Links, bei denen die Zieldatei
bzw. das Zielverzeichnis der gleichen Benutzerkennung gehört, wie
der Link.
<note><title>Anmerkung</title> Diese Option wird innerhalb eines
<directive module="core" type="section">Location</directive>-Abschnitts
ignoriert.</note></dd>
</dl>
<p>Wenn mehrere <directive>Options</directive> auf ein Verzeichnis
angewandt werden können, dann wird normalerweise die
spezifischste <transnote>Gemeint ist die zuletzt
ausgeführte Option.</transnote> verwendet und alle anderen werden
ignoriert; die Optionen werden nicht vermischt. (Siehe auch <a
href="/sections.html#mergin">Wie Abschnitte zusammengeführt
werden.</a>.) Wenn jedoch <em>allen</em> Optionen der
<directive>Options</directive>-Anweisung eines der Zeichen
<code>+</code> oder <code>-</code> vorangestellt wird, werden die Optionen
zusammengemischt. Jede Option mit vorangestelltem <code>+</code> wird
zu den momentan gültigen Optionen hinzugefügt und jede Option
mit vorangestelltem <code>-</code> wird aus den derzeit gültigen
Optionen entfernt.</p>
<note type="warning"><title>Warnung</title>
<p>Die Vermischung von Optionen mit <code>+</code> oder <code>-</code> mit
Optionen ohne diese (Zeichen) ist keine gültige Syntax und führt
mit hoher Wahrscheinlichkeit zu unerwarteten Effekten.</p>
</note>
<p>So wird zum Beispiel ohne die Zeichen <code>+</code> und
<code>-</code></p>
<example>
<indent>
Options Indexes FollowSymLinks<br />
</indent>
</Directory><br />
<br />
<indent>
Options Includes<br />
</indent>
</Directory>
</example>
lediglich <code>Includes</code> gesetzt. Wenn die zweite
<directive>Options</directive>-Anweisung jedoch <code>+</code>-
und <code>-</code>-Zeichen verwenden würde,</p>
<example>
<indent>
Options Indexes FollowSymLinks<br />
</indent>
</Directory><br />
<br />
<indent>
Options +Includes -Indexes<br />
</indent>
</Directory>
</example>
<p>dann würden die Optionen <code>FollowSymLinks</code> und
gesetzt.</p>
<note><title>Anmerkung</title>
<p>Die Verwendung von <code>-IncludesNOEXEC</code> oder
<code>-Includes</code> deaktiviert Server Side Includes unabhängig
von der vorigen Einstellung vollständig.</p>
</note>
<p>Die Voreinstellung ist <code>All</code>, sofern keine anderen Angaben
gemacht wurden.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>Require</name>
<description>Wählt die authentisierten Benutzer aus, die auf eine
Ressource zugreifen können</description>
<syntax>Require <var>Name</var> [<var>Name</var>] ...</syntax>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
<usage>
<p>Die Direktive wählt aus, welche authentisierten Benutzer auf eine
Ressource zugreifen dürfen. Folgende Syntax ist erlaubt:</p>
<dl>
<dt><code>Require user <var>User-ID</var> [<var>User-ID</var>]
...</code></dt>
<dd>Nur die genannten Benutzer dürfen auf die Ressource
zugreifen.</dd>
<dt><code>Require group <var>Gruppenname</var> [<var>Gruppenname</var>]
...</code></dt>
<dd>Nur Benutzer der genannten Gruppen dürfen auf die
Ressource zugreifen.</dd>
<dt><code>Require valid-user</code></dt>
<dd>Alle gültigen Benutzer dürfen auf die Ressource
zugreifen.</dd>
</dl>
<p><directive>Require</directive> muss von den Direktiven
<directive module="mod_authn_core">AuthName</directive> und <directive
module="mod_authn_core">AuthType</directive> sowie Direktiven wie
<directive module="mod_authn_file">AuthUserFile</directive>
und <directive module="mod_authz_groupfile">AuthGroupFile</directive>
(zur Definition von Benutzern und Gruppen) begleitet werden, um
korrekt zu funktionieren. Beispiel:</p>
<example>
AuthType Basic<br />
AuthName "Geschützte Ressource"<br />
Require group admin
</example>
<p>Zugriffskontrollen, die in dieser Form angewandt werden, gelten
für <strong>alle</strong> Methoden. <strong>Dies ist normalerweise
gewünscht.</strong> Wenn Sie Zugriffskontrollen nur auf bestimmte
Methoden anwenden möchten, während andere Methoden
ungeschützt bleiben, dann müssen Sie die
<directive>Require</directive>-Anweisung innerhalb eines
<directive module="core" type="section">Limit</directive>-Abschnitts
platzieren.</p>
</usage>
<seealso><directive module="mod_access_compat">Satisfy</directive></seealso>
<seealso><module>mod_authz_host</module></seealso>
</directivesynopsis>
<directivesynopsis>
<name>RLimitCPU</name>
<description>Begrenzt den CPU-Verbrauch von Prozessen, die von
Apache-Kindprozessen gestartet wurden</description>
<syntax>RLimitCPU <var>Sekunden</var>|max [<var>Sekunden</var>|max]</syntax>
<default>unbestimmt; verwendet die Voreinstellung des Systems</default>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context></contextlist>
<override>All</override>
<usage>
<p>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 <code>max</code> sein. <code>max</code>
zeigt dem Server an, dass das vom Betriebssystem erlaubte Maximum
verwendet werden soll. Das Anheben der maximal erlaubten Ressourcennutzung
erfordert, dass der Server als <code>root</code> läuft, zumindest in
der anfänglichen Startphase.</p>
<p>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.</p>
<p>CPU-Ressourcenbegrenzung wird in Sekunden pro Prozess
ausgedrückt.</p>
</usage>
<seealso><directive module="core">RLimitMEM</directive></seealso>
<seealso><directive module="core">RLimitNPROC</directive></seealso>
</directivesynopsis>
<directivesynopsis>
<name>RLimitMEM</name>
<description>Begrenzt den Speicherverbrauch von Prozessen, die von
Apache-Kindprozessen gestartet wurden</description>
<syntax>RLimitMEM <var>Bytes</var>|max [<var>Bytes</var>|max]</syntax>
<default>unbestimmt; verwendet die Voreinstellung des Systems</default>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context></contextlist>
<override>All</override>
<usage>
<p>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 <code>max</code> sein. <code>max</code>
zeigt dem Server an, dass das vom Betriebssystem erlaubte Maximum
verwendet werden soll. Das Anheben der maximal erlaubten Ressourcennutzung
erfordert, dass der Server als <code>root</code> läuft, zumindest in
der anfänglichen Startphase.</p>
<p>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.</p>
<p>Die Begrenzung des Speicherverbrauchs wird in Bytes pro Prozess
ausgedrückt.</p>
</usage>
<seealso><directive module="core">RLimitCPU</directive></seealso>
<seealso><directive module="core">RLimitNPROC</directive></seealso>
</directivesynopsis>
<directivesynopsis>
<name>RLimitNPROC</name>
<description>Begrenzt die Anzahl der Prozesse, die von Prozessen gestartet
werden können, der ihrerseits von Apache-Kinprozessen gestartet
wurden</description>
<syntax>RLimitNPROC <var>Zahl</var>|max [<var>Zahl</var>|max]</syntax>
<default>unbestimmt; verwendet die Voreinstellung des Systems</default>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context></contextlist>
<override>All</override>
<usage>
<p>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 <code>max</code> sein. <code>max</code>
zeigt dem Server an, dass das vom Betriebssystem erlaubte Maximum
verwendet werden soll. Das Anheben der maximal erlaubten Ressourcennutzung
erfordert, dass der Server als <code>root</code> läuft, zumindest in
der anfänglichen Startphase.</p>
<p>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.</p>
<p>Prozessbegrenzungen steuern die Anzahl der Prozesse pro Benutzer.</p>
<note><title>Anmerkung</title>
<p>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
<strong><code>cannot fork</code></strong>-Meldungen
<transnote><code>kann nicht abspalten</code></transnote> in der
Datei <code>error_log</code>.</p>
</note>
</usage>
<seealso><directive module="core">RLimitMEM</directive></seealso>
<seealso><directive module="core">RLimitCPU</directive></seealso>
</directivesynopsis>
<directivesynopsis>
<name>Satisfy</name>
<description>Zusammenspiel von rechnerbasierter Zugriffskontrolle und
Benutzerauthentisierung</description>
<syntax>Satisfy Any|All</syntax>
<default>Satisfy All</default>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
<compatibility>Wird seit Version 2.0.51 von <directive module="core"
type="section">Limit</directive> und <directive module="core"
type="section">LimitExcept</directive> beeinflusst</compatibility>
<usage>
<p>Verfahrensweise für den Zugriff, falls sowohl <directive
module="mod_access_compat">Allow</directive> als auch <directive
module="mod_authz_core">Require</directive> verwendet werden. Der Parameter kann
entweder <code>All</code> oder <code>Any</code> sein. Die Direktive ist
nur dann nützlich, wenn der Zugriff zu einem bestimmten Bereich
eingeschränkt ist. In diesem Fall verlangt die Voreinstellung
(<code>All</code>), dass der Client die Adressbeschränkung passiert
<em>und</em> eine gültige Benutzerkennung und ein gültiges
Passwort übermittelt. Mit der Auswahl <code>Any</code> 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.</p>
<p>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:</p>
<example>
Require valid-user<br />
Allow from 192.168.1<br />
Satisfy Any
</example>
<p>Seit Version 2.0.51 können
<directive>Satisfy</directive>-Anweisungen durch <directive module="core"
type="section">Limit</directive>- und <directive module="core"
type="section">LimitExcept</directive>-Abschnitte auf bestimmte Methoden
beschränkt werden.</p>
</usage>
<seealso><directive module="mod_access_compat">Allow</directive></seealso>
<seealso><directive module="mod_access_compat">Require</directive></seealso>
</directivesynopsis>
<directivesynopsis>
<name>ScriptInterpreterSource</name>
<description>Methode zur Ermittlung des Interpreters von
CGI-Skripten</description>
<syntax>ScriptInterpreterSource Registry|Registry-Strict|Script</syntax>
<default>ScriptInterpreterSource Script</default>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context></contextlist>
<override>FileInfo</override>
<compatibility>ausschließlich Win32;
Die Option <code>Registry-Strict</code> ist verfügbar seit Apache
2.0.</compatibility>
<usage>
<p>Die Direktive steuert, wie der Apache den Interpreter zur Ausführung
von CGI-Skripten bestimmt. Die Voreinstellung ist <code>Script</code>. Dies
veranlaßt den Apache, den Interpreter zu verwenden, auf den die
Shebang-Zeile (erste Zeile, beginnt mit <code>#!</code>) im Skript zeigt.
Auf Win32-Systemen sieht diese Zeile üblicherweise so aus:</p>
<example>
</example>
<p>oder, wenn <code>perl</code> im Pfad (Umgebungsvariable <code>PATH</code>) liegt,
einfach:</p>
<example>
#!perl
</example>
<p>Die Einstellung <code>ScriptInterpreterSource Registry</code>
veranlaßt eine Suche in <code>HKEY_CLASSES_ROOT</code> der
Windows-Registrierungsdatenbank und verwendet die Endung der Skript-Datei
<code>Shell\ExecCGI\Command</code> oder, falls dieser nicht existiert,
<code>Shell\Open\Command</code> definierte Befehl wird zum Öffnen der
Skript-Datei verwendet. Wenn der Schlüssel zur Dateiendung oder
beide Unterschlüssel fehlen, dann verwendet der Apache die Option
<code>Script</code>.</p>
<note type="warning"><title>Sicherheit</title>
<p>Seien Sie vorsichtig, <code>ScriptInterpreterSource Registry</code> bei
Verzeichnissen zu verwenden, auf die eine <directive
module="mod_alias">ScriptAlias</directive>-Anweisung zeigt, denn der
Apache versucht <strong>jede</strong> Datei innerhalb des Verzeichnisses
auszuführen. Die Einstellung <code>Registry</code> kann
unerwünschte Programmaufrufe bei Dateien verursachen, die
üblicherweise nicht ausgeführt werden. Auf den meisten
Windows-Systemen beispielsweise startet der voreingestellte
Öffnen-Befehl für <code>.htm</code>-Dateien den Microsoft
Internet Explorer, so dass jede HTTP-Anfrage nach einer existierenden
<code>.htm</code>-Datei im Skript-Verzeichnis den Browser im Hintergrund
starten würde. Dies ist eine wirksame Methode, Ihr System binnen
etwa einer Minute zum Absturz zu bringen.</p>
</note>
<p>Die seit Apache 2.0 neue Option <code>Registry-Strict</code>
macht das gleiche wie <code>Registry</code>, verwendet jedoch nur den
Unterschlüssel <code>Shell\ExecCGI\Command</code>. Der Schlüssel
<code>ExecCGI</code> ist gewöhnlich nicht voreingestellt. Er muss
manuell eingerichtet werden und schützt Ihr System so for
versehentlichen Programmaufrufen.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ServerAdmin</name>
<description>E-Mail-Adresse, die der Server in Fehlermeldungen einfügt,
welche an den Client gesendet werden</description>
<syntax>ServerAdmin <var>E-Mail-Adresse</var>|<var>URL</var></syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p><directive>ServerAdmin</directive> legt die Kontaktadresse fest,
die der Server in jede Fehlermeldung einfügt, die er an den
Client zurückschickt. Wenn <code>httpd</code> das übergebene
Argument nicht als URL erkennt, nimmt er an, dess es sich um eine
<var>E-Mail-Adresse</var> handelt und stellt in Hyperlinks
<code>mailto:</code> voran. Es ist jedoch sogar sinnvoll, eine
E-Mail-Adresse zu verwenden, da viele CGI-Skripte davon ausgehen. Wenn Sie
eine URL verwenden möchten, sollten Sie auf einem anderen unter Ihrer
Kontrolle stehenden Server verweisen. Andernfalls können Besucher Sie
im Fehlerfall möglicherweise nicht kontaktieren.</p>
<p>Es kann sich lohnen, hierfür eine reservierte Adresse
anzugeben, z.B.</p>
<example>
ServerAdmin www-admin@foo.example.com
</example>
<p>da Anwender nicht unbedingt erwähnen, dass sie vom Server
sprechen!</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ServerAlias</name>
<description>Alternativer Name für einen Host, der verwendet wird, wenn
Anfragen einem namensbasierten virtuellen Host zugeordnet werden</description>
<syntax>ServerAlias <var>Hostname</var> [<var>Hostname</var>] ...</syntax>
<contextlist><context>virtual host</context></contextlist>
<usage>
<p>Die Direktive <directive>ServerAlias</directive> bestimmt die
alternativen Namen eines Hosts zur Verwendung mit <a
<example>
<VirtualHost *><br />
ServerName server.domain.com<br />
ServerAlias server server2.domain.com server2<br />
# ...<br />
</VirtualHost>
</example>
</usage>
Hosts</a></seealso>
</directivesynopsis>
<directivesynopsis>
<name>ServerName</name>
<description>Rechnername und Port, die der Server dazu verwendet, sich
selbst zu identifizieren</description>
<syntax>ServerName
<var>voll-qualifizierter-Domainname</var>[:<var>port</var>]</syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<compatibility>Diese Direktive löst in Version 2.0 die
Funktionalität der Direktive <directive>Port</directive> aus
Version 1.3 ab.</compatibility>
<usage>
<p>Die Direktive <directive>ServerName</directive> 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
Webserver so identifizieren möchten, sollten Sie die folgende
Anweisung verwenden:</p>
<example>
ServerName www.example.com:80
</example>
<p>Wenn kein <directive>ServerName</directive> angegeben wurde,
dann versucht der Server den Rechnernamen mittels eines Reverse-Lookup
herzuleiten. Wenn kein Port in der
<directive>ServerName</directive>-Anweisung angegeben wurde, dann
verwendet der Server den Port der eingegangenen Anfrage. Für eine
optimale Zuverlässigkeit und Berechenbarkeit sollten Sie einen
eindeutigen Rechnernamen und Port angeben, in dem Sie die Direktive
<directive>ServerName</directive> verwenden.</p>
virtuelle Hosts</a> verwenden, gibt <directive>ServerName</directive>
innerhalb eines <directive type="section"
module="core">VirtualHost</directive>-Abschnitts an, welcher
Hostname im <code>Host:</code>-Header der Anfrage auftauchen muss,
damit sie diesem virtuellen Host zugeordnet wird.</p>
<p>Lesen Sie bitte die Beschreibung der Direktiven <directive
module="core">UseCanonicalName</directive> und <directive module="core"
>UseCanonicalPhysicalPort</directive> für Einstellungen, die
bestimmen, ob selbstreferenzierende URLs (z.B. vom Modul
<module>mod_dir</module>) auf den angegebenen Port zeigen oder auf die
Portnummern die in der Anfrage des Clients angegeben ist.</p>
</usage>
Apache</a></seealso>
Hosts</a></seealso>
<seealso><directive module="core">UseCanonicalName</directive></seealso>
<seealso><directive module="core">UseCanonicalPhysicalPort</directive></seealso>
<seealso><directive module="core">NameVirtualHost</directive></seealso>
<seealso><directive module="core">ServerAlias</directive></seealso>
</directivesynopsis>
<directivesynopsis>
<name>ServerPath</name>
<description>Veralteter URL-Pfad für einen namensbasierten
virtuellen Host, auf den von einem inkompatiblen Browser zugegriffen
wird</description>
<syntax>ServerPath <var>URL-Pfad</var></syntax>
<contextlist><context>virtual host</context></contextlist>
<usage>
<p>Die Direktive <directive>ServerPath</directive> legt den
veralteten <transnote>Gemeint ist eigentlich "Altlast" aufgrund
antiquierter Clients.</transnote> URL-Pfad eines Hosts zur Verwendung mit
</usage>
Hosts</a></seealso>
</directivesynopsis>
<directivesynopsis>
<name>ServerRoot</name>
<description>Basisverzeichnis der Serverinstallation</description>
<syntax>ServerRoot <var>Verzeichnis</var></syntax>
<contextlist><context>server config</context></contextlist>
<usage>
<p>Die Direktive <directive>ServerRoot</directive> bestimmt das
Verzeichnis, in dem der Server installiert ist. Üblicherweise
enthält es die Unterverzeichnisse <code>conf/</code> und
<directive module="core">Include</directive> oder <directive
module="mod_so">LoadModule</directive>) werden relativ zu diesem
Verzeichnis betrachtet.</p>
<example><title>Beispiel</title>
</example>
</usage>
<code>-d</code></a></seealso>
für Informationen, wie die Rechte auf das <directive
>ServerRoot</directive>-Verzeichnis richtig gesetzt werden</seealso>
</directivesynopsis>
<directivesynopsis>
<name>ServerSignature</name>
<description>Konfiguriert die Fußzeile von servergenerierten
Dokumenten</description>
<syntax>ServerSignature On|Off|EMail</syntax>
<default>ServerSignature Off</default>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<usage>
<p>Die Direktive <directive>ServerSignature</directive> ermöglicht
die Gestaltung einer unter servergenerierten Dokumenten (z.B.
Fehlerdokumente, FTP-Verzeichnislisten von <module>mod_proxy</module>,
<module>mod_info</module>-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.</p>
<p>Die (Vor-)Einstellung <code>Off</code> unterdrückt die
Fußzeile (und ist damit kompatibel zum Verhalten des Apache 1.2 und
früher). Die Einstellung <code>On</code> fügt schlicht eine
Zeile mit der Versionsnummer des Servers und dem Servernamen (<directive
module="core">ServerName</directive>) des bedienenden virtuellen Hosts an.
Die Einstellung <code>EMail</code> erstellt zusätzlich einen
"mailto:"-Verweis zum Serveradministrator (<directive
module="core">ServerAdmin</directive>) des referenzierten Dokuments.</p>
<p>Ab Version 2.0.44 werden die Details der angegebenen Versionsnummer des
Servers von der Direktive <directive
module="core">ServerTokens</directive> kontrolliert.</p>
</usage>
<seealso><directive module="core">ServerTokens</directive></seealso>
</directivesynopsis>
<directivesynopsis>
<name>ServerTokens</name>
<description>Konfiguriert den HTTP-Response-Header
<code>Server</code></description>
<syntax>ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full</syntax>
<default>ServerTokens Full</default>
<contextlist><context>server config</context></contextlist>
<usage>
<p>die Direktive steuert, ob der Response-Header <code>Server</code>,
der an den Client zurückgesendet wird, eine Beschreibung des
allgemeinen Betriesbsystemtyps des Servers wie auch Informationen
über einkompilierte Module enthält.</p>
<dl>
<dt><code>ServerTokens Prod[uctOnly]</code></dt>
Apache</code></dd>
<dt><code>ServerTokens Major</code></dt>
Apache/2</code></dd>
<dt><code>ServerTokens Minor</code></dt>
<dt><code>ServerTokens Min[imal]</code></dt>
<dt><code>ServerTokens OS</code></dt>
(Unix)</code></dd>
<dt><code>ServerTokens Full</code> (oder nicht angegeben)</dt>
</dl>
<p>Diese Einstellung gilt für den gesamten Server und kann nicht
auf Virtual-Host-Basis aktiviert oder deaktiviert werden.</p>
<p>Ab Version 2.0.44 steuert diese Direktive auch die Informationen, die
durch die Direktive <directive module="core">ServerSignature</directive>
angeboten werden.</p>
</usage>
<seealso><directive module="core">ServerSignature</directive></seealso>
</directivesynopsis>
<directivesynopsis>
<name>SetHandler</name>
<description>Erzwingt die Verarbeitung aller passenden Dateien durch
einen Handler</description>
<syntax>SetHandler <var>Handlername</var>|None</syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>FileInfo</override>
<compatibility>Seit Apache 2.0 im Core</compatibility>
<usage>
<p>Wenn die Direktive innerhalb einer <code>.htaccess</code>-Datei
oder in einem <directive type="section"
module="core">Directory</directive>- oder
<directive type="section" module="core">Location</directive>-Abschnitt
angegeben wird, erzwingt sie, dass alle entsprechenden Dateien von dem
durch <var>Handlername</var> angegebenen <a
href="/handler.html">Handler</a> 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 <code>.htaccess</code>-Datei in
dem Verzeichnis schreiben:</p>
<example>
SetHandler imap-file
</example>
<p>Noch ein Beispiel: wenn Sie den Server immer, wenn die URL
Statusbericht anzeigen lassen möchten, dann können
<example>
<Location /status><br />
<indent>
SetHandler server-status<br />
</indent>
</Location>
</example>
<p>Sie können eine zuvor definierte
<directive>SetHandler</directive>-Anweisung aufheben, indem Sie den Wert
<code>None</code> verwenden.</p>
<p><strong>Hinweis:</strong> SetHandler setzt die Standard-Handler
außer Kraft und unterdrückt gewohnte Verhaltensweisen, wie
beispielsweise die Behandlung von URLs, die auf einen Schrägstrich
(/) enden als Verzeichnisse oder (die Auslieferung von) Index-Dateien.</p>
</usage>
<seealso><directive module="mod_mime">AddHandler</directive></seealso>
</directivesynopsis>
<directivesynopsis>
<name>SetInputFilter</name>
<description>Bestimmt die Filter, die Client-Anfragen und POST-Eingaben
verarbeiten</description>
<syntax>SetInputFilter <var>Filter</var>[;<var>Filter</var>...]</syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>FileInfo</override>
<usage>
<p>Die Direktive <directive>SetInputFilter</directive> 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
<directive module="mod_mime">AddInputFilter</directive>.</p>
<p>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.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>SetOutputFilter</name>
<description>Bestimmt die Filter, die Antworten des Servers verarbeiten</description>
<syntax>SetOutputFilter <var>Filter</var>[;<var>Filter</var>...]</syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>FileInfo</override>
<usage>
<p>Die Direktive <directive>SetOutputFilter</directive> 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
<directive module="mod_mime">AddOutputFilter</directive>.</p>
<p>Die folgende Konfiguration verarbeitet zum Beispiel alle Dateien
<example>
<indent>
SetOutputFilter INCLUDES<br />
</indent>
</Directory>
</example>
<p>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.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>TimeOut</name>
<description>Zeitspanne, die der Server auf verschiedene Ereignisse wartet,
bevor er die Anfrage abbricht</description>
<syntax>TimeOut <var>Sekunden</var></syntax>
<default>TimeOut 60</default>
<contextlist><context>server config</context></contextlist>
<usage>
<p>Die Direktive <directive>TimeOut</directive> definiert derzeit die
Zeitspanne, die der Apache auf drei Dinge wartet:</p>
<ol>
<li>Die gesamte Zeispanne, die benötigt wird, um eine GET-Anfrage
zu empfangen.</li>
<li>Die Zeitspanne zwischen dem Empfang von TCP-Paketen einer
POST- oder PUT-Anfrage.</li>
<li>Die Zeitspanne zwischen ACKs bei der Übermittlung der
TCP-Pakete der Antwort.</li>
</ol>
<p>Wir haben vor, diese Zeitspannen in Zukunft separat konfigurierbar zu
machen. Vor Version 1.2 war der Zeitgeber auf 1200 voreingestellt, wurde
dann aber auf 300 herabgesetzt, was immer noch weit mehr ist, als in den
meisten Situationen benötigt wird. Die Voreinstellung wurde nicht
weiter herabgesetzt, da gelegentlich noch Stellen im Code existieren
können, wo der Zeitgeber nicht zurückgesetzt wird, wenn ein
Paket verschickt wird. Seit Apache 2.4 ist die Voreinstellung 60.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>TraceEnable</name>
<description>Legt das Verhalten von <code>TRACE</code>-Anfragen fest</description>
<syntax>TraceEnable <var>[on|off|extended]</var></syntax>
<default>TraceEnable on</default>
<contextlist><context>server config</context></contextlist>
<compatibility>Verfügbar ab Apache 1.3.34 und 2.0.55</compatibility>
<usage>
<p>Diese Direktive beeinflusst das Verhalten von <code>TRACE</code> sowohl
für den Server selbst als auch <module>mod_proxy</module>. Die
Voreinstellung <code>TraceEnable on</code> erlaubt
<code>TRACE</code>-Anfragen gemäß RFC 2616. Dort werden
nur Anfragen ohne Datenteil zugelassen. <code>TraceEnable off</code>
sorgt dafür, dass der Serverkern und <module>mod_proxy</module> den
Fehler <code>405</code> (Zugriffsmethode nicht erlaubt) an den Client
senden.</p>
<p>Zu Test- und Diagnosezwecken können Sie auch
nicht-standardkonforme Anfragen mit Datenteil erlauben, indem Sie die
Direktive <code>TraceEnable extended</code> verwenden. Der Server (als
Ursprungsserver) beschränkt den Anfrageinhalt auf 64k. (Wenn
<code>Transfer-Encoding: chunked</code> benutzt wird, können
weitere 8k für die Chunk-Kopfzeilen verwendet werden.) Der
Server selbst reflektiert dann die vollständigen HTTP- und
Chunk-Kopfzeilen in seiner Antwort. Die Einschränkung auf 64k gilt
nicht, wenn der Server als Proxy arbeitet.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>UseCanonicalName</name>
<description>Bestimmt, wie der Server seinen eigenen Namen und Port
ermittelt</description>
<syntax>UseCanonicalName On|Off|DNS</syntax>
<default>UseCanonicalName Off</default>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context></contextlist>
<usage>
<p>In vielen Situationen muss der Apache eine
Server zurück verweist -- zusammenbauen. Bei <code>UseCanonicalName
On</code> verwendet der Apache den Hostnamen und Port, der in der
<directive module="core">ServerName</directive>-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 <code>SERVER_NAME</code> und <code>SERVER_PORT</code>
verwendet.</p>
<p>Bei <code>UseCanonicalName Off</code> 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 <a
href="/vhosts/name-based.html">namensbasierten virtuellen Hosts</a>
verwendet werden, und sie sind mit den gleichen Clients verfügbar
<transnote>, die auch in der Lage sind, auf namensbasierte virtuelle Hosts
Die CGI-Variablen <code>SERVER_NAME</code> und <code>SERVER_PORT</code>
werden ebenfalls aus den vom Client angeboten Werten erstellt.</p>
<p>Ein Intranet-Server, auf den Anwender mit kurzen Namen wie
<code>www</code> zugreifen, ist ein Beispiel, wo dies sinnvoll sein kann.
Sie werden bemerken, dass der Apache den Benutzer auf
Kurznamen und eine URL, die einem Verzeichnis entspricht, ohne
abschließenden Schrägstrich eingibt, wie z.B.
bewirkt dies, dass der Benutzer sich zweimal identifizieren muss
(einmal für <code>www</code> und noch einmal für
href="http://httpd.apache.org/docs/misc/FAQ.html#prompted-twice">die
FAQ zu diesem Thema</a>). Wenn <directive>UseCanonicalName</directive>
jedoch auf <code>Off</code> gesetzt ist, denn wird der Apache zu
<p>Es existiert noch eine dritte Option, <code>UseCanonicalName DNS</code>,
die für den Betrieb von IP-basierten Massen-Virtual-Hosts gedacht ist,
um antiquierte Clients zu unterstützen, die keinen
<code>Host:</code>-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.</p>
<note type="warning"><title>Warnung</title>
<p>Wenn CGI-Skripte Vermutungen aufgrund des Wertes von
<code>SERVER_NAME</code> 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 <code>SERVER_NAME</code> jedoch lediglich dazu verwendet,
selbstreferenzierende URLs zu erstellen, sollte das gerade noch
in Ordnung sein.</p>
</note>
</usage>
<seealso><directive module="core">ServerName</directive></seealso>
<seealso><directive module="mpm_common">Listen</directive></seealso>
</directivesynopsis>
<directivesynopsis>
<name>UseCanonicalPhysicalPort</name>
<description>Bestimmt, wie der Server seinen eigenen Namen und Port
ermittelt</description>
<syntax>UseCanonicalPhysicalPort On|Off</syntax>
<default>UseCanonicalPhysicalPort Off</default>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context></contextlist>
<usage>
<p>In vielen Situationen muss der Apache eine
den selben Server zurück verweist. Wenn der Apache für die
<directive module="core">UseCanonicalName</directive>-Direktive den Port
bestimmt, wird mit <code>UseCanonicalPhysicalPort On</code> die
tatsächlich für die Anfrage verwendete physische Portnummer
in Betracht gezogen. Mit <code>UseCanonicalPhysicalPort Off</code>
verläßt sich der Apache nur auf die Konfiguration, um eine
gültige Portnummer zu bestimmen und läßt die
physische Portnummer außer acht.</p>
<note><title>Hinweis</title>
<p>Wenn der physische Port verwendet wird, ist die Reihenfolge wie
folgt:<br /><br />
<code>UseCanonicalName On</code></p>
<ul>
<li>Der in <code>Servername</code> angegebene Port</li>
<li>Der physische Port</li>
<li>Der Standardport</li>
</ul>
<code>UseCanonicalName Off | DNS</code>
<ul>
<li>Der Port, der aus dem <code>Host:</code>-Header gewonnen wurde</li>
<li>Der physische Port</li>
<li>Der in <code>Servername</code> angegebene Port</li>
<li>Der Standardport</li>
</ul>
<p>Bei <code>UseCanonicalPhysicalPort Off</code> werden die physischen
Ports aus der Suchreihe entfernt.</p>
</note>
</usage>
<seealso><directive module="core">UseCanonicalName</directive></seealso>
<seealso><directive module="core">ServerName</directive></seealso>
<seealso><directive module="mpm_common">Listen</directive></seealso>
</directivesynopsis>
<directivesynopsis type="section">
<name>VirtualHost</name>
<description>Enthält Direktiven, die nur auf bestimmte Hostnamen oder
IP-Adressen angewendet werden</description>
<syntax><VirtualHost
<var>Adresse</var>[:<var>Port</var>] [<var>Adresse</var>[:<var>Port</var>]]
...> ... </VirtualHost></syntax>
<contextlist><context>server config</context></contextlist>
<usage>
<p><directive type="section">VirtualHost</directive> und
<code></VirtualHost></code> werden dazu verwendet, eine Gruppe
von Direktiven zusammenzufassen, die nur auf einen bestimmten virtuellen
Host angewendet werden. Jede Direktive, die im Virtual-Host-Kontext
zulässig ist, kann verwendet werden. Wenn der Server eine Anfrage
für ein bestimmtes Dokument eines bestimmten virtuellen Hosts
empfängt, dann benutzt er die im
<directive type="section">VirtualHost</directive>-Container enthaltenen
Konfigurationsanweisungen. <var>Adresse</var> kann sein:</p>
<ul>
<li>Die IP-Adresse des virtuellen Hosts.</li>
<li>Ein voll qualifizierter Domainname für die IP-Adresse des
virtuellen Hosts.</li>
<li>Das Zeichen <code>*</code>, welches nur in Kombination mit
<code>NameVirtualHost *</code> verwendet wird, um allen IP-Adressen
zu entsprechen.</li>
<li>Die Zeichenkette <code>_default_</code>, die nur mit IP-basierten
virtuellen Hosts verwendet wird, um nicht zugewiesene IP-Adressen
aufzufangen.</li>
</ul>
<example><title>Beispiel</title>
<VirtualHost 10.1.2.3><br />
<indent>
ServerAdmin webmaster@host.foo.com<br />
ServerName host.foo.com<br />
</indent>
</VirtualHost>
</example>
<p>IPv6-Adressen müssen in eckigen Klammern angegeben werden, da die
optionale Portnummer sonst nicht erkannt werden kann. Hier ein
IPv6-Beispiel:</p>
<example>
<VirtualHost [2001:db8::a00:20ff:fea7:ccea]><br />
<indent>
ServerAdmin webmaster@host.example.com<br />
ServerName host.example.com<br />
</indent>
</VirtualHost>
</example>
<p>Jeder virtuelle Host muss einer anderen IP-Adresse, einem anderen Port
oder einem anderen Hostnamen für den Server entsprechen. Im ersten
Fall muss die Servermaschine so eingerichtet sein, dass sie IP-Pakete
für mehrere Adressen akzeptiert. (Wenn der Rechner nicht mehrere
Netzwerkkarten besitzt, kann dies mit dem Befehl <code>ifconfig
alias</code> durchgeführt werden -- sofern Ihr Betriebssystem das
unterstützt).</p>
<note><title>Anmerkung</title>
<p>Die Verwendung von <directive type="section">VirtualHost</directive>
beeinflusst <strong>nicht</strong>, an welchen Adressen der Apache
lauscht. Sie müssen mit <directive
module="mpm_common">Listen</directive> sicherstellen, dass der Apache
an der richtigen Adresse lauscht.</p>
</note>
<p>Bei der Verwendung IP-basierter virtuellen Hosts kann der spezielle
Name <code>_default_</code> benutzt werden. In diesem Fall weist
der Apache jede IP-Adresse diesem virtuellen Host zu, die nicht explizit in
einem anderen virtuellen Host angegeben ist. Falls kein virtueller Host
<code>_default_</code> 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 <directive
module="core">NameVirtualHost</directive>-Anweisung passt, weder den
"Hauptserver" noch den virtuellen Host <code>_default_</code> verwendet.
Lesen Sie für weitere Details die Dokumentation zu <a
<p>Sie können einen speziellen <code>:Port</code> angeben,
um den entsprechenden Port zu wechseln. Falls nicht angegeben, wird
er auf den gleichen Port voreingestellt, wie die letzte
<directive module="mpm_common">Listen</directive>-Anweisung des
Hauptservers. Sie können auch <code>:*</code> angeben, um alle
Ports dieser Adresse zu akzeptieren. (Dies wird zusammen mit
<code>_default_</code> empfohlen.)</p>
<note type="warning"><title>Sicherheit</title>
<p>Lesen Sie das Dokument <a
href="/misc/security_tips.html">Sicherheitshinweise</a> 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.</p>
</note>
</usage>
Hosts</a></seealso>
Apache</a></seealso>
der Apache verwendet</a></seealso>
<Location> und <Files> arbeiten</a> für eine
Erläuterung, wie diese verschiedenen Abschnitte miteinander
kombiniert werden, wenn eine Anfrage empfangen wird</seealso>
</directivesynopsis>
</modulesynopsis>