XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
This file is generated from xml source: DO NOT EDIT
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-->
Upgrade von 1.3 auf 2.0 - Apache HTTP Server
Module | Direktiven | FAQ | Glossar | Seitenindex
Apache HTTP Server Version 2.0
Apache > HTTP-Server > Dokumentation > Version 2.0Upgrade von 1.3 auf 2.0
Verf黦bare Sprachen: de |
en |
es |
fr |
ja |
ko |
ru
Dieses Dokument dient der Unterst黷zung beim Upgrade. Es
enth鋖t die entscheidenden Informationen f黵 bisherige
Apache-Nutzer. Diese sind als kurze Anmerkungen
gedacht. Weitere Informationen finden Sie entweder unter
Neue Funktionen oder in
den src/CHANGES-Dateien.
膎derungen der Konfiguration bei der Kompilierung
膎derungen der Laufzeit-Konfiguration
Sonstige 膎derungen
Module von Drittanbietern
Siehe auch躡ersicht der neuen Funktionen
in Apache 2.0
膎derungen der Konfiguration bei der Kompilierung
Der Apache benutzt jetzt ein autoconf- und
libtool-System zur Konfiguration des
Erstellungsverfahrens. Die Verwendung dieses Systems ist
鋒nlich, aber nicht identisch mit dem APACI-System des
Apache 1.3.
Zus鋞zlich zu der 黚lichen Auswahl von Modulen, die
kompiliert werden sollen, wurde der Hauptteil der
Request-Verarbeitung im Apache 2.0 in die
Multi-Processing-Module (MPMs) verschoben.
膎derungen der Laufzeit-Konfiguration
Viele Anweisungen aus dem Serverkern des Apache 1.3 sind
jetzt in den MPMs enthalten. Wenn Sie ein Serververhalten
w黱schen, das demjenigen des Apache 1.3 m鰃lichst
鋒nlich ist, sollten Sie das prefork-MPM
ausw鋒len. Andere MPMs verwenden abweichende Anweisungen
f黵 die Prozess-Erstellung und Request-Verarbeitung.
Das Proxy-Modul wurde
umgearbeitet, um es auf den Stand von HTTP/1.1 zu bringen. Eine
der bedeutendsten 膎derungen ist die Platzierung der
Proxy-Zugriffskontrolle innerhalb eines <Proxy>-Blocks, statt innerhalb eines
<Directory proxy:>-Blocks.
Die Behandlung von PATH_INFO (hinter dem
tats鋍hlichen Dateinamen angef黦te Pfadangaben) wurde
f黵 einige Module ge鋘dert. Module, die bisher als Handler
implementiert waren, jetzt aber als Filter implementiert sind,
akzeptieren m鰃licherweise keine Requests mit
PATH_INFO mehr. Filter wie INCLUDES oder PHP sind gleich oben im
Core-Handler implementiert und weisen deshalb Requests mit
PATH_INFO ab. Sie k鰊nen die AcceptPathInfo-Direktive
verwenden, um den Core-Handler zu zwingen, Requests mit
PATH_INFO zu akzeptieren, und dadurch die F鋒igkeit
wiederherstellen, PATH_INFO in Server Side Includes zu
benutzen.
Die CacheNegotiatedDocs-Direktive
hat jetzt das Argument an (on) oder aus
(off). Die vorhandenen Anweisungen CacheNegotiatedDocs sollten durch
CacheNegotiatedDocs on ersetzt werden.
Die ErrorDocument-Direktive
verwendet kein Anf黨rungszeichen mehr am Anfang des
Arguments, um eine
Textnachricht anzuzeigen. Stattdessen sollten Sie die
Nachricht in doppelte Anf黨rungszeichen einschlie遝n.
Zum Beispiel sollten existierende Angaben wie
ErrorDocument 403 "Eine Nachricht
durch
ErrorDocument 403 "Eine Nachricht"
ersetzt werden.
Solange das zweite Argument kein g黮tiger URL oder
Pfadname ist, wird es als Textnachricht behandelt.
Die Direktiven AccessConfig und
ResourceConfig sind entfallen.
Diese Direktiven k鰊nen durch die Include-Direktive
ersetzt werden, die eine 鋛uivalente Funktionalit鋞 besitzt.
Wenn Sie die Defaultwerte dieser Direktiven verwendet haben,
ohne sie in die Konfigurationsdateien einzuf黦en, m黶sen Sie
m鰃licherweise Include conf/access.conf und
Include conf/srm.conf zu Ihrer httpd.conf
hinzuf黦en. Um sicherzustellen, da
