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
