home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
PC World 2004 May
/
PCWorld_2004-05_cd.bin
/
komunikace
/
apache
/
apache_2.0.48-win32-x86-no_ssl.msi
/
Data.Cab
/
F252280_upgrading.xml.de
< prev
next >
Wrap
Extensible Markup Language
|
2003-04-23
|
9KB
|
197 lines
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.de.xsl"?>
<!-- English revision: 1.6.2.5 -->
<manualpage metafile="upgrading.xml.meta">
<title>Upgrade von 1.3 auf 2.0</title>
<summary>
<p>Dieses Dokument dient der Unterstützung beim Upgrade. Es
enthält die entscheidenden Informationen für bisherige
Apache-Nutzer. Diese sind als kurze Anmerkungen
gedacht. Weitere Informationen finden Sie entweder unter
<a href="new_features_2_0.html">Neue Funktionen</a> oder in
den <code>src/CHANGES</code>-Dateien.</p>
</summary>
<seealso><a href="new_features_2_0.html">Übersicht der neuen Funktionen
in Apache 2.0</a></seealso>
<section id="compile-time">
<title>Änderungen der Konfiguration bei der Kompilierung</title>
<ul>
<li>Der Apache benutzt jetzt ein <code>autoconf</code>- und
<code>libtool</code>-System zur <a
href="install.html">Konfiguration des
Erstellungsverfahrens</a>. Die Verwendung dieses Systems ist
ähnlich, aber nicht identisch mit dem APACI-System des
Apache 1.3.</li>
<li>Zusätzlich zu der üblichen Auswahl von Modulen, die
kompiliert werden sollen, wurde der Hauptteil der
Request-Verarbeitung im Apache 2.0 in die <a href="mpm.html">
Multi-Processing-Module</a> (MPMs) verschoben.</li>
</ul>
</section>
<section id="run-time">
<title>Änderungen der Laufzeit-Konfiguration</title>
<ul>
<li>Viele Anweisungen aus dem Serverkern des Apache 1.3 sind
jetzt in den MPMs enthalten. Wenn Sie ein Serververhalten
wünschen, das demjenigen des Apache 1.3 möglichst
ähnlich ist, sollten Sie das <module>prefork</module>-MPM
auswählen. Andere MPMs verwenden abweichende Anweisungen
für die Prozess-Erstellung und Request-Verarbeitung.</li>
<li>Das <a href="mod/mod_proxy.html">Proxy-Modul</a> wurde
umgearbeitet, um es auf den Stand von HTTP/1.1 zu bringen. Eine
der bedeutendsten Änderungen ist die Platzierung der
Proxy-Zugriffskontrolle innerhalb eines <directive type="section"
module="mod_proxy">Proxy</directive>-Blocks, statt innerhalb eines
<code><Directory proxy:></code>-Blocks.</li>
<li>Die Behandlung von <code>PATH_INFO</code> (hinter dem
tatsächlichen Dateinamen angefügte Pfadangaben) wurde
für einige Module geändert. Module, die bisher als Handler
implementiert waren, jetzt aber als Filter implementiert sind,
akzeptieren möglicherweise keine Requests mit
<code>PATH_INFO</code> mehr. Filter wie <a
href="mod/mod_include.html">INCLUDES</a> oder <a
href="http://www.php.net/">PHP</a> sind gleich oben im
Core-Handler implementiert und weisen deshalb Requests mit
<code>PATH_INFO</code> ab. Sie können die <directive
module="core">AcceptPathInfo</directive>-Direktive
verwenden, um den Core-Handler zu zwingen, Requests mit
<code>PATH_INFO</code> zu akzeptieren, und dadurch die Fähigkeit
wiederherstellen, <code>PATH_INFO</code> in Server Side Includes zu
benutzen.</li>
<li>Die <directive
module="mod_negotiation">CacheNegotiatedDocs</directive>-Direktive
hat jetzt das Argument an (<code>on</code>) oder aus
(<code>off</code>). Die vorhandenen Anweisungen <directive
>CacheNegotiatedDocs</directive> sollten durch
<code>CacheNegotiatedDocs on</code> ersetzt werden.</li>
<li>
Die <directive module="core">ErrorDocument</directive>-Direktive
verwendet kein Anführungszeichen mehr am Anfang des
Arguments, um eine
Textnachricht anzuzeigen. Stattdessen sollten Sie die
Nachricht in doppelte Anführungszeichen einschließen.
Zum Beispiel sollten existierende Angaben wie
<example>
ErrorDocument 403 "Eine Nachricht
</example>
durch
<example>
ErrorDocument 403 "Eine Nachricht"
</example>
ersetzt werden.
Solange das zweite Argument kein gültiger URL oder
Pfadname ist, wird es als Textnachricht behandelt.
</li>
<li>Die Direktiven <code>AccessConfig</code> und
<code>ResourceConfig</code> sind entfallen.
Diese Direktiven können durch die <directive
module="core">Include</directive>-Direktive
ersetzt werden, die eine äquivalente Funktionalität besitzt.
Wenn Sie die Defaultwerte dieser Direktiven verwendet haben,
ohne sie in die Konfigurationsdateien einzufügen, müssen Sie
möglicherweise <code>Include conf/access.conf</code> und
<code>Include conf/srm.conf</code> zu Ihrer <code>httpd.conf</code>
hinzufügen. Um sicherzustellen, daß der Apache die
Konfigurationsdateien in der gleichen Reihenfolge liest, wie sie von
den älteren Direktiven impliziert wurde, sollten die <directive
module="core">Include</directive>-Direktiven ans Ende der
<code>httpd.conf</code> gestellt werden, wobei die Direktive für
<code>srm.conf</code> derjenigen für <code>access.conf</code>
vorangeht.</li>
<li>Die Direktiven <code>BindAddress</code> und <code>Port</code>
sind entfallen. Eine äquivalente Funktionalität wird von der
flexibleren Direktive <directive
module="mpm_common">Listen</directive> bereitgestellt.</li>
<li>Im Apache 1.3 wurde die <code>Port</code>-Direktive außerdem
dazu verwendet, die Portnummer für
selbstreferenzierende URLs festzulegen.
Die neue <directive module="core">ServerName</directive>-Syntax
stellt das Apache-2.0-Äquivalent dar:
sie wurde dahingehend verändert, sowohl den Hostnamen
<em>als auch</em> die Portnummer für selbstreferenzierende URLs
in einer Direktive angeben zu können.</li>
<li>Die <code>ServerType</code>-Direktive entfällt.
Die Methode zum Bedienen der Requests wird nun durch die Auswahl
des MPM ermittelt. Derzeit ist kein MPM dafür bestimmt, von inetd
gestartet zu werden.</li>
<li>Die Module <code>mod_log_agent</code> und <code>
mod_log_referer</code>, welche die Direktiven <code>AgentLog</code>,
<code>RefererLog</code> und <code>RefererIgnore</code> bereitgestellt
hatten, wurden entfernt. Durch Verwendung der Direktive <directive
module="mod_log_config">CustomLog</directive> aus mod_log_config
sind die Agent- und Refererlogs auch weiterhin verfügbar.</li>
<li>Die Direktiven <code>AddModule</code> und
<code>ClearModuleList</code> sind entfallen.
Diese Direktiven wurden benutzt, um sicherzustellen, daß die
Module in der richtigen Reihenfolge aktiviert werden können.
Die neue Apache 2.0 API erlaubt es Modulen, ihre Reihenfolge
explizit anzugeben, und macht diese Direktiven damit
überflüssig.</li>
<li>Die Direktive <code>FancyIndexing</code> wurde entfernt.
Die gleiche Funktionalität ist nun mit der Option
<code>FancyIndexing</code> der Direktive <directive
module="mod_autoindex">IndexOptions</directive> verfügbar.</li>
<li>Die von <module>mod_negotiation</module> bereitgestellte
Content-Negotiation-Technik MultiViews führt nun eine strengere
Dateierkennung durch. Es wird ausschließlich unter den
<em>aushandelbaren</em> Dateien gewählt. Das bisherige Verhalten
kann jedoch mit der Direktive <directive
module="mod_mime">MultiviewsMatch</directive> wiederhergestellt
werden.</li>
</ul>
</section>
<section id="misc">
<title>Sonstige Änderungen</title>
<ul>
<li>Das Modul <module>mod_auth_digest</module>, das im Apache 1.3
experimentellen Status hatte, ist nun ein Standardmodul.</li>
<li>Das Modul <code>mod_mmap_static</code>, das im Apache 1.3
experimentellen Status hatte, wurde durch das Modul <module
>mod_file_cache</module> ersetzt.</li>
<li>Die Distribution wurde komplett reorganisiert und enthält kein
unabhängiges <code>src</code>-Verzeichnis mehr. Stattdessen wurden
die Quellcodes logisch unterhalb des Hauptverzeichnisses der
Distribution angeordnet. Installationen des kompilierten Servers
sollten in ein separates Verzeichnis erfolgen.</li>
</ul>
</section>
<section id="third-party">
<title>Module von Drittanbietern</title>
<p>An der API des Apache 2.0 wurden umfassende Änderungen
vorgenommen. Bestehende Module, die für die Apache 1.3 API
entwickelt wurden, werden <strong>nicht</strong> ohne Modifikationen mit
der Version 2.0 des Apache zusammenarbeiten. Details sind in der <a
href="developer/">Dokumentation für Entwickler</a> beschrieben.</p>
</section>
</manualpage>