mirror of
https://github.com/apache/httpd.git
synced 2025-05-30 01:07:09 +03:00
46d7e81888
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@558837 13f79535-47bb-0310-9956-ffa450edef68
3300 lines
139 KiB
XML
3300 lines
139 KiB
XML
<?xml version="1.0"?>
|
|
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
|
|
<?xml-stylesheet type="text/xsl" href="../style/manual.de.xsl"?>
|
|
<!-- English Revision: 167959:558694 (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
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
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>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
|
|
Verzeichnis zeigt, welches lediglich eine Datei <code>here.html</code>
|
|
enthält. Dann wird bei Anfragen nach
|
|
<code>/test/here.html/more</code> und
|
|
<code>/test/nothere.html/more</code> beides Mal <code>/more</code>
|
|
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
|
|
<code>/test/here.html/more</code> im obigen Beispiel, den Fehler
|
|
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
|
|
obige Beispiel <code>/test/here.html/more</code> wird akzeptiert,
|
|
wenn <code>/test/here.html</code> auf eine gültige Datei
|
|
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,
|
|
wie z.B. <a href="mod_cgi.html">cgi-script</a> und
|
|
<a href="mod_isapi.html">isapi-handler</a>, sind im Allgemeinen darauf
|
|
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
|
|
<a href="../filter.html">Filter</a> wie <a
|
|
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
|
|
<code>/usr/local/web/index.html</code> wird der Server
|
|
<code>/.acl</code>, <code>/usr/.acl</code>,
|
|
<code>/usr/local/.acl</code> und <code>/usr/local/web/.acl</code>
|
|
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>
|
|
<seealso><a href="../configuring.html">Konfigurationsdateien</a></seealso>
|
|
<seealso><a href="../howto/htaccess.html">.htaccess-Dateien</a></seealso>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>AddDefaultCharset</name>
|
|
<description>Standard-Charset-Parameter, der bei Antworten vom Content-Type
|
|
<code>text/plain</code> oder <code>text/html</code> hinzugefügt wird
|
|
</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
|
|
<code>text/plain</code> oder <code>text/html</code> ist. Dies sollte jedes
|
|
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
|
|
MIME-Type der Antwort einen bestimmten Ausgabe-<a href="../filter.html"
|
|
>Filter</a>.</p>
|
|
|
|
<p>Das folgende Beispiel verwendet den Filter <code>DEFLATE</code>,
|
|
der von <module>mod_deflate</module> angeboten wird. Er komprimiert
|
|
jede Ausgabe, die als <code>text/html</code> oder <code>text/plain</code>
|
|
gekennzeichnet ist, (gleichgültig, ob statisch oder dynamisch)
|
|
bevor sie an den Client gesendet wird.</p>
|
|
|
|
<example>
|
|
AddOutputFilterByType DEFLATE text/html text/plain
|
|
</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
|
|
Skriptausgaben, die als <code>text/html</code> gekennzeichnet
|
|
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 />
|
|
AddOutputFilterByType INCLUDES;DEFLATE text/html<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 MIME-Type 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>
|
|
<seealso><a href="../filter.html">Filter</a></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 All</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,
|
|
die den <a href="directive-dict.html#Context">Kontext</a>
|
|
.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_authn_dbm">AuthDBMGroupFile</directive>,
|
|
<directive module="mod_authn_dbm">AuthDBMUserFile</directive>,
|
|
<directive module="mod_authz_groupfile">AuthGroupFile</directive>,
|
|
<directive module="core">AuthName</directive>,
|
|
<directive module="core">AuthType</directive>, <directive
|
|
module="mod_authn_file">AuthUserFile</directive>, <directive
|
|
module="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>).</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>, <directive
|
|
module="mod_autoindex">FancyIndexing</directive>, <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_authz_host">Allow</directive>, <directive
|
|
module="mod_authz_host">Deny</directive> und <directive
|
|
module="mod_authz_host">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>
|
|
<seealso><a href="../configuring.html">Konfigurationsdateien</a></seealso>
|
|
<seealso><a href="../howto/htaccess.html">.htaccess-Dateien</a></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
|
|
href="../howto/auth.html">Authentisierung, Autorisierung und
|
|
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>
|
|
<seealso><a href="../howto/auth.html">Authentisierung, Autorisierung und
|
|
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
|
|
von <code>CGIMapExtension sys:\foo.nlm .foo</code>, dass
|
|
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. RFC2068
|
|
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>
|
|
<default>DefaultType text/plain</default>
|
|
<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 MIME-Type-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>
|
|
DefaultType image/gif
|
|
</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 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
|
|
/*/public_html></code> nicht auf <code>/home/user/public_html</code>,
|
|
<code><Directory /home/*/public_html></code> jedoch tut es.
|
|
Beispiel:</p>
|
|
|
|
<example>
|
|
<Directory /usr/local/httpd/htdocs><br />
|
|
<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 reguläre Ausdrücke 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>
|
|
|
|
<p>Beim Zugriff auf das Dokument <code>/home/web/dir/doc.html</code>
|
|
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
|
|
<code>/home/.htaccess</code>, <code>/home/web/.htaccess</code> und
|
|
<code>/home/web/dir/.htaccess</code> der Reihe nach an.</li>
|
|
</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
|
|
der reguläre Ausdruck mit <code>/home/abc/public_html/abc</code>
|
|
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
|
|
href="../misc/security_tips.html">Sicherheitshinweisen</a>.</strong></p>
|
|
|
|
<p>Die Verzeichnisabschnitte erscheinen in der Datei
|
|
<code>httpd.conf</code>. <directive
|
|
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>
|
|
<seealso><a href="../sections.html">Wie die Abschnitte <Directory>,
|
|
<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 regulärer Ausdruck.
|
|
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>
|
|
<seealso><a href="../sections.html">Wie die Abschnitte <Directory>,
|
|
<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>
|
|
<default>DocumentRoot /usr/local/apache/htdocs</default>
|
|
<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>
|
|
DocumentRoot /usr/web
|
|
</example>
|
|
|
|
<p>Damit bezieht sich ein Zugriff auf
|
|
<code>http://www.my.host.com/index.html</code> auf
|
|
<code>/usr/web/index.html</code>. Wenn das <var>Verzeichnis</var> nicht
|
|
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>
|
|
<seealso><a href="../urlmapping.html">URLs auf das Dateisystem
|
|
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
|
|
module="core">DocumentRoot</directive> (z.B. NFS oder SMB) ist der
|
|
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>
|
|
</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>
|
|
</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 404 /cgi-bin/falsche_urls.pl<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>
|
|
ErrorDocument 404 /cgi-bin/bad_urls.pl<br /><br />
|
|
<Directory /web/docs><br />
|
|
<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
|
|
href="http://support.microsoft.com/default.aspx?scid=kb;en-us;Q294807"
|
|
>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>
|
|
|
|
<seealso><a href="../custom-error.html">Dokumentation zu individuellen
|
|
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>
|
|
<default>ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows and
|
|
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>
|
|
ErrorLog /var/log/httpd/error_log
|
|
</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>
|
|
ErrorLog "|/usr/local/bin/httpd_errors"
|
|
</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>
|
|
<seealso><a href="../logs.html">Apache-Log-Dateien</a></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 reguläre Ausdrücke 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>
|
|
<seealso><a href="../sections.html">Wie die Abschnitte <Directory>,
|
|
<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 reguläre Ausdrücke.
|
|
Beispielsweise würde</p>
|
|
|
|
<example>
|
|
<FilesMatch "\.(gif|jpe?g|png)$">
|
|
</example>
|
|
|
|
<p>auf die gebräuchlichsten Grafikformate im Internet passen.</p>
|
|
</usage>
|
|
|
|
<seealso><a href="../sections.html">Wie die Abschnitte <Directory>,
|
|
<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>
|
|
ForceType image/gif
|
|
</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>
|
|
# erzwinge image/gif für alle Dateien:<br />
|
|
<Location /images><br />
|
|
<indent>
|
|
ForceType image/gif<br />
|
|
</indent>
|
|
</Location><br />
|
|
<br />
|
|
# hier jedoch normale MIME-Type-Zuordnungen:<br />
|
|
<Location /images/mixed><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
|
|
<code>REMOTE_HOST</code> an CGIs/SSIs übergeben) werden könnnen.
|
|
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>
|
|
LoadModule rewrite_module modules/mod_rewrite.so<br />
|
|
LoadModule proxy_module modules/libproxy.so<br />
|
|
</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
|
|
<code>mod_rewrite.c</code> ist der Dateiname. Wenn ein Modul aus mehreren
|
|
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>
|
|
Include /usr/local/apache2/conf/ssl.conf<br />
|
|
Include /usr/local/apache2/conf/vhosts/*.conf
|
|
</example>
|
|
|
|
<p>Oder Sie geben Pfade relativ zu Ihrem <directive
|
|
module="core">ServerRoot</directive>-Verzeichnis an:</p>
|
|
|
|
<example>
|
|
Include conf/ssl.conf<br />
|
|
Include conf/vhosts/*.conf
|
|
</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 />
|
|
Processing config file: /usr/local/apache2/conf/ssl.conf<br />
|
|
Processing config file: /usr/local/apache2/conf/vhosts/vhost1.conf<br />
|
|
Processing config file: /usr/local/apache2/conf/vhosts/vhost2.conf<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>
|
|
<p>Die Keep-Alive-Erweiterung von HTTP/1.0 und die
|
|
HTTP/1.1-Funktionalität persistenter Verbindungen unterstützt
|
|
langlebige HTTP-Sitzungen, die es erlauben, mehrere Anfragen über
|
|
die gleich TCP-Verbindung zu senden. In einigen Fällen wurde eine
|
|
Beschleunigung der Wartezeiten von beinahe 50% für HTML-Dokumente
|
|
mit vielen Bildern festgestellt. Um Keep-Alive-Verbindungen zu aktivieren,
|
|
setzen Sie <code>KeepAlive On</code>.</p>
|
|
|
|
<p>Bei HTTP/1.0-Clients werden Keep-Alive-Verbindungen nur dann verwendet,
|
|
wenn sie vom Client eigens angefordert werden. Desweiteren können
|
|
Keep-Alive-Verbindungen bei einem HTTP/1.0-Client nur dann verwendet
|
|
werden, wenn die Länge des Inhalts im Voraus bekannt ist. Dies
|
|
impliziert, dass dynamische Inhalte wie CGI-Ausgaben, SSI-Seiten und
|
|
servergenerierte Verzeichnisauflistungen im Allgemeinen keine
|
|
Keep-Alive-Verbindungen mit HTTP/1.0-Clients verwenden. Bei
|
|
HTTP/1.1-Clients sind Keep-Alive-Verbindungen Voreinstellung, solange
|
|
nichts anderes angegeben ist. Wenn der Client es anfordert, wird
|
|
Chunked-Encoding verwendet, um Inhalte mit unbekannter Länge
|
|
über persistente Verbindungen zu senden.</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 immmer 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
|
|
sie angefordert worden. <module>mod_dir</module> z.B. verwendet
|
|
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
|
|
<code>schema://servername/path</code>. Das Präfix muss angegeben
|
|
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 reguläre Ausdrücke können ebenfalls
|
|
verwendet werden, indem das Zeichen <code>~</code> hinzugefügt
|
|
wird. Beispielsweise würde</p>
|
|
|
|
<example>
|
|
<Location ~ "/(extra|special)/data">
|
|
</example>
|
|
|
|
<p>auf URLs passen, welche die Zeichenfolge <code>/extra/data</code>
|
|
oder <code>/special/data</code> enthalten. Die Direktive <directive
|
|
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
|
|
nur von Browsern aus <code>foo.com</code> zuzulassen, könnten Sie
|
|
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
|
|
(<em>d.h.</em> <code>/home///foo</code> ist das gleiche wie
|
|
<code>/home/foo</code>). Im URL-Raum ist dies nicht notwendigerweise
|
|
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
|
|
beispielsweise <code><Location /abc/def></code> an und die
|
|
Anfrage lautet auf <code>/abc//def</code>, dann greift die Anweisung.</p>
|
|
</note>
|
|
</usage>
|
|
<seealso><a href="../sections.html">Wie die Abschnitte <Directory>,
|
|
<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 reguläre Ausdrücke als Argument anstelle
|
|
einer einfachen Zeichenkette. Beispielsweise würde</p>
|
|
|
|
<example>
|
|
<LocationMatch "/(extra|special)/data">
|
|
</example>
|
|
|
|
<p>auf URLs passen, welche die Zeichenfolge <code>/extra/data</code>
|
|
oder <code>/special/data</code> enthalten.</p>
|
|
</usage>
|
|
|
|
<seealso><a href="../sections.html">Wie die Abschnitte <Directory>,
|
|
<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
|
|
Min/MaxSpareServers erhöhen)"</transnote></td>
|
|
</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
|
|
allen höheren Leveln ebenso angezeigt. <em>Z.B.:</em> Wenn
|
|
<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,
|
|
wenn Sie <a href="../vhosts/">namensbasierte virtuelle Hosts</a>
|
|
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>
|
|
<seealso><a href="../vhosts/">Dokumentation zu virtuellen Hosts</a></seealso>
|
|
</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
|
|
Indexdatei (<em>z.B.</em> <code>index.html</code>) befindet, dann liefert
|
|
<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
|
|
href="../content-negotiation.html">Content-Negotiation</a>).</dd>
|
|
|
|
<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>
|
|
|
|
<p>So wird zum Beispiel ohne die Zeichen <code>+</code> und
|
|
<code>-</code></p>
|
|
|
|
<example>
|
|
<Directory /web/docs><br />
|
|
<indent>
|
|
Options Indexes FollowSymLinks<br />
|
|
</indent>
|
|
</Directory><br />
|
|
<br />
|
|
<Directory /web/docs/spec><br />
|
|
<indent>
|
|
Options Includes<br />
|
|
</indent>
|
|
</Directory>
|
|
</example>
|
|
|
|
<p>für das Verzeichnis <code>/web/docs/spec</code> wird jetzt
|
|
lediglich <code>Includes</code> gesetzt. Wenn die zweite
|
|
<directive>Options</directive>-Anweisung jedoch <code>+</code>-
|
|
und <code>-</code>-Zeichen verwenden würde,</p>
|
|
|
|
<example>
|
|
<Directory /web/docs><br />
|
|
<indent>
|
|
Options Indexes FollowSymLinks<br />
|
|
</indent>
|
|
</Directory><br />
|
|
<br />
|
|
<Directory /web/docs/spec><br />
|
|
<indent>
|
|
Options +Includes -Indexes<br />
|
|
</indent>
|
|
</Directory>
|
|
</example>
|
|
|
|
<p>dann würden die Optionen <code>FollowSymLinks</code> und
|
|
<code>Includes</code> für das Verzeichnis <code>/web/docs/spec</code>
|
|
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="core">AuthName</directive> und <directive
|
|
module="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 />
|
|
AuthUserFile /web/users<br />
|
|
AuthGroupFile /web/groups<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="core">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_authz_host">Allow</directive> als auch <directive
|
|
module="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
|
|
durch Benutzername/Passwort <em>und</em> Clientrechner-Adressen
|
|
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_authz_host">Allow</directive></seealso>
|
|
<seealso><directive module="core">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>
|
|
#!C:/Perl/bin/perl.exe
|
|
</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
|
|
(z.B. <code>.pl</code>) als Suchargument. Der durch den Unterschlüssel
|
|
<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
|
|
href="../vhosts/name-based.html">namensbasierten virtuellen Hosts</a>.</p>
|
|
|
|
<example>
|
|
<VirtualHost *><br />
|
|
ServerName server.domain.com<br />
|
|
ServerAlias server server2.domain.com server2<br />
|
|
# ...<br />
|
|
</VirtualHost>
|
|
</example>
|
|
</usage>
|
|
<seealso><a href="../vhosts/">Apache-Dokumentation zu virtuellen
|
|
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
|
|
beherbergt, <code>simple.example.com</code> lautet, die Maschine jedoch
|
|
auch einen DNS-Alias <code>www.example.com</code> besitzt und Sie den
|
|
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>
|
|
|
|
<p>Wenn Sie <a href="../vhosts/name-based.html">namensbasierte
|
|
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 Direktive <directive
|
|
module="core">UseCanonicalName</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>
|
|
|
|
<seealso><a href="../dns-caveats.html">Probleme bezüglich DNS und
|
|
Apache</a></seealso>
|
|
<seealso><a href="../vhosts/">Apache-Dokumentation zu virtuellen
|
|
Hosts</a></seealso>
|
|
<seealso><directive module="core">UseCanonicalName</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
|
|
<a href="../vhosts/">namensbasierten virtuellen Hosts</a> fest.</p>
|
|
</usage>
|
|
<seealso><a href="../vhosts/">Apache-Dokumentation zu virtuellen
|
|
Hosts</a></seealso>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>ServerRoot</name>
|
|
<description>Basisverzeichnis der Serverinstallation</description>
|
|
<syntax>ServerRoot <var>Verzeichnis</var></syntax>
|
|
<default>ServerRoot /usr/local/apache</default>
|
|
<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
|
|
<code>logs/</code>. Relative Pfadangaben anderer Direktiven (wie z.B.
|
|
<directive module="core">Include</directive> oder <directive
|
|
module="mod_so">LoadModule</directive>) werden relativ zu diesem
|
|
Verzeichnis betrachtet.</p>
|
|
|
|
<example><title>Beispiel</title>
|
|
ServerRoot /home/httpd
|
|
</example>
|
|
</usage>
|
|
<seealso><a href="../invoking.html">Die <code>httpd</code>-Option
|
|
<code>-d</code></a></seealso>
|
|
<seealso><a href="../misc/security_tips.html#serverroot">Sicherheitshinweise</a>
|
|
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>
|
|
|
|
<dd>Der Server sendet (<em>z.B.</em>): <code>Server:
|
|
Apache</code></dd>
|
|
|
|
<dt><code>ServerTokens Major</code></dt>
|
|
|
|
<dd>Der Server sendet (<em>z.B.</em>): <code>Server:
|
|
Apache/2</code></dd>
|
|
|
|
<dt><code>ServerTokens Minor</code></dt>
|
|
|
|
<dd>Der Server sendet (<em>z.B.</em>): <code>Server:
|
|
Apache/2.0</code></dd>
|
|
|
|
<dt><code>ServerTokens Min[imal]</code></dt>
|
|
|
|
<dd>Der Server sendet (<em>z.B.</em>): <code>Server:
|
|
Apache/2.0.41</code></dd>
|
|
|
|
<dt><code>ServerTokens OS</code></dt>
|
|
|
|
<dd>Der Server sendet (<em>z.B.</em>): <code>Server: Apache/2.0.41
|
|
(Unix)</code></dd>
|
|
|
|
<dt><code>ServerTokens Full</code> (oder nicht angegeben)</dt>
|
|
|
|
<dd>Der Server sendet (<em>z.B.</em>): <code>Server: Apache/2.0.41
|
|
(Unix) PHP/4.2.2 MyMod/1.2</code></dd>
|
|
</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
|
|
<code>http://servername/status</code> aufgerufen wird, einen
|
|
Statusbericht anzeigen lassen möchten, dann können
|
|
Sie folgendes in die <code>httpd.conf</code> schreiben:</p>
|
|
|
|
<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>
|
|
</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>
|
|
<seealso><a href="../filter.html">Filter</a>-Dokumentation</seealso>
|
|
</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
|
|
im Verzeichnis <code>/www/data</code> als Server Side Includes.</p>
|
|
|
|
<example>
|
|
<Directory /www/data/><br />
|
|
<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>
|
|
<seealso><a href="../filter.html">Filter</a>-Dokumentation</seealso>
|
|
</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 300</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.</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
|
|
<em>selbstreferenzierende</em> URL -- d.h. eine URL, die auf den selben
|
|
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
|
|
zuzugreifen, d.h. einen <code>Host</code>-Header mitschicken</transnote>.
|
|
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
|
|
<code>http://www.domain.com/splat/</code> umleitet, wenn dieser einen
|
|
Kurznamen und eine URL, die einem Verzeichnis entspricht, ohne
|
|
abschließenden Schrägstrich eingibt, wie z.B.
|
|
<code>http://www/splat</code>. Wenn Sie Authentisierung aktiviert haben,
|
|
bewirkt dies, dass der Benutzer sich zweimal identifizieren muss
|
|
(einmal für <code>www</code> und noch einmal für
|
|
<code>www.domain.com</code> -- lesen Sie für weitere Informationen <a
|
|
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
|
|
<code>http://www/splat/</code> umleiten.</p>
|
|
|
|
<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 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 />
|
|
DocumentRoot /www/docs/host.foo.com<br />
|
|
ServerName host.foo.com<br />
|
|
ErrorLog logs/host.foo.com-error_log<br />
|
|
TransferLog logs/host.foo.com-access_log<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 />
|
|
DocumentRoot /www/docs/host.example.com<br />
|
|
ServerName host.example.com<br />
|
|
ErrorLog logs/host.example.com-error_log<br />
|
|
TransferLog logs/host.example.com-access_log<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
|
|
href="../vhosts/name-based.html">namensbasierten virtuell Hosts</a>.)</p>
|
|
|
|
<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>
|
|
<seealso><a href="../vhosts/">Apache-Dokumentation zu virtuellen
|
|
Hosts</a></seealso>
|
|
<seealso><a href="../dns-caveats.html">Probleme bezüglich DNS und
|
|
Apache</a></seealso>
|
|
<seealso><a href="../bind.html">Bestimmen, welche Adressen und Ports
|
|
der Apache verwendet</a></seealso>
|
|
<seealso><a href="../sections.html">Wie die Abschnitte <Directory>,
|
|
<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>
|