| <?xml version="1.0"?> |
| <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd"> |
| <?xml-stylesheet type="text/xsl" href="../style/manual.de.xsl"?> |
| <!-- English Revision: 344972:1841039 (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>AcceptFilter</name> |
| <description>Konfiguriert Optimierungen für lauschende Sockets bestimmter |
| Protokolle</description> |
| <syntax>AcceptFilter <var>Protokoll</var> <var>Filter</var></syntax> |
| <contextlist><context>server config</context></contextlist> |
| <compatibility>Verfügbar ab Apache 2.1.5</compatibility> |
| |
| <usage> |
| <p>Diese Direktive aktiviert betriebssystemspezifische Optimierungen |
| für lauschende Sockets anhand des Protokolltyps. Der grundlegende |
| Ansatz ist, dass der Kernel das Socket nicht an den Serverprozess |
| übergibt, bis entweder Daten verfügbar sind oder eine komplette |
| HTTP-Anfrage zwischengespeichert wurde. Derzeit werden |
| ausschließlich die <a |
| href="http://www.freebsd.org/cgi/man.cgi?query=accept_filter&sektion=9" |
| >Accept-Filter von FreeBSD</a> und das primitivere |
| <code>TCP_DEFER_ACCEPT</code> von Linux unterstützt.</p> |
| |
| <p>Die Standardeinstellungen für FreeBSD sind:</p> |
| <example> |
| AcceptFilter http httpready<br /> |
| AcceptFilter https dataready |
| </example> |
| |
| <p>Der <code>httpready</code>-Accept-Filter puffert komplette |
| HTTP-Anfragen auf Kernelebene. Sobald eine Anfrage vollständig |
| vorliegt, schickt der Kernel sie an den Server weiter. Bitte schlagen Sie |
| in der <a |
| href="http://www.freebsd.org/cgi/man.cgi?query=accf_http&sektion=9" |
| >accf_http(9)</a>-Manpage für weitere Details nach. HTTPS-Anfragen |
| sind verschlüsselt. Daher wird dafür nur der <a |
| href="http://www.freebsd.org/cgi/man.cgi?query=accf_data&sektion=9" |
| >accf_data(9)</a>-Filter verwendet.</p> |
| |
| <p>Die Standardeinstellungen für Linux sind:</p> |
| <example> |
| AcceptFilter http data<br /> |
| AcceptFilter https data |
| </example> |
| |
| <p><code>TCP_DEFER_ACCEPT</code> unter Linux unterstützt keine |
| Zwischenspeicherung von HTTP-Anfragen. Jeder andere Wert als |
| <code>none</code> aktiviert <code>TCP_DEFER_ACCEPT</code> auf dem |
| Lauschsocket. Mehr Details finden Sie in der <a |
| href="http://homepages.cwi.nl/~aeb/linux/man2html/man7/tcp.7.html" |
| >tcp(7)</a>-Manpage von Linux.</p> |
| |
| <p>Wenn Sie <code>none</code> als Argument verwenden, werden alle |
| Accept-Filter für das Protokoll abgeschaltet. Das ist sinnvoll |
| für Protokolle, bei denen der Server zuerst Daten senden muss, |
| wie zum Beispiel <code>nntp</code>:</p> |
| <example>AcceptFilter nttp none</example> |
| |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>AcceptPathInfo</name> |
| <description>Ressourcen lassen angehängte Pfadangaben zu</description> |
| <syntax>AcceptPathInfo On|Off|Default</syntax> |
| <default>AcceptPathInfo Default</default> |
| <contextlist><context>server config</context> |
| <context>virtual host</context><context>directory</context> |
| <context>.htaccess</context></contextlist> |
| <override>FileInfo</override> |
| <compatibility>Verfügbar ab Apache 2.0.30</compatibility> |
| |
| <usage> |
| <p>Die Direktive steuert, ob Anfragen akzeptiert oder |
| abgewiesen werden, bei denen nach der tatsächlichen |
| Datei (oder einer nicht existierenden Datei in einem existierenden |
| Verzeichnis) zusätzliche Pfadangaben folgen. Die angehängte |
| Pfadangabe kann Skripten in der Umgebungsvariable <code>PATH_INFO</code> |
| verfügbar gemacht werden.</p> |
| |
| <p>Nehmen wir beispielsweise an, dass <code>/test/</code> auf ein |
| 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 |
| <glossary>MIME-Type</glossary> 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 <glossary>MIME-Type</glossary> |
| nicht bestimmt werden kann und auf die Einstellung der <directive |
| module="core">DefaultType</directive>-Anweisung zurückfällt, |
| selbst wenn die <directive |
| module="core">DefaultType</directive>-Einstellung die gleiche ist.</p> |
| |
| <p>Wenn Sie jedoch sicherstellen wollen, dass der Filter |
| angewendet wird, sollten Sie den Content-Type z.B. mit |
| <directive module="mod_mime">AddType</directive> oder |
| <directive module="core">ForceType</directive> der Ressource |
| explizit zuordnen. Das Setzen des Content-Types innerhalb |
| eines (nicht-nph) CGI-Skriptes funktioniert ebenfalls |
| zuverlässig.</p> |
| |
| <p>Die Typ-gebundenen Ausgabefilter werden niemals auf |
| Proxy-Anfragen angewendet.</p> |
| </note> |
| </usage> |
| |
| <seealso><directive module="mod_mime">AddOutputFilter</directive></seealso> |
| <seealso><directive module="core">SetOutputFilter</directive></seealso> |
| <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 None (2.3.9 und später), AllowOverride All (2.3.8 und früher)</default> |
| <contextlist><context>directory</context></contextlist> |
| |
| <usage> |
| <p>Wenn der Server eine <code>.htaccess</code>-Datei (wie durch |
| <directive module="core">AccessFileName</directive> definiert) |
| findet, muss er wissen, welche in der Datei angegebenen Direktiven |
| frühere Konfigurationsanweisungen überschreiben |
| dürfen.</p> |
| |
| <note><title>Nur in <Directory>-Abschnitten verfügbar</title> |
| <directive>AllowOverride</directive> ist nur in <directive |
| type="section" module="core">Directory</directive>-Abschnitten |
| gültig, die ohne reguläre Ausdrücke definiert wurden, nicht |
| in <directive type="section" module="core">Location</directive>-, |
| <directive module="core" type="section">DirectoryMatch</directive>- oder |
| <directive type="section" module="core">Files</directive>-Abschnitten. |
| </note> |
| |
| <p>Wenn diese Anweisung auf <code>None</code> gesetzt wird, dann |
| werden <a href="#accessfilename">.htaccess</a>-Dateien komplett |
| ignoriert. In diesem Fall wird der Server nicht einmal versuchen, |
| die <code>.htaccess</code>-Dateien im Dateisystem zu lesen.</p> |
| |
| <p>Wenn diese Anweisung auf <code>All</code> gesetzt wird, dann |
| ist jede Direktive in den <code>.htaccess</code>-Dateien erlaubt, |
| 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_authz_dbm">AuthDBMGroupFile</directive>, |
| <directive module="mod_authn_dbm">AuthDBMUserFile</directive>, |
| <directive module="mod_authz_groupfile">AuthGroupFile</directive>, |
| <directive module="mod_authn_core">AuthName</directive>, |
| <directive module="mod_authn_core">AuthType</directive>, <directive |
| module="mod_authn_file">AuthUserFile</directive>, <directive |
| module="mod_authz_core">Require</directive> <em>usw.</em>).</dd> |
| |
| <dt>FileInfo</dt> |
| |
| <dd> |
| Erlaubt die Verwendung von Direktiven zur Steuerung der |
| Dokumenttypen (<directive |
| module="core">DefaultType</directive>, <directive |
| module="core">ErrorDocument</directive>, <directive |
| module="core">ForceType</directive>, <directive |
| module="mod_negotiation">LanguagePriority</directive>, |
| <directive module="core">SetHandler</directive>, <directive |
| module="core">SetInputFilter</directive>, <directive |
| module="core">SetOutputFilter</directive>, und |
| <module>mod_mime</module>-Direktiven Add* und Remove* |
| <em>usw.</em>), Metadaten (<directive |
| module="mod_headers">Header</directive>, <directive |
| module="mod_headers">RequestHeader</directive>, <directive |
| module="mod_setenvif">SetEnvIf</directive>, <directive |
| module="mod_setenvif">SetEnvIfNoCase</directive>, <directive |
| module="mod_setenvif">BrowserMatch</directive>, <directive |
| module="mod_usertrack">CookieExpires</directive>, <directive |
| module="mod_usertrack">CookieDomain</directive>, <directive |
| module="mod_usertrack">CookieStyle</directive>, <directive |
| module="mod_usertrack">CookieTracking</directive>, <directive |
| module="mod_usertrack">CookieName</directive>), |
| <module>mod_rewrite</module>-Direktiven <directive |
| module="mod_rewrite">RewriteEngine</directive>, <directive |
| module="mod_rewrite">RewriteOptions</directive>, <directive |
| module="mod_rewrite">RewriteBase</directive>, <directive |
| module="mod_rewrite">RewriteCond</directive>, <directive |
| module="mod_rewrite">RewriteRule</directive>) und |
| <directive module="mod_actions">Action</directive> aus |
| <module>mod_actions</module>. |
| </dd> |
| |
| <dt>Indexes</dt> |
| |
| <dd> |
| Erlaubt die Verwendung von Direktiven zur Steuerung von |
| Verzeichnisindizes (<directive |
| module="mod_autoindex">AddDescription</directive>, |
| <directive module="mod_autoindex">AddIcon</directive>, <directive |
| module="mod_autoindex">AddIconByEncoding</directive>, |
| <directive module="mod_autoindex">AddIconByType</directive>, |
| <directive module="mod_autoindex">DefaultIcon</directive>, <directive |
| module="mod_dir">DirectoryIndex</directive>, <a |
| href="mod_autoindex.html#indexoptions.fancyindexing"> |
| <code>FancyIndexing</code></a>, <directive |
| module="mod_autoindex">HeaderName</directive>, <directive |
| module="mod_autoindex">IndexIgnore</directive>, <directive |
| module="mod_autoindex">IndexOptions</directive>, <directive |
| module="mod_autoindex">ReadmeName</directive> |
| <em>usw.</em>).</dd> |
| |
| <dt>Limit</dt> |
| |
| <dd> |
| Erlaubt die Verwendung von Direktiven zur Steuerung des |
| Zugriffs von Hosts (<directive |
| module="mod_access_compat">Allow</directive>, <directive |
| module="mod_access_compat">Deny</directive> und <directive |
| module="mod_access_compat">Order</directive>).</dd> |
| |
| <dt>Options[=<var>Option</var>,...]</dt> |
| |
| <dd> |
| Erlaubt die Verwendung von Direktiven zur Steuerung spezieller |
| Verzeichniseigenschaften (<directive module="core">Options</directive> |
| und <directive module="mod_include">XBitHack</directive>). Sie |
| können mit einem Gleichheitszeichen gefolgt von einer |
| kommaseparierten Liste (ohne Leerzeichen) angeben, welche Optionen mit |
| der <directive module="core">Options</directive>-Direktive gesetzt |
| werden dürfen.</dd> |
| </dl> |
| |
| <p>Beispiel:</p> |
| |
| <example> |
| AllowOverride AuthConfig Indexes |
| </example> |
| |
| <p>Im obigen Beispiel erzeugen alle Direktiven einen internal server |
| error <transnote>Server-interner Fehler</transnote>, die weder der |
| Gruppe <code>AuthConfig</code> noch der Gruppe <code>Indexes</code> |
| angehören.</p> |
| </usage> |
| |
| <seealso><directive module="core">AccessFileName</directive></seealso> |
| <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. RFC2616 |
| definiert sind.</p> |
| |
| <p>MD5 ist ein Algorithmus zur Berechnung eines "Datenextrakts" |
| (zuweilen "Fingerabdruck" genannt) <transnote>Der "Datenextrakt" wird im |
| Englischen als "message digest" oder "fingerprint" bezeichnet.</transnote> |
| aus beliebig langen Daten. Es gilt als zuverlässig, dass |
| Veränderungen an den Daten sich in Veränderungen des |
| Extrakts wiederspiegeln.</p> |
| |
| <p>Der <code>Content-MD5</code>-Header bietet eine |
| End-to-End-Integritätsprüfung (MIC) <transnote>MIC steht für |
| "message integrity check".</transnote> des Daten-Inhalts. Ein Proxy oder |
| Client kann diesen Header prüfen, um zufällige Veränderungen |
| des Entity-Inhalts bei der Übertragung festzustellen. |
| Beispielheader:</p> |
| |
| <example> |
| Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA== |
| </example> |
| |
| <p>Beachten Sie bitte, dass dies Performanceprobleme auf Ihrem |
| System verursachen kann, da der Extrakt bei jeder Anfrage |
| berechnet wird (der Wert wird nicht zwischengespeichert).</p> |
| |
| <p><code>Content-MD5</code> wird nur für Dokumente gesendet, |
| die von <module>core</module> bedient werden, nicht jedoch bei |
| Modulen. SSI-Dokumente, CGI-Skript-Ausgaben und Byte-Range-Antworten |
| besitzen diesen Header beispielsweise nicht.</p> |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>DefaultType</name> |
| <description>MIME-Content-Type, der gesendet wird, wenn der Server den Typ |
| nicht auf andere Weise ermitteln kann.</description> |
| <syntax>DefaultType <var>MIME-Type</var></syntax> |
| <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 <glossary ref="mime-type" |
| >MIME-Type</glossary>-Zuordnungen bestimmen kann.</p> |
| |
| <p>Der Server muss den Client über den Content-Type des |
| Dokumentes informieren. Daher verwendet er im Falle eines |
| unbekannten Typs die <code>DefaultType</code>-Einstellung. |
| Zum Beispiel:</p> |
| |
| <example> |
| 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> |
| <name>Define</name> |
| <description>Define the existence of a variable</description> |
| <syntax>Define <var>Parametername</var></syntax> |
| <contextlist><context>server config</context></contextlist> |
| |
| <usage> |
| <p>Equivalent zum übergeben von <var>Parametername</var> mittels des |
| <code>-D</code> Arguments an <program>httpd</program>.</p> |
| <p>Diese Directive kann verwendet werden, um die Nutzung von <directive module="core" |
| type="section">IfDefine</directive> Sectionen umzuschalten, ohne die |
| <code>-D</code> Argumentente in etwaigen Start-Skripten ändern |
| zu müssen.</p> |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis type="section"> |
| <name>Directory</name> |
| <description>Umschließt eine Gruppe von Direktiven, die nur auf |
| das genannte Verzeichnis des Dateisystems und Unterverzeichnisse angewendet |
| werden</description> |
| <syntax><Directory <var>Verzeichnispfad</var>> |
| ... </Directory></syntax> |
| <contextlist><context>server config</context><context>virtual host</context> |
| </contextlist> |
| |
| <usage> |
| <p><directive type="section">Directory</directive> und |
| <code></Directory></code> werden dazu verwendet, eine Gruppe |
| von Direktiven zusammenzufassen, die nur für das genannte |
| Verzeichnis und dessen Unterverzeichnisse gelten. Jede Direktive, |
| die im Verzeichnis-Kontext erlaubt ist, kann verwendet werden. |
| <var>Verzeichnispfad</var> ist entweder der vollständige Pfad zu |
| einem Verzeichnis oder eine Zeichenkette mit Platzhaltern wie sie von der |
| Unix-Shell zum Abgleich verwendet werden. In einer Zeichenkette |
| mit Platzhaltern <transnote>sogenannte wild-cards</transnote> entspricht |
| <code>?</code> einem einzelnen Zeichen und <code>*</code> einer |
| Zeichenkette beliebiger Länge. Sie können auch auch |
| <code>[]</code>-Zeichenbereiche verwenden. Keiner der Platzhalter |
| entspricht dem Zeichen "/". Daher passt <code><Directory |
| /*/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 <glossary ref="regex" |
| >reguläre Ausdrücke</glossary> können ebenfalls |
| verwendet werden, indem das Zeichen <code>~</code> hinzugefügt |
| wird. Beispielsweise würde</p> |
| |
| <example> |
| <Directory ~ "^/www/.*/[0-9]{3}"> |
| </example> |
| |
| <p>auf Verzeichnisse in <code>/www/</code> passen, die aus drei |
| Zahlen bestehen.</p> |
| |
| <p>Wenn mehrere <directive type="section">Directory</directive>-Abschnitte |
| (ohne reguläre Ausdrücke) auf ein Verzeichnis (oder |
| ein ihm übergeordnetes Verzeichnis) passen, welches ein Dokument |
| enthält, dann werden die Direktiven der Reihe nach, angefangen |
| beim kürzesten passenden Muster, vermischt mit den Direktiven |
| aus den <a href="#accessfilename">.htaccess</a>-Dateien, angewendet. |
| Beispiel:</p> |
| |
| <example> |
| <Directory /><br /> |
| <indent> |
| AllowOverride None<br /> |
| </indent> |
| </Directory><br /> |
| <br /> |
| <Directory /home/><br /> |
| <indent> |
| AllowOverride FileInfo<br /> |
| </indent> |
| </Directory> |
| </example> |
| |
| <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 <glossary ref="regex">regulärer |
| Ausdruck</glossary>. Beispielsweise würde</p> |
| |
| <example> |
| <DirectoryMatch "^/www/.*/[0-9]{3}"> |
| </example> |
| |
| <p>auf Verzeichnisse in <code>/www/</code> passen, die aus drei |
| Zeichen bestehen.</p> |
| </usage> |
| <seealso><directive type="section" module="core">Directory</directive> |
| für eine Beschreibung, wie reguläre Ausdrücke mit |
| normalen <directive type="section">Directory</directive>-Anweisungen |
| vermischt werden.</seealso> |
| <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> |
| <li>Unter Linux auf Itanium-Systemen kommt sendfile unter Umständen |
| nicht mit Dateien größer als 2GB klar.</li> |
| </ul> |
| |
| <p>Bei Serverkonfigurationen, die für dieses Problam |
| anfällig sind, sollten die diese Funktion deaktivieren, indem |
| Sie schreiben:</p> |
| |
| <example> |
| EnableSendfile Off |
| </example> |
| |
| <p>Bei per NFS oder SMB eingebundenen Dateien kann diese Funktion |
| explizit für die störenden Dateien deaktiviert werden, indem |
| Sie angeben:</p> |
| |
| <example> |
| <Directory "/pfad-zu-den-nfs-dateien"> |
| <indent> |
| EnableSendfile Off |
| </indent> |
| </Directory> |
| </example> |
| <p>Beachten Sie bitte, dass die verzeichnisbasierte und |
| .htaccess-Konfiguration von <directive>EnableSendfile</directive> |
| nicht vom <module>mod_cache_disk</module>-Modul unterstützt wird. |
| Nur die globale Konfiguration von <directive>EnableSendfile</directive> |
| wird vom Modul beachtet. |
| </p> |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>ErrorDocument</name> |
| <description>Das, was der Server im Fehlerfall an den Client |
| zurückgibt</description> |
| <syntax>ErrorDocument <var>Fehlercode</var> <var>Dokument</var></syntax> |
| <contextlist><context>server config</context><context>virtual host</context> |
| <context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>FileInfo</override> |
| <compatibility>Die Syntax der Anführungszeichen bei Textnachrichten hat |
| sich im Apache 2.0 geändert</compatibility> |
| |
| <usage> |
| <p>Im Falle eines Problems oder Fehlers kann der Apache |
| konfiguriert werden, eine der vier Aktionen auszuführen:</p> |
| |
| <ol> |
| <li>Ausgabe einer einfachen, hartkodierten Fehlermeldung</li> |
| |
| <li>Ausgabe einer angepassten Meldung</li> |
| |
| <li>Umleitung zu einem lokalen <var>URL-Pfad</var> der das |
| Problem bzw. den Fehler behandelt</li> |
| |
| <li>Umleitung zu einer externen <var>URL</var>, die das Problem |
| bzw. den Fehler behandelt</li> |
| </ol> |
| |
| <p>Die erste Option ist Voreinstellung, während die Optionen |
| 2 bis 4 über die Direktive <directive>ErrorDocument</directive> |
| eingestellt werden, welcher der HTTP-Statuscode und eine |
| URL oder Nachricht folgen. Abhängig vom Problem bzw. Fehler bietet |
| der Apache manchmal zusätzliche Informationen an.</p> |
| |
| <p>URLs können bei lokalen Webpfaden mit einem Schrägstrich |
| (/) beginnen (relativ zum <directive module="core" |
| >DocumentRoot</directive>-Verzeichnis) oder eine vollständige URL |
| bilden, die der Client auflösen kann. Alternativ kann eine |
| Nachricht für die Anzeige im Browser angeboten werden. Beispiel:</p> |
| |
| <example> |
| ErrorDocument 500 http://foo.example.com/cgi-bin/tester<br /> |
| ErrorDocument 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 <glossary ref="regex">reguläre |
| Ausdrücke</glossary> können ebenfalls verwendet werden, indem |
| das Zeichen <code>~</code> hinzugefügt wird. Beispielsweise |
| würde</p> |
| |
| <example> |
| <Files ~ "\.(gif|jpe?g|png)$"> |
| </example> |
| |
| <p>auf die gebräuchlichsten Grafikformate im Internet passen. |
| <directive module="core" type="section">FilesMatch</directive> wird |
| jedoch bevorzugt.</p> |
| |
| <p>Beachten Sie bitte, dass die <directive |
| type="section">Files</directive>-Container anders als <directive |
| type="section" module="core">Directory</directive>- und <directive |
| type="section" module="core">Location</directive>-Container innerhalb |
| von <code>.htaccess</code>-Dateien verwendet werden können. |
| Dies erlaubt den Anwendern auf Dateiebene die Kontrolle über ihre |
| eigenen Dateien.</p> |
| </usage> |
| <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 <glossary ref="regex">reguläre |
| Ausdrücke</glossary>. Beispielsweise würde</p> |
| |
| <example> |
| <FilesMatch "\.(gif|jpe?g|png)$"> |
| </example> |
| |
| <p>auf die gebräuchlichsten Grafikformate im Internet passen.</p> |
| </usage> |
| |
| <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 immer einem <directive |
| module="core" type="section">Limit</directive>-Container vorgezogen |
| werden, da <directive module="core" type="section">LimitExcept</directive> |
| einen Schutz gegen beliebige Methoden bietet. |
| </note> |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis type="section"> |
| <name>LimitExcept</name> |
| <description>Beschränkt Zugriffskontrollen auf alle HTTP-Methoden |
| außer den genannten</description> |
| <syntax><LimitExcept <var>Methode</var> [<var>Methode</var>] ... > ... |
| </LimitExcept></syntax> |
| <contextlist><context>server config</context><context>virtual host</context> |
| <context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>All</override> |
| |
| <usage> |
| <p><directive type="section">LimitExcept</directive> und |
| <code></LimitExcept></code> werden dazu verwendet, eine Gruppe |
| von Anweisungen zur Zugriffskontrolle zusammenzufassen, die dann auf |
| jede HTTP-Methode angewendet werden, die <strong>nicht</strong> |
| als Argument angegeben ist. D.h. dies ist das Gegenteil des |
| <directive type="section" module="core">Limit</directive>-Containers |
| und kann zur Steuerung von Standard- und nicht-Standard-/unbekannten |
| Methoden verwendet werden. Für weitere Einzelheiten lesen Sie bitte |
| die Beschreibung zu <directive module="core" |
| type="section">Limit</directive>.</p> |
| |
| <p>Beispiel:</p> |
| |
| <example> |
| <LimitExcept POST GET><br /> |
| <indent> |
| Require valid-user<br /> |
| </indent> |
| </LimitExcept> |
| </example> |
| |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>LimitInternalRecursion</name> |
| <description>Bestimmt die maximale Anzahl interner Umleitungen und |
| verschachtelter Unteranfragen</description> |
| <syntax>LimitInternalRecursion <var>Zahl</var> [<var>Zahl</var>]</syntax> |
| <default>LimitInternalRecursion 10</default> |
| <contextlist><context>server config</context><context>virtual host</context> |
| </contextlist> |
| <compatibility>Verfügbar ab Apache 2.0.47</compatibility> |
| |
| <usage> |
| <p>Eine interne Umleitung erfolgt beispielsweise, wenn die Direktive |
| <directive module="mod_actions">Action</directive> verwendet wird, welche |
| die Originalanfrage intern zu einem CGI-Skript weiterleitet. Eine |
| Unteranfrage <transnote>engl. Subrequest</transnote> ist ein Mechanismus des |
| Apache, um herauszufinden, was bei einer URI geschehen würde, wäre |
| 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 <glossary ref="regex">reguläre |
| Ausdrücke</glossary> können ebenfalls verwendet werden, indem |
| das Zeichen <code>~</code> hinzugefügt wird. Beispielsweise |
| würde</p> |
| |
| <example> |
| <Location ~ "/(extra|special)/data"> |
| </example> |
| |
| <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 <glossary ref="regex">reguläre |
| Ausdrücke</glossary> 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> |
| |
| <note type="warning"><title>Warnung</title> |
| <p>Die Vermischung von Optionen mit <code>+</code> oder <code>-</code> mit |
| Optionen ohne diese (Zeichen) ist keine gültige Syntax und führt |
| mit hoher Wahrscheinlichkeit zu unerwarteten Effekten.</p> |
| </note> |
| |
| <p>So wird zum Beispiel ohne die Zeichen <code>+</code> und |
| <code>-</code></p> |
| |
| <example> |
| <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="mod_authn_core">AuthName</directive> und <directive |
| module="mod_authn_core">AuthType</directive> sowie Direktiven wie |
| <directive module="mod_authn_file">AuthUserFile</directive> |
| und <directive module="mod_authz_groupfile">AuthGroupFile</directive> |
| (zur Definition von Benutzern und Gruppen) begleitet werden, um |
| korrekt zu funktionieren. Beispiel:</p> |
| |
| <example> |
| AuthType Basic<br /> |
| AuthName "Geschützte Ressource"<br /> |
| 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="mod_access_compat">Satisfy</directive></seealso> |
| <seealso><module>mod_authz_host</module></seealso> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>RLimitCPU</name> |
| <description>Begrenzt den CPU-Verbrauch von Prozessen, die von |
| Apache-Kindprozessen gestartet wurden</description> |
| <syntax>RLimitCPU <var>Sekunden</var>|max [<var>Sekunden</var>|max]</syntax> |
| <default>unbestimmt; verwendet die Voreinstellung des Systems</default> |
| <contextlist><context>server config</context><context>virtual host</context> |
| <context>directory</context><context>.htaccess</context></contextlist> |
| <override>All</override> |
| |
| <usage> |
| <p>Akzeptiert einen oder zwei Parameter. Der erste Paramater setzt eine |
| weiche Ressourcenbegrenzung für alle Prozesse, der zweite Parameter |
| setzt die Maximalgrenze für die Ressourcennutzung. Jeder der |
| Parameter kann eine Zahl oder <code>max</code> sein. <code>max</code> |
| zeigt dem Server an, dass das vom Betriebssystem erlaubte Maximum |
| verwendet werden soll. Das Anheben der maximal erlaubten Ressourcennutzung |
| erfordert, dass der Server als <code>root</code> läuft, zumindest in |
| der anfänglichen Startphase.</p> |
| |
| <p>Dies wird auf Prozesse angewendet, die von Anfragen bearbeitenden |
| Apache-Kindprozessen abgespalten werden, nicht auf die |
| Apache-Kindprozesse selbst. Das beinhaltet CGI-Skripte und |
| SSI-exec-Befehle, nicht jedoch Prozesse, die vom Apache-Elternprozess |
| abgespalten werden, wie z.B. Protokollierung.</p> |
| |
| <p>CPU-Ressourcenbegrenzung wird in Sekunden pro Prozess |
| ausgedrückt.</p> |
| </usage> |
| <seealso><directive module="core">RLimitMEM</directive></seealso> |
| <seealso><directive module="core">RLimitNPROC</directive></seealso> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>RLimitMEM</name> |
| <description>Begrenzt den Speicherverbrauch von Prozessen, die von |
| Apache-Kindprozessen gestartet wurden</description> |
| <syntax>RLimitMEM <var>Bytes</var>|max [<var>Bytes</var>|max]</syntax> |
| <default>unbestimmt; verwendet die Voreinstellung des Systems</default> |
| <contextlist><context>server config</context><context>virtual host</context> |
| <context>directory</context><context>.htaccess</context></contextlist> |
| <override>All</override> |
| |
| <usage> |
| <p>Akzeptiert einen oder zwei Parameter. Der erste Paramater setzt eine |
| weiche Ressourcenbegrenzung für alle Prozesse, der zweite Parameter |
| setzt die Maximalgrenze für die Ressourcennutzung. Jeder der |
| Parameter kann eine Zahl oder <code>max</code> sein. <code>max</code> |
| zeigt dem Server an, dass das vom Betriebssystem erlaubte Maximum |
| verwendet werden soll. Das Anheben der maximal erlaubten Ressourcennutzung |
| erfordert, dass der Server als <code>root</code> läuft, zumindest in |
| der anfänglichen Startphase.</p> |
| |
| <p>Dies wird auf Prozesse angewendet, die von Anfragen bearbeitenden |
| Apache-Kindprozessen abgespalten werden, nicht auf die |
| Apache-Kindprozesse selbst. Das beinhaltet CGI-Skripte und |
| SSI-exec-Befehle, nicht jedoch Prozesse, die vom Apache-Elternprozess |
| abgespalten werden, wie z.B. Protokollierung.</p> |
| |
| <p>Die Begrenzung des Speicherverbrauchs wird in Bytes pro Prozess |
| ausgedrückt.</p> |
| </usage> |
| <seealso><directive module="core">RLimitCPU</directive></seealso> |
| <seealso><directive module="core">RLimitNPROC</directive></seealso> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>RLimitNPROC</name> |
| <description>Begrenzt die Anzahl der Prozesse, die von Prozessen gestartet |
| werden können, der ihrerseits von Apache-Kinprozessen gestartet |
| wurden</description> |
| <syntax>RLimitNPROC <var>Zahl</var>|max [<var>Zahl</var>|max]</syntax> |
| <default>unbestimmt; verwendet die Voreinstellung des Systems</default> |
| <contextlist><context>server config</context><context>virtual host</context> |
| <context>directory</context><context>.htaccess</context></contextlist> |
| <override>All</override> |
| |
| <usage> |
| <p>Akzeptiert einen oder zwei Parameter. Der erste Paramater setzt eine |
| weiche Ressourcenbegrenzung für alle Prozesse, der zweite Parameter |
| setzt die Maximalgrenze für die Ressourcennutzung. Jeder der |
| Parameter kann eine Zahl oder <code>max</code> sein. <code>max</code> |
| zeigt dem Server an, dass das vom Betriebssystem erlaubte Maximum |
| verwendet werden soll. Das Anheben der maximal erlaubten Ressourcennutzung |
| erfordert, dass der Server als <code>root</code> läuft, zumindest in |
| der anfänglichen Startphase.</p> |
| |
| <p>Dies wird auf Prozesse angewendet, die von Anfragen bearbeitenden |
| Apache-Kindprozessen abgespalten werden, nicht auf die |
| Apache-Kindprozesse selbst. Dies beinhaltet CGI-Skripte und |
| SSI-exec-Befehle, nicht jedoch Prozesse, die vom Apache-Elternprozess |
| abgespalten werden, wie z.B. Protokollierung.</p> |
| |
| <p>Prozessbegrenzungen steuern die Anzahl der Prozesse pro Benutzer.</p> |
| |
| <note><title>Anmerkung</title> |
| <p>Wenn CGI-Prozesse nicht unter anderen Benutzerkennungen als der |
| User-ID des Webservers laufen, dann beschränkt diese Direktive |
| die Anzahl der Prozesse, die der Server selbst erstellen kann. |
| Kennzeichen einer solchen Situation sind |
| <strong><code>cannot fork</code></strong>-Meldungen |
| <transnote><code>kann nicht abspalten</code></transnote> in der |
| Datei <code>error_log</code>.</p> |
| </note> |
| </usage> |
| <seealso><directive module="core">RLimitMEM</directive></seealso> |
| <seealso><directive module="core">RLimitCPU</directive></seealso> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>Satisfy</name> |
| <description>Zusammenspiel von rechnerbasierter Zugriffskontrolle und |
| Benutzerauthentisierung</description> |
| <syntax>Satisfy Any|All</syntax> |
| <default>Satisfy All</default> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| <compatibility>Wird seit Version 2.0.51 von <directive module="core" |
| type="section">Limit</directive> und <directive module="core" |
| type="section">LimitExcept</directive> beeinflusst</compatibility> |
| |
| <usage> |
| <p>Verfahrensweise für den Zugriff, falls sowohl <directive |
| module="mod_access_compat">Allow</directive> als auch <directive |
| module="mod_authz_core">Require</directive> verwendet werden. Der Parameter kann |
| entweder <code>All</code> oder <code>Any</code> sein. Die Direktive ist |
| nur dann nützlich, wenn der Zugriff zu einem bestimmten Bereich |
| 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_access_compat">Allow</directive></seealso> |
| <seealso><directive module="mod_access_compat">Require</directive></seealso> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>ScriptInterpreterSource</name> |
| <description>Methode zur Ermittlung des Interpreters von |
| CGI-Skripten</description> |
| <syntax>ScriptInterpreterSource Registry|Registry-Strict|Script</syntax> |
| <default>ScriptInterpreterSource Script</default> |
| <contextlist><context>server config</context><context>virtual host</context> |
| <context>directory</context><context>.htaccess</context></contextlist> |
| <override>FileInfo</override> |
| <compatibility>ausschließlich Win32; |
| Die Option <code>Registry-Strict</code> ist verfügbar seit Apache |
| 2.0.</compatibility> |
| |
| <usage> |
| <p>Die Direktive steuert, wie der Apache den Interpreter zur Ausführung |
| von CGI-Skripten bestimmt. Die Voreinstellung ist <code>Script</code>. Dies |
| veranlaßt den Apache, den Interpreter zu verwenden, auf den die |
| Shebang-Zeile (erste Zeile, beginnt mit <code>#!</code>) im Skript zeigt. |
| Auf Win32-Systemen sieht diese Zeile üblicherweise so aus:</p> |
| |
| <example> |
| #!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 Direktiven <directive |
| module="core">UseCanonicalName</directive> und <directive module="core" |
| >UseCanonicalPhysicalPort</directive> für Einstellungen, die |
| bestimmen, ob selbstreferenzierende URLs (z.B. vom Modul |
| <module>mod_dir</module>) auf den angegebenen Port zeigen oder auf die |
| Portnummern die in der Anfrage des Clients angegeben ist.</p> |
| </usage> |
| |
| <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">UseCanonicalPhysicalPort</directive></seealso> |
| <seealso><directive module="core">NameVirtualHost</directive></seealso> |
| <seealso><directive module="core">ServerAlias</directive></seealso> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>ServerPath</name> |
| <description>Veralteter URL-Pfad für einen namensbasierten |
| virtuellen Host, auf den von einem inkompatiblen Browser zugegriffen |
| wird</description> |
| <syntax>ServerPath <var>URL-Pfad</var></syntax> |
| <contextlist><context>virtual host</context></contextlist> |
| |
| <usage> |
| <p>Die Direktive <directive>ServerPath</directive> legt den |
| veralteten <transnote>Gemeint ist eigentlich "Altlast" aufgrund |
| antiquierter Clients.</transnote> URL-Pfad eines Hosts zur Verwendung mit |
| <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> |
| <p><strong>Hinweis:</strong> SetHandler setzt die Standard-Handler |
| außer Kraft und unterdrückt gewohnte Verhaltensweisen, wie |
| beispielsweise die Behandlung von URLs, die auf einen Schrägstrich |
| (/) enden als Verzeichnisse oder (die Auslieferung von) Index-Dateien.</p> |
| </usage> |
| <seealso><directive module="mod_mime">AddHandler</directive></seealso> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>SetInputFilter</name> |
| <description>Bestimmt die Filter, die Client-Anfragen und POST-Eingaben |
| verarbeiten</description> |
| <syntax>SetInputFilter <var>Filter</var>[;<var>Filter</var>...]</syntax> |
| <contextlist><context>server config</context><context>virtual host</context> |
| <context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>FileInfo</override> |
| |
| <usage> |
| <p>Die Direktive <directive>SetInputFilter</directive> bestimmt den oder |
| die Filter, die Client-Anfragen und POST-Eingaben verarbeiten, wenn |
| sie vom Server empfangen werden. Diese gelten zusätzlich zu |
| anderweitig definierten Filtern, einschließlich denen der Direktive |
| <directive module="mod_mime">AddInputFilter</directive>.</p> |
| |
| <p>Wenn mehr als ein Filter angegeben wird, dann müssen diese |
| durch Semikolon voneinander getrennt in der Reihenfolge angegeben werden, |
| in der sie die Daten verarbeiten sollen.</p> |
| </usage> |
| <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 60</default> |
| <contextlist><context>server config</context></contextlist> |
| |
| <usage> |
| <p>Die Direktive <directive>TimeOut</directive> definiert derzeit die |
| Zeitspanne, die der Apache auf drei Dinge wartet:</p> |
| |
| <ol> |
| <li>Die gesamte Zeispanne, die benötigt wird, um eine GET-Anfrage |
| zu empfangen.</li> |
| |
| <li>Die Zeitspanne zwischen dem Empfang von TCP-Paketen einer |
| POST- oder PUT-Anfrage.</li> |
| |
| <li>Die Zeitspanne zwischen ACKs bei der Übermittlung der |
| TCP-Pakete der Antwort.</li> |
| </ol> |
| |
| <p>Wir haben vor, diese Zeitspannen in Zukunft separat konfigurierbar zu |
| machen. Vor Version 1.2 war der Zeitgeber auf 1200 voreingestellt, wurde |
| dann aber auf 300 herabgesetzt, was immer noch weit mehr ist, als in den |
| meisten Situationen benötigt wird. Die Voreinstellung wurde nicht |
| weiter herabgesetzt, da gelegentlich noch Stellen im Code existieren |
| können, wo der Zeitgeber nicht zurückgesetzt wird, wenn ein |
| Paket verschickt wird. Seit Apache 2.4 ist die Voreinstellung 60.</p> |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>TraceEnable</name> |
| <description>Legt das Verhalten von <code>TRACE</code>-Anfragen fest</description> |
| <syntax>TraceEnable <var>[on|off|extended]</var></syntax> |
| <default>TraceEnable on</default> |
| <contextlist><context>server config</context></contextlist> |
| <compatibility>Verfügbar ab Apache 1.3.34 und 2.0.55</compatibility> |
| |
| <usage> |
| <p>Diese Direktive beeinflusst das Verhalten von <code>TRACE</code> sowohl |
| für den Server selbst als auch <module>mod_proxy</module>. Die |
| Voreinstellung <code>TraceEnable on</code> erlaubt |
| <code>TRACE</code>-Anfragen gemäß RFC 2616. Dort werden |
| nur Anfragen ohne Datenteil zugelassen. <code>TraceEnable off</code> |
| sorgt dafür, dass der Serverkern und <module>mod_proxy</module> den |
| Fehler <code>405</code> (Zugriffsmethode nicht erlaubt) an den Client |
| senden.</p> |
| |
| <p>Zu Test- und Diagnosezwecken können Sie auch |
| nicht-standardkonforme Anfragen mit Datenteil erlauben, indem Sie die |
| Direktive <code>TraceEnable extended</code> verwenden. Der Server (als |
| Ursprungsserver) beschränkt den Anfrageinhalt auf 64k. (Wenn |
| <code>Transfer-Encoding: chunked</code> benutzt wird, können |
| weitere 8k für die Chunk-Kopfzeilen verwendet werden.) Der |
| Server selbst reflektiert dann die vollständigen HTTP- und |
| Chunk-Kopfzeilen in seiner Antwort. Die Einschränkung auf 64k gilt |
| nicht, wenn der Server als Proxy arbeitet.</p> |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>UseCanonicalName</name> |
| <description>Bestimmt, wie der Server seinen eigenen Namen und Port |
| ermittelt</description> |
| <syntax>UseCanonicalName On|Off|DNS</syntax> |
| <default>UseCanonicalName Off</default> |
| <contextlist><context>server config</context><context>virtual host</context> |
| <context>directory</context></contextlist> |
| |
| <usage> |
| <p>In vielen Situationen muss der Apache eine |
| <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> |
| <name>UseCanonicalPhysicalPort</name> |
| <description>Bestimmt, wie der Server seinen eigenen Namen und Port |
| ermittelt</description> |
| <syntax>UseCanonicalPhysicalPort On|Off</syntax> |
| <default>UseCanonicalPhysicalPort Off</default> |
| <contextlist><context>server config</context><context>virtual host</context> |
| <context>directory</context></contextlist> |
| |
| <usage> |
| <p>In vielen Situationen muss der Apache eine |
| <em>selbstreferenzierende</em> URL zusammenbauen, d.h. eine URL, die auf |
| den selben Server zurück verweist. Wenn der Apache für die |
| <directive module="core">UseCanonicalName</directive>-Direktive den Port |
| bestimmt, wird mit <code>UseCanonicalPhysicalPort On</code> die |
| tatsächlich für die Anfrage verwendete physische Portnummer |
| in Betracht gezogen. Mit <code>UseCanonicalPhysicalPort Off</code> |
| verläßt sich der Apache nur auf die Konfiguration, um eine |
| gültige Portnummer zu bestimmen und läßt die |
| physische Portnummer außer acht.</p> |
| |
| <note><title>Hinweis</title> |
| <p>Wenn der physische Port verwendet wird, ist die Reihenfolge wie |
| folgt:<br /><br /> |
| <code>UseCanonicalName On</code></p> |
| <ul> |
| <li>Der in <code>Servername</code> angegebene Port</li> |
| <li>Der physische Port</li> |
| <li>Der Standardport</li> |
| </ul> |
| <code>UseCanonicalName Off | DNS</code> |
| <ul> |
| <li>Der Port, der aus dem <code>Host:</code>-Header gewonnen wurde</li> |
| <li>Der physische Port</li> |
| <li>Der in <code>Servername</code> angegebene Port</li> |
| <li>Der Standardport</li> |
| </ul> |
| |
| <p>Bei <code>UseCanonicalPhysicalPort Off</code> werden die physischen |
| Ports aus der Suchreihe entfernt.</p> |
| </note> |
| |
| </usage> |
| <seealso><directive module="core">UseCanonicalName</directive></seealso> |
| <seealso><directive module="core">ServerName</directive></seealso> |
| <seealso><directive module="mpm_common">Listen</directive></seealso> |
| </directivesynopsis> |
| |
| <directivesynopsis type="section"> |
| <name>VirtualHost</name> |
| <description>Enthält Direktiven, die nur auf bestimmte Hostnamen oder |
| IP-Adressen angewendet werden</description> |
| <syntax><VirtualHost |
| <var>Adresse</var>[:<var>Port</var>] [<var>Adresse</var>[:<var>Port</var>]] |
| ...> ... </VirtualHost></syntax> |
| <contextlist><context>server config</context></contextlist> |
| |
| <usage> |
| <p><directive type="section">VirtualHost</directive> und |
| <code></VirtualHost></code> werden dazu verwendet, eine Gruppe |
| von Direktiven zusammenzufassen, die nur auf einen bestimmten virtuellen |
| Host angewendet werden. Jede Direktive, die im Virtual-Host-Kontext |
| zulässig ist, kann verwendet werden. Wenn der Server eine Anfrage |
| für ein bestimmtes Dokument eines bestimmten virtuellen Hosts |
| empfängt, dann benutzt er die im |
| <directive type="section">VirtualHost</directive>-Container enthaltenen |
| Konfigurationsanweisungen. <var>Adresse</var> kann sein:</p> |
| |
| <ul> |
| <li>Die IP-Adresse des virtuellen Hosts.</li> |
| |
| <li>Ein voll qualifizierter Domainname für die IP-Adresse des |
| virtuellen Hosts.</li> |
| |
| <li>Das Zeichen <code>*</code>, welches nur in Kombination mit |
| <code>NameVirtualHost *</code> verwendet wird, um allen IP-Adressen |
| zu entsprechen.</li> |
| |
| <li>Die Zeichenkette <code>_default_</code>, die nur mit IP-basierten |
| virtuellen Hosts verwendet wird, um nicht zugewiesene IP-Adressen |
| aufzufangen.</li> |
| </ul> |
| |
| <example><title>Beispiel</title> |
| <VirtualHost 10.1.2.3><br /> |
| <indent> |
| ServerAdmin webmaster@host.foo.com<br /> |
| 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> |
