Apache-Kernfunktionen

Direktiven

• AcceptFilter
• AcceptPathInfo
• AccessFileName
• AddDefaultCharset
• AllowEncodedSlashes
• AllowOverride
• AllowOverrideList
• CGIMapExtension
• CGIPassAuth
• CGIVar
• ContentDigest
• DefaultRuntimeDir
• DefaultType
• Define
• <Directory>
• <DirectoryMatch>
• DocumentRoot
• <Else>
• <ElseIf>
• EnableMMAP
• EnableSendfile
• Error
• ErrorDocument
• ErrorLog
• ErrorLogFormat
• ExtendedStatus
• FileETag
• <Files>
• <FilesMatch>
• FlushMaxPipelined
• FlushMaxThreshold
• ForceType
• GprofDir
• HostnameLookups
• HttpProtocolOptions
• <If>
• <IfDefine>
• <IfDirective>
• <IfFile>
• <IfModule>
• <IfSection>
• Include
• IncludeOptional
• KeepAlive
• KeepAliveTimeout
• <Limit>
• <LimitExcept>
• LimitInternalRecursion
• LimitRequestBody
• LimitRequestFields
• LimitRequestFieldSize
• LimitRequestLine
• LimitXMLRequestBody
• <Location>
• <LocationMatch>
• LogLevel
• MaxKeepAliveRequests
• MaxRangeOverlaps
• MaxRangeReversals
• MaxRanges
• MergeSlashes
• MergeTrailers
• Mutex
• NameVirtualHost
• Options
• Protocol
• Protocols
• ProtocolsHonorOrder
• QualifyRedirectURL
• ReadBufferSize
• RegexDefaultOptions
• RegisterHttpMethod
• RLimitCPU
• RLimitMEM
• RLimitNPROC
• ScriptInterpreterSource
• SeeRequestTail
• ServerAdmin
• ServerAlias
• ServerName
• ServerPath
• ServerRoot
• ServerSignature
• ServerTokens
• SetHandler
• SetInputFilter
• SetOutputFilter
• StrictHostCheck
• TimeOut
• TraceEnable
• UNCList
• UnDefine
• UseCanonicalName
• UseCanonicalPhysicalPort
• <VirtualHost>

Bugfix checklist

• httpd changelog
• Known issues
• Report a bug

Siehe auch

• Kommentare

AcceptFilter-Direktive

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 dieAccept-Filter von FreeBSD und das primitivereTCP_DEFER_ACCEPT von Linux unterstützt.

Die Standardeinstellungen für FreeBSD sind:

Derhttpready-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 deraccf_http(9)-Manpage für weitere Details nach. HTTPS-Anfragen sind verschlüsselt. Daher wird dafür nur deraccf_data(9)-Filter verwendet.

Die Standardeinstellungen für Linux sind:

TCP_DEFER_ACCEPT unter Linux unterstützt keine Zwischenspeicherung von HTTP-Anfragen. Jeder andere Wert alsnone aktiviertTCP_DEFER_ACCEPT auf dem Lauschsocket. Mehr Details finden Sie in dertcp(7)-Manpage von Linux.

Wenn Sienone 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 Beispielnntp:

AcceptPathInfo-Direktive

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 UmgebungsvariablePATH_INFO verfügbar gemacht werden.

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

Die drei möglichen Argumente für die DirektiveAcceptPathInfo sind:

Off

Eine Anfrage wird nur dann akzeptiert, wenn sie exakt auf ein existierendes Verzeichnis (oder eine Datei) abgebildet werden kann. Daher würde eine Anfrage mit einer nach dem tatsächlichen Dateinamen angehängten Pfadangabe, wie/test/here.html/more im obigen Beispiel, den Fehler 404 NOT FOUND(Anm.d.Ü.: nicht gefunden) zurückgeben.

On

Eine Anfrage wird akzeptiert, wenn eine vorangestellte Pfadangabe auf ein existierendes Verzeichnis abgebildet werden kann. Das obige Beispiel/test/here.html/more wird akzeptiert, wenn/test/here.html auf eine gültige Datei zeigt.

Default

Die Behandlung von Anfragen mit angehängten Pfadangaben wird von dem für die Anfrage verantwortlichenHandler bestimmt. Der Core-Handler für gewöhnliche Dateien weistPATH_INFO-Zugriffe standardmäßig zurück. Handler, die Skripte bedienen, wie z.B.cgi-script undisapi-handler, sind im Allgemeinen darauf voreingestellt,PATH_INFO zu akzeptieren.

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

AccessFileName-Direktive

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 Konfigurationsdateienerlaubt sind. Beispiel:

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

deaktiviert wurden.

Siehe auch

• AllowOverride
• Konfigurationsdateien
• .htaccess-Dateien

AddDefaultCharset-Direktive

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 entwedertext/plain odertext/html ist. Dies sollte jedes mittelsMETA-Element im Datenteil der Antwort angegebene Charset überschreiben. Das genaue Verhalten hängt jedoch oft von der Client-Konfiguration des Benutzers ab. Die EinstellungAddDefaultCharset Off deaktiviert diese Funktionalität.AddDefaultCharset On aktiviert die Standard-Zeichenkodierungiso-8859-1. Jeder andere Wert wird als die zu verwendendeZeichenkodierung aufgefaßt, die eines der beiIANA registrierten Charset-Werte zur Verwendung in MIME-Medientypen sein sollte. Zum Beispiel:

AddDefaultCharset sollte nur verwendet werden, wenn von allen Textressourcen, für die es gilt, bekannt ist, dass sie in dieser Zeichkodierung vorliegen, oder wenn es zu unbequem ist, ihre Zeichenkodierung indivuell zu benennen. Ein solches Beispiel ist das Hinzufügen des Charset-Parameters zu Ressourcen, die generierte Inhalte enthalten. Ein Beispiel sind CGI-Skript-Altlasten, die aufgrund von in die Ausgabe integrierten Daten, die durch den Benutzer übermittelt wurden, gegen Cross-Site-Scripting-Angriffe verwundbar sind. Eine bessere Lösung wäre jedoch, diese Skripte zu korrigieren (oder zu löschen), da die Angabe einer Standard-Zeichencodierung keine Anwender schützt, die in ihrem Browser die Funktion zur automatischen Erkennung der Zeichenkodierung aktiviert haben.

Siehe auch

• AddCharset

AllowEncodedSlashes-Direktive

DieAllowEncodedSlashes-Direktive erlaubt die Verwendung von URLs, welche kodierte Pfadtrennzeichen (%2F für/ und auf entsprechenden Systemen zusätzlich%5C für\) enthalten. Normalerweise werden derartige URLs mit einem 404-Fehler (Nicht gefunden) abgewiesen.

AllowEncodedSlashesOn ist vor allem in Verbindung mitPATH_INFO hilfreich.

Siehe auch

• AcceptPathInfo

AllowOverride-Direktive

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

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

Wenn diese Anweisung aufAll gesetzt wird, dann ist jede Direktive in den.htaccess-Dateien erlaubt, die denKontext .htaccess besitzt.

DerDirektiven-Typ kann eine der folgenden Anweisungsgruppen sein.

AuthConfig

Erlaubt die Verwendung von Autorisierungs-Anweisungen (AuthDBMGroupFile,AuthDBMUserFile,AuthGroupFile,AuthName,AuthType,AuthUserFile,Requireusw.).

FileInfo

Erlaubt die Verwendung von Direktiven zur Steuerung der Dokumenttypen (DefaultType,ErrorDocument,ForceType,LanguagePriority,SetHandler,SetInputFilter,SetOutputFilter, undmod_mime-Direktiven Add* und Remove*usw.), Metadaten (Header,RequestHeader,SetEnvIf,SetEnvIfNoCase,BrowserMatch,CookieExpires,CookieDomain,CookieStyle,CookieTracking,CookieName),mod_rewrite-DirektivenRewriteEngine,RewriteOptions,RewriteBase,RewriteCond,RewriteRule) undAction ausmod_actions.

Indexes

Erlaubt die Verwendung von Direktiven zur Steuerung von Verzeichnisindizes (AddDescription,AddIcon,AddIconByEncoding,AddIconByType,DefaultIcon,DirectoryIndex,FancyIndexing,HeaderName,IndexIgnore,IndexOptions,ReadmeNameusw.).

Limit

Erlaubt die Verwendung von Direktiven zur Steuerung des Zugriffs von Hosts (Allow,Deny undOrder).

Options[=Option,...]

Erlaubt die Verwendung von Direktiven zur Steuerung spezieller Verzeichniseigenschaften (Options undXBitHack). Sie können mit einem Gleichheitszeichen gefolgt von einer kommaseparierten Liste (ohne Leerzeichen) angeben, welche Optionen mit derOptions-Direktive gesetzt werden dürfen.

Beispiel:

Im obigen Beispiel erzeugen alle Direktiven einen internal server error(Anm.d.Ü.: Server-interner Fehler), die weder der GruppeAuthConfig noch der GruppeIndexes angehören.

Siehe auch

• AccessFileName
• Konfigurationsdateien
• .htaccess-Dateien

AllowOverrideList-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

Siehe auch

• AccessFileName
• AllowOverride
• Configuration Files
• .htaccess Files

CGIMapExtension-Direktive

Die Direktive wird zur Steuerung verwendet, wie Apache den Interpreter ermittelt, der zur Ausführung von CGI-Skripten verwendet wird. Beispielsweise bestimmt die Angabe vonCGIMapExtension sys:\foo.nlm .foo, dass alle CGI-Scripte mit der Endung.foo an den FOO-Interpreter übergeben werden.

CGIPassAuth-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

CGIVar-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

ContentDigest-Direktive

Die Direktive aktiviert die Generierung vonContent-MD5-Headern, wie sie in RFC1864 bzw. RFC2616 definiert sind.

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

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

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

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

DefaultRuntimeDir-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

Siehe auch

• the security tips for information on how to properly set permissions on theServerRoot

DefaultType-Direktive

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

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

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

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

Define-Direktive

Equivalent zum übergeben vonParametername mittels des-D Arguments anhttpd.

Diese Directive kann verwendet werden, um die Nutzung von<IfDefine> Sectionen umzuschalten, ohne die-D Argumentente in etwaigen Start-Skripten ändern zu müssen.

<Directory>-Direktive

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

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

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

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

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

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

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

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

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

ändern und anschließend für Verzeichnisse überschreiben, die Sie verfügbar machenwollen. Für weitere Einzelheiten lesen Sie bitte die Seite zu denSicherheitshinweisen.

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

Siehe auch

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

<DirectoryMatch>-Direktive

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

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

Siehe auch

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

DocumentRoot-Direktive

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

Damit bezieht sich ein Zugriff aufhttp://www.my.host.com/index.html auf/usr/web/index.html. Wenn dasVerzeichnis nicht absolut angegeben ist, wird es relativ zuServerRoot betrachtet.

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

Siehe auch

• URLs auf das Dateisystemabbilden

<Else>-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

Siehe auch

• <If>
• <ElseIf>
• How <Directory>, <Location>, <Files> sections work for an explanation of how these different sections are combined when a request is received.<If>,<ElseIf>, and<Else> are applied last.

<ElseIf>-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

Siehe auch

• Expressions in Apache HTTP Server,for a complete reference and more examples.
• <If>
• <Else>
• How <Directory>, <Location>, <Files> sections work for an explanation of how these different sections are combined when a request is received.<If>,<ElseIf>, and<Else> are applied last.

EnableMMAP-Direktive

Die Direktive steuert, obhttpd 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 mittelsmod_include serverseitig analysierten Datei --, dann verwendet der Apache standardmäßig Memory-Mapping für diese Datei, sofern das Betriebssystem es unterstützt.

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

• Bei einigen Multiprozessorsystemen kann Memory-Mapping die Performance vonhttpd reduzieren.
• Bei einem per NFS eingebundenenDocumentRoot kannhttpd mit einem Speicherzugriffsfehler(Anm.d.Ü.: ein so genannter "segmentation fault") abstürzen, wenn eine Datei gelöscht oder gekürzt wird, währendhttpd sie im Speicher abbildet.

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

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

EnableSendfile-Direktive

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

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

• Einige Plattformen besitzen u.U. eine fehlerhafte sendfile-Unterstützung, die das Erstellungssystem nicht erkennt, insbesondere wenn die Binärdateien auf einem anderen Rechner erstellt und auf eine solche Maschine mit fehlerhafter sendfile-Unterstützung übertragen wurden.
• Bei einem über das Netzwerk eingebundenenDocumentRoot (z.B. NFS oder SMB) ist der Kernel möglicherweise nicht in der Lage, die Netzwerkdatei über seinen eigenen Cache zu bedienen.
• Unter Linux löst die Verwendung vonsendfile in Verbindung mit bestimmten Netzwerkkarten und IPv6 TCP-Checksummenfehler aus.
• Unter Linux auf Itanium-Systemen kommt sendfile unter Umständen nicht mit Dateien größer als 2GB klar.

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

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

Beachten Sie bitte, dass die verzeichnisbasierte und .htaccess-Konfiguration vonEnableSendfile nicht vommod_cache_disk-Modul unterstützt wird. Nur die globale Konfiguration vonEnableSendfile wird vom Modul beachtet.

Error-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

ErrorDocument-Direktive

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

1. Ausgabe einer einfachen, hartkodierten Fehlermeldung
2. Ausgabe einer angepassten Meldung
3. Umleitung zu einem lokalenURL-Pfad der das Problem bzw. den Fehler behandelt
4. Umleitung zu einer externenURL, die das Problem bzw. den Fehler behandelt

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

URLs können bei lokalen Webpfaden mit einem Schrägstrich (/) beginnen (relativ zumDocumentRoot-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:

Außerdem kann der spezielle Wertdefault angegeben werden, um die schlichte, hartkodierte Nachricht des Apache zu verwenden. Es wird normalerweise nicht benötigt, dochdefault stellt die einfach, im Apache hartkodierte Meldung in Konfigurationen wieder her, die ansonsten von einem existierenden(Anm.d.Ü.: zuvor konfigurierten)ErrorDocument erben würden.

Wenn Sie eineErrorDocument-Anweisung angeben, die auf eine entfernte URL weist (d.h. irgendetwas mit der Methodehttp 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 AnweisungErrorDocument 401 verwenden, wird der Client darüber hinaus nicht wissen, dass er den Benutzer zur Eingabe eines Passwortes auffordern muss, da er den Statuscode 401 nicht erhält.Deshalb müssen Sie sich auf ein lokales Dokument beziehen, wenn Sie eine AnweisungErrorDocument 401 verwenden.

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

Obwohl die meisten Fehlermeldungen überschrieben werden können, werden unter bestimmten Umständen die internen Meldungen ungeachtet der Einstellung derErrorDocument-Direktive verwendet. Insbesondere bei einer fehlerhaften Anfrage werden der normale Bearbeitungsprozess sofort beendet und die interne Meldung zurückgegeben. Das ist notwendig, um Sicherheitsprobleme zu vermeiden, die auf Grund fehlerhafter Anfragen entstehen.

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

Siehe auch

• Dokumentation zu individuellenFehlermeldungen

ErrorLog-Direktive

Die DirektiveErrorLog bestimmt den Namen der Datei, in welcher der Server alle auftretenden Fehler protokolliert. WennDateiname nicht absolut ist, wird er relativ zuServerRoot betrachtet.

Wenn derDateiname 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.

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

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

Siehe auch

• LogLevel
• Apache-Log-Dateien

ErrorLogFormat-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

Siehe auch

• ErrorLog
• LogLevel
• Apache HTTP Server Log Files

ExtendedStatus-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

FileETag-Direktive

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

INode

Die I-Node-Nummer wird in die Berechnung mit einbezogen

MTime

Datum und Uhrzeit der letzten Änderung werden mit einbezogen

Size

Die Anzahl der Bytes in der Datei wird mit einbezogen

All

Alle verfügbaren Angaben werden verwendet. Die ist gleichbedeutend mit:

FileETag INode MTime Size

None

Es wird keineETag-Angabe in die Antwort eingefügt, wenn dem Dokument eine Datei zugrundeliegt.

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

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

<Files>-Direktive

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

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

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

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

Siehe auch

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

<FilesMatch>-Direktive

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

auf die gebräuchlichsten Grafikformate im Internet passen.

Siehe auch

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

FlushMaxPipelined-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

FlushMaxThreshold-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

ForceType-Direktive

Wenn sie innerhalb einer.htaccess-Datei, eines<Directory>-,<Location>-<Files>-Containers angegeben wird, erzwingt die Direktive die Auslieferung aller entsprechenden Dateien mit dem Content-Type, der durchMIME-Type definiert wurde. Wenn Sie zum Beispiel ein Verzeichnis voller GIF-Dateien haben, die Sie nicht alle durch.gif kennzeichnen wollen, können Sie angeben:

Beachten Sie bitte, dass die Direktive anders alsDefaultType alle MIME-Type-Zuordnungen überschreibt, einschließlich Dateiendungen, die einen Medientyp bezeichnen könnten.

Sie können jedeForceType-Angabe durch die Verwendung des WertesNone überschreiben:

GprofDir-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

HostnameLookups-Direktive

Diese Direktive aktiviert die DNS-Abfrage(Anm.d.Ü.: ein sogenannter DNS-Lookup), so dass Hostnamen protokolliert (und inREMOTE_HOST an CGIs/SSIs übergeben) werden könnnen. Der WertDouble 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 diesPARANOID genannt.)

Unabhängig von der Einstellung wird ein Double-Reverse-Lookup durchgeführt, wennmod_authz_host zur Zugriffskontrolle per Hostnamen eingesetzt wird. Dies ist aus Sicherheitsgründen notwendig. Beachten Sie, dass das Ergebnis dieses Double-Reverse-Lookups nicht generell verfügbar ist, solange Sie nichtHostnameLookups Double setzen. Wenn beispielsweise nurHostnameLookups On angegeben ist und eine Anfrage für ein Objekt erfolgt, welches durch Hostnamen-Beschränkungen geschützt ist, dann wird CGIs nur das Ergebnis des Singel-Reverse-Lookups inREMOTE_HOST übergeben, egal ob das Doble-Reverse-Lookup fehlschlug oder nicht.

Die Voreinstellung istOff, 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 aufOfflassen. Das Hilfsprogrammlogresolve, das standardmäßig in das Unterverzeichnisbin Ihres Installationsverzeichnisses kompiliert wird, kann dazu verwendet werden, um offline Hostnamen von protokollierten IP-Adressen nachzuschlagen.

HttpProtocolOptions-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

<If>-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

Siehe auch

• Expressions in Apache HTTP Server,for a complete reference and more examples.
• <ElseIf>
• <Else>
• How <Directory>, <Location>, <Files> sections work for an explanation of how these different sections are combined when a request is received.<If>,<ElseIf>, and<Else> are applied last.

<IfDefine>-Direktive

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

In der<IfDefine>-Anweisung kannTest eine von zwei Formen annehmen:

• Parametername
• !Parametername

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

Das ArgumentParametername ist ein sogenanntes "Define", das beim beim Start des Servers in derhttpd-Befehlszeile durch-DParameter angegeben wird.

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

<IfDirective>-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

Siehe auch

• <IfSection>

<IfFile>-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

<IfModule>-Direktive

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

In der<IfModule>-Anweisung kannTest eine von zwei Formen annehmen:

• Modul
• !Modul

Im ersten Fall werden die Direktiven zwischen der Start- und Endemarkierung nur ausgeführt, das Modul namensModul im Apache enthalten ist -- entweder einkompiliert oder mittelsLoadModule dynamisch geladen. Die zweite Form dreht den Test um und führt die Direktiven nur aus, wennModulnicht enthalten ist.

Das ArgumentModul kann entweder der Modulbezeichner oder der Dateiname des Moduls zum Zeitpunkt seiner Kompilierung sein.rewrite_module beispielsweise ist der Bezeichner undmod_rewrite.c ist der Dateiname. Wenn ein Modul aus mehreren Quelltext-Dateien besteht, verwenden Sie den Namen der Datei, welche die ZeichenfolgeSTANDARD20_MODULE_STUFF enthält.

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

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

<IfSection>-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

Siehe auch

• <IfDirective>

Include-Direktive

Die Direktive erlaubt das Einfügen anderer Konfigurationsdateien in die Konfigurationsdatei des Servers.

Shell-typische (fnmatch()) Platzhlaterzeichen können dazu verwendet werden, mehrere Dateien auf einmal in alphabetischer Reihenfolge einzufügen. WennInclude 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, washttpd scheitern lassen kann.

Der angegebene Dateiname kann ein absoluter Pfad sein oder relativ zumServerRoot-Verzeichnis angegeben werden.

Beispiele:

Oder Sie geben Pfade relativ zu IhremServerRoot-Verzeichnis an:

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

Siehe auch

• apachectl

IncludeOptional-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

Siehe auch

• Include
• apachectl

KeepAlive-Direktive

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 SieKeepAlive On.

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

Siehe auch

• MaxKeepAliveRequests

KeepAliveTimeout-Direktive

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 DirektiveTimeout festgelegte Auszeit angewendet.

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

<Limit>-Direktive

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

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

Sie können eine oder mehrere der folgenden Methoden angeben:GET,POST,PUT,DELETE,CONNECT,OPTIONS,PATCH,PROPFIND,PROPPATCH,MKCOL,COPY,MOVE,LOCK undUNLOCK.Die Methodennamen unterscheiden zwischen Groß- und Kleinschreibung. WennGET verwendet wird, sindHEAD-Anfragen ebenfalls eingeschränkt. DieTRACE-Methode kann nicht limitiert werden.

<LimitExcept>-Direktive

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

Beispiel:

LimitInternalRecursion-Direktive

Eine interne Umleitung erfolgt beispielsweise, wenn die DirektiveAction verwendet wird, welche die Originalanfrage intern zu einem CGI-Skript weiterleitet. Eine Unteranfrage(Anm.d.Ü.: engl. Subrequest) ist ein Mechanismus des Apache, um herauszufinden, was bei einer URI geschehen würde, wäre sie angefordert worden.mod_dir z.B. verwendet Unteranfragen, um nach den Dateien zu suchen, die in derDirectoryIndex-Anweisung aufgeführt sind.

LimitInternalRecursion bewahrt den Server vor einem Absturz, wenn er in eine Endlosschleife aus internen Umleitungen oder Unteranfragen hineinläuft. Derartige Schleifen werden gewöhnlich durch Fehlkonfiguration verursacht.

Die Direktive setzt zwei verschiedene Begrenzungen, welche je Anfrage ausgewertet werden. Die ersteZahl bestimmt die maximale Anzahl der Umleitungen, die aufeinander folgen dürfen. Die zweiteZahl legt fest, wie tief Unteranfragen ineinander verschachtelt werden dürfen. Wenn Sie lediglich eineZahl angeben, wird sie beiden Begrenzungen zugewiesen.

LimitRequestBody-Direktive

Die Direktive gibt die Anzahl derBytes zwischen 0 (unbegrenzt) und 2147483647 (2GB) an, die im Request-Body (Datenteil der Anfrage) erlaubt sind.

Die DirektiveLimitRequestBody 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 diePUT-Methode angewendet, dann muss der Wert mindestens so groß sein wie irgendeine Darstellungsform, die der Server für diese Ressource akzeptieren soll.

Die Direktive gibt dem Serveradministrator eine größere Kontrolle gegenüber abnormalem Verhalten von Clients, was bei der Vermeidung einiger Formen von Denial-of-Service-Attacken hilfreich sein kann.

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

LimitRequestFields-Direktive

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

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

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

Beispiel:

LimitRequestFieldSize-Direktive

Die Direktive gibt die Anzahl derBytes an, die in einem HTTP-Header erlaubt sind.

Die DirektiveLimitRequestFieldsize erlaubt es dem Serveradministrator, die maximale Größe eines HTTP-Request-Headers zu verringern oder erhöhen. Für den Server muss der Wert groß genug sein, um eine beliebige Headerzeile einer normalen Client-Anfrage vorzuhalten. Die Größe variiert stark zwischen den verschiedenen Client-Ausführungen, oft abhängig vom Ausmaß, mit dem der Anwender die genaue Content-Negotiation-Unterstützung seines Browsers konfiguriert hat. SPNEGO-Authentisierungs-Header können bis zu 12392 Bytes lang sein.

Die Direktive gibt dem Serveradministrator eine größere Kontrolle gegenüber abnormalem Verhalten von Clients, was bei der Vermeidung einiger Formen von Denial-of-Service-Attacken hilfreich sein kann.

Beispiel:

LimitRequestLine-Direktive

Die Direktive legt die Anzahl derBytes fest, die in der HTTP-Anfragezeile erlaubt sind.

Die DirektiveLimitRequestLine 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 dieLimitRequestLine-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 einerGET-Anfrage übergeben werden können.

Die Direktive gibt dem Serveradministrator eine größere Kontrolle gegenüber abnormalem Verhalten von Clients, was bei der Vermeidung einiger Formen von Denial-of-Service-Attacken hilfreich sein kann.

Beispiel:

LimitXMLRequestBody-Direktive

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

Beispiel:

<Location>-Direktive

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

<Location>-Abschnitte operieren vollständig außerhalb des Dateisystems. Dies hat mehrere Konsequenzen. An Wichtigsten,<Location>-Anweisungen sollten nicht dafür verwendet werden, den Zugriff zu Teilen des Dateisystems zu steuern. Da mehrere unterschiedliche URLs auf die gleiche Stelle des Dateisystems zeigen können, könnte eine solche Zugriffskontrolle u.U. umgangen werden.

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

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

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

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

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

Siehe auch

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

<LocationMatch>-Direktive

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

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

Siehe auch

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

LogLevel-Direktive

LogLevel stellt die Ausführlichkeit der Nachrichten ein, die im Fehlerprotokoll aufgezeichnet werden (siehe DirektiveErrorLog). Die folgenden, nach absteigender Aussagekraft sortiertenLevel sind verfügbar:

Geben Sie einen bestimmten Level an, denn werden Nachrichten von allen höheren Leveln ebenso angezeigt.Z.B.: WennLogLevel info eingestellt ist, dann werden Nachrichten der Log-Levelnotice undwarn ebenso eingetragen.

Es wird empfohlen, mindestens den Levelcrit zu verwenden.

Beispiel:

MaxKeepAliveRequests-Direktive

Die DirektiveMaxKeepAliveRequests begrenzt die Anzahl der Anfragen, die pro Verbindung zulässig sind, wennKeepAlive eingeschaltet ist. Bei der Einstellung0 sind unbegrenzt viele Anfragen erlaubt. Wir empfehlen für diese Einstellung einen hohen Wert für eine maximale Serverleistung.

Beispiel:

MaxRangeOverlaps-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

MaxRangeReversals-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

MaxRanges-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

MergeSlashes-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

MergeTrailers-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

Mutex-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

NameVirtualHost-Direktive

Die DirektiveNameVirtualHost ist erforderlich, wenn Sienamensbasierte virtuelle Hosts konfigurieren möchten.

ObwohlAdresse eine Hostname sein kann, wird empfohlen, dass Sie stets eine IP-Adresse verwenden, z.B.:

Mit derNameVirtualHost-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.

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

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

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

Siehe auch

• Dokumentation zu virtuellen Hosts

Options-Direktive

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

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

All

Alle Optionen außerMultiViews. Dies ist die Voreinstellung.

ExecCGI

Die Ausführung von CGI-Skripten, welchemod_cgi verwenden, ist erlaubt.

FollowSymLinks

Der Server folgt symbolischen Links in diesem Verzeichnis.

Auch wenn der Server symbolischen Links folgt, bedeutet diesnicht, dass der zum Abgleich gegen<Directory>-Abschnitte verwendete Pfadname wechselt.

Beachten Sie auch, dass diese Option innerhalb eines<Location>-Abschnittsignoriert wird.

Includes

Server Side Includes, die vonmod_include bereitgestellt werden, sind erlaubt.

IncludesNOEXEC

Server Side Includes sind erlaubt,#exec cmd und#exec cgi sind jedoch deaktiviert. Es ist aber noch möglich, CGI-Skripte ausScriptAlias-Verzeichnissen mittels#include virtual einzubinden.

Indexes

Wenn eine URL, die auf ein Verzeichnis zeigt, in dem sich keine durchDirectoryIndex definierte Indexdatei (z.B.index.html) befindet, dann liefertmod_autoindex eine formatierte Auflistung des Verzeichnisses zurück.

MultiViews

"MultiViews" sind bei der Verwendung vonmod_negotiation erlaubt (sieheContent-Negotiation).

SymLinksIfOwnerMatch

Der Server folgt nur symbolischen Links, bei denen die Zieldatei bzw. das Zielverzeichnis der gleichen Benutzerkennung gehört, wie der Link.

Anmerkung

Diese Option wird innerhalb eines<Location>-Abschnitts ignoriert.

Wenn mehrereOptions auf ein Verzeichnis angewandt werden können, dann wird normalerweise die spezifischste(Anm.d.Ü.: Gemeint ist die zuletzt ausgeführte Option.) verwendet und alle anderen werden ignoriert; die Optionen werden nicht vermischt. (Siehe auchWie Abschnitte zusammengeführt werden..) Wenn jedochallen Optionen derOptions-Anweisung eines der Zeichen+ oder- vorangestellt wird, werden die Optionen zusammengemischt. Jede Option mit vorangestelltem+ wird zu den momentan gültigen Optionen hinzugefügt und jede Option mit vorangestelltem- wird aus den derzeit gültigen Optionen entfernt.

So wird zum Beispiel ohne die Zeichen+ und-

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

dann würden die OptionenFollowSymLinks undIncludes für das Verzeichnis/web/docs/spec gesetzt.

Die Voreinstellung istAll, sofern keine anderen Angaben gemacht wurden.

Protocol-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

Siehe auch

• AcceptFilter
• Listen

Protocols-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

Siehe auch

• ProtocolsHonorOrder

ProtocolsHonorOrder-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

Siehe auch

• Protocols

QualifyRedirectURL-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

ReadBufferSize-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

RegexDefaultOptions-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

RegisterHttpMethod-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

Siehe auch

• HTTPProtocolOptions
• AllowMethods

RLimitCPU-Direktive

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 odermax sein.max zeigt dem Server an, dass das vom Betriebssystem erlaubte Maximum verwendet werden soll. Das Anheben der maximal erlaubten Ressourcennutzung erfordert, dass der Server alsroot läuft, zumindest in der anfänglichen Startphase.

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

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

Siehe auch

• RLimitMEM
• RLimitNPROC

RLimitMEM-Direktive

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 odermax sein.max zeigt dem Server an, dass das vom Betriebssystem erlaubte Maximum verwendet werden soll. Das Anheben der maximal erlaubten Ressourcennutzung erfordert, dass der Server alsroot läuft, zumindest in der anfänglichen Startphase.

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

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

Siehe auch

• RLimitCPU
• RLimitNPROC

RLimitNPROC-Direktive

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 odermax sein.max zeigt dem Server an, dass das vom Betriebssystem erlaubte Maximum verwendet werden soll. Das Anheben der maximal erlaubten Ressourcennutzung erfordert, dass der Server alsroot läuft, zumindest in der anfänglichen Startphase.

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

Prozessbegrenzungen steuern die Anzahl der Prozesse pro Benutzer.

Siehe auch

• RLimitMEM
• RLimitCPU

ScriptInterpreterSource-Direktive

Die Direktive steuert, wie der Apache den Interpreter zur Ausführung von CGI-Skripten bestimmt. Die Voreinstellung istScript. Dies veranlaßt den Apache, den Interpreter zu verwenden, auf den die Shebang-Zeile (erste Zeile, beginnt mit#!) im Skript zeigt. Auf Win32-Systemen sieht diese Zeile üblicherweise so aus:

oder, wennperl im Pfad (UmgebungsvariablePATH) liegt, einfach:

Die EinstellungScriptInterpreterSource Registry veranlaßt eine Suche inHKEY_CLASSES_ROOT der Windows-Registrierungsdatenbank und verwendet die Endung der Skript-Datei (z.B..pl) als Suchargument. Der durch den UnterschlüsselShell\ExecCGI\Command oder, falls dieser nicht existiert,Shell\Open\Command definierte Befehl wird zum Öffnen der Skript-Datei verwendet. Wenn der Schlüssel zur Dateiendung oder beide Unterschlüssel fehlen, dann verwendet der Apache die OptionScript.

Die seit Apache 2.0 neue OptionRegistry-Strict macht das gleiche wieRegistry, verwendet jedoch nur den UnterschlüsselShell\ExecCGI\Command. Der SchlüsselExecCGI ist gewöhnlich nicht voreingestellt. Er muss manuell eingerichtet werden und schützt Ihr System so for versehentlichen Programmaufrufen.

SeeRequestTail-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

ServerAdmin-Direktive

ServerAdmin legt die Kontaktadresse fest, die der Server in jede Fehlermeldung einfügt, die er an den Client zurückschickt. Wennhttpd das übergebene Argument nicht als URL erkennt, nimmt er an, dess es sich um eineE-Mail-Adresse handelt und stellt in Hyperlinksmailto: voran. Es ist jedoch sogar sinnvoll, eine E-Mail-Adresse zu verwenden, da viele CGI-Skripte davon ausgehen. Wenn Sie eine URL verwenden möchten, sollten Sie auf einem anderen unter Ihrer Kontrolle stehenden Server verweisen. Andernfalls können Besucher Sie im Fehlerfall möglicherweise nicht kontaktieren.

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

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

ServerAlias-Direktive

Die DirektiveServerAlias bestimmt die alternativen Namen eines Hosts zur Verwendung mitnamensbasierten virtuellen Hosts.

Siehe auch

• Apache-Dokumentation zu virtuellen Hosts

ServerName-Direktive

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

Wenn keinServerName angegeben wurde, dann versucht der Server den Rechnernamen mittels eines Reverse-Lookup herzuleiten. Wenn kein Port in derServerName-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 DirektiveServerName verwenden.

Wenn Sienamensbasierte virtuelle Hosts verwenden, gibtServerName innerhalb eines<VirtualHost>-Abschnitts an, welcher Hostname imHost:-Header der Anfrage auftauchen muss, damit sie diesem virtuellen Host zugeordnet wird.

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

Siehe auch

• Probleme bezüglich DNS undApache
• Apache-Dokumentation zu virtuellen Hosts
• UseCanonicalName
• UseCanonicalPhysicalPort
• NameVirtualHost
• ServerAlias

ServerPath-Direktive

Die DirektiveServerPath legt den veralteten(Anm.d.Ü.: Gemeint ist eigentlich "Altlast" aufgrund antiquierter Clients.) URL-Pfad eines Hosts zur Verwendung mitnamensbasierten virtuellen Hosts fest.

Siehe auch

• Apache-Dokumentation zu virtuellen Hosts

ServerRoot-Direktive

Die DirektiveServerRoot bestimmt das Verzeichnis, in dem der Server installiert ist. Üblicherweise enthält es die Unterverzeichnisseconf/ undlogs/. Relative Pfadangaben anderer Direktiven (wie z.B.Include oderLoadModule) werden relativ zu diesem Verzeichnis betrachtet.

Siehe auch

• Diehttpd-Option-d
• Sicherheitshinweise für Informationen, wie die Rechte auf dasServerRoot-Verzeichnis richtig gesetzt werden

ServerSignature-Direktive

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

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

Ab Version 2.0.44 werden die Details der angegebenen Versionsnummer des Servers von der DirektiveServerTokens kontrolliert.

Siehe auch

• ServerTokens

ServerTokens-Direktive

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

ServerTokens Prod[uctOnly]

Der Server sendet (z.B.):Server: Apache

ServerTokens Major

Der Server sendet (z.B.):Server: Apache/2

ServerTokens Minor

Der Server sendet (z.B.):Server: Apache/2.0

ServerTokens Min[imal]

Der Server sendet (z.B.):Server: Apache/2.0.41

ServerTokens OS

Der Server sendet (z.B.):Server: Apache/2.0.41 (Unix)

ServerTokens Full (oder nicht angegeben)

Der Server sendet (z.B.):Server: Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2

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

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

Siehe auch

• ServerSignature

SetHandler-Direktive

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

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

Sie können eine zuvor definierteSetHandler-Anweisung aufheben, indem Sie den WertNone verwenden.

Hinweis: SetHandler setzt die Standard-Handler außer Kraft und unterdrückt gewohnte Verhaltensweisen, wie beispielsweise die Behandlung von URLs, die auf einen Schrägstrich (/) enden als Verzeichnisse oder (die Auslieferung von) Index-Dateien.

Siehe auch

• AddHandler

SetInputFilter-Direktive

Die DirektiveSetInputFilter 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 DirektiveAddInputFilter.

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

Siehe auch

• Filter-Dokumentation

SetOutputFilter-Direktive

Die DirektiveSetOutputFilter 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 DirektiveAddOutputFilter.

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

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

Siehe auch

• Filter-Dokumentation

StrictHostCheck-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

TimeOut-Direktive

Die DirektiveTimeOut definiert derzeit die Zeitspanne, die der Apache auf drei Dinge wartet:

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

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

TraceEnable-Direktive

Diese Direktive beeinflusst das Verhalten vonTRACE sowohl für den Server selbst als auchmod_proxy. Die VoreinstellungTraceEnable on erlaubtTRACE-Anfragen gemäß RFC 2616. Dort werden nur Anfragen ohne Datenteil zugelassen.TraceEnable off sorgt dafür, dass der Serverkern undmod_proxy den Fehler405 (Zugriffsmethode nicht erlaubt) an den Client senden.

Zu Test- und Diagnosezwecken können Sie auch nicht-standardkonforme Anfragen mit Datenteil erlauben, indem Sie die DirektiveTraceEnable extended verwenden. Der Server (als Ursprungsserver) beschränkt den Anfrageinhalt auf 64k. (WennTransfer-Encoding: chunked benutzt wird, können weitere 8k für die Chunk-Kopfzeilen verwendet werden.) Der Server selbst reflektiert dann die vollständigen HTTP- und Chunk-Kopfzeilen in seiner Antwort. Die Einschränkung auf 64k gilt nicht, wenn der Server als Proxy arbeitet.

UNCList-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

UnDefine-Direktive

Die Dokumentation zu dieser Direktive wurde noch nicht übersetzt. Bitte schauen Sie in die englische Version.

Siehe auch

• Define
• IfDefine

UseCanonicalName-Direktive

In vielen Situationen muss der Apache eineselbstreferenzierende URL -- d.h. eine URL, die auf den selben Server zurück verweist -- zusammenbauen. BeiUseCanonicalName On verwendet der Apache den Hostnamen und Port, der in derServerName-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 vonSERVER_NAME undSERVER_PORT verwendet.

BeiUseCanonicalName Off bildet der Apache selbstreferenzierende URLs, indem er den vom Client übermittelten Hostnamen und Port verwendet, sofern diese vorhanden sind (andernfalls wird der kanonische Name, wie oben beschrieben, benutzt). Die Werte sind die gleichen, die zur Anwendung vonnamensbasierten virtuellen Hosts verwendet werden, und sie sind mit den gleichen Clients verfügbar(Anm.d.Ü.: , die auch in der Lage sind, auf namensbasierte virtuelle Hosts zuzugreifen, d.h. einenHost-Header mitschicken). Die CGI-VariablenSERVER_NAME undSERVER_PORT werden ebenfalls aus den vom Client angeboten Werten erstellt.

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

Es existiert noch eine dritte Option,UseCanonicalName DNS, die für den Betrieb von IP-basierten Massen-Virtual-Hosts gedacht ist, um antiquierte Clients zu unterstützen, die keinenHost:-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.

Siehe auch

• ServerName
• Listen

UseCanonicalPhysicalPort-Direktive

In vielen Situationen muss der Apache eineselbstreferenzierende URL zusammenbauen, d.h. eine URL, die auf den selben Server zurück verweist. Wenn der Apache für dieUseCanonicalName-Direktive den Port bestimmt, wird mitUseCanonicalPhysicalPort On die tatsächlich für die Anfrage verwendete physische Portnummer in Betracht gezogen. MitUseCanonicalPhysicalPort Off verläßt sich der Apache nur auf die Konfiguration, um eine gültige Portnummer zu bestimmen und läßt die physische Portnummer außer acht.

Siehe auch

• UseCanonicalName
• ServerName
• Listen

<VirtualHost>-Direktive

<VirtualHost> und</VirtualHost> werden dazu verwendet, eine Gruppe von Direktiven zusammenzufassen, die nur auf einen bestimmten virtuellen Host angewendet werden. Jede Direktive, die im Virtual-Host-Kontext zulässig ist, kann verwendet werden. Wenn der Server eine Anfrage für ein bestimmtes Dokument eines bestimmten virtuellen Hosts empfängt, dann benutzt er die im<VirtualHost>-Container enthaltenen Konfigurationsanweisungen.Adresse kann sein:

• Die IP-Adresse des virtuellen Hosts.
• Ein voll qualifizierter Domainname für die IP-Adresse des virtuellen Hosts.
• Das Zeichen*, welches nur in Kombination mitNameVirtualHost * verwendet wird, um allen IP-Adressen zu entsprechen.
• Die Zeichenkette_default_, die nur mit IP-basierten virtuellen Hosts verwendet wird, um nicht zugewiesene IP-Adressen aufzufangen.

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

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 Befehlifconfig alias durchgeführt werden -- sofern Ihr Betriebssystem das unterstützt).

Bei der Verwendung IP-basierter virtuellen Hosts kann der spezielle Name_default_ benutzt werden. In diesem Fall weist der Apache jede IP-Adresse diesem virtuellen Host zu, die nicht explizit in einem anderen virtuellen Host angegeben ist. Falls kein virtueller Host_default_ angegeben ist, wird die "Hauptserver"-Konfiguration, die aus allen Definitionen außerhalb der Virtual-Host-Abschnitte besteht, für nicht passende IPs verwendet. (Beachten Sie jedoch, dass eine IP-Adressen die zu einerNameVirtualHost-Anweisung passt, weder den "Hauptserver" noch den virtuellen Host_default_ verwendet. Lesen Sie für weitere Details die Dokumentation zunamensbasierten virtuell Hosts.)

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

Siehe auch

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