[prev in list] [next in list] [prev in thread] [next in thread]
List: apache-docs
Subject: German translation requsts.xml
From: JGiesecke () t-online ! de (Jobst Giesecke)
Date: 2004-02-24 14:56:05
Message-ID: 403B6605.7080408 () t-online ! de
[Download RAW message or body]
["request.xml.de" (text/html)]
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.de.xsl"?>
<manualpage metafile="request.xml.meta">
<parentdocument href="./">Dokumentation für Entwickler</parentdocument>
<title>Anfragebearbeitung durch den Apache 2.0</title>
<summary>
<note type="warning"><title>Warnung</title>
<p>Achtung - dies ist ein kurzer Entwurf, der noch überarbeitet werden muss!</p>
</note>
<p>Zahlreiche Änderungen des Apache 2.0 betreffen die interne
Anfrageverarbeitung. Modulentwickler müssen diese Änderungen kennen, damit
sie die Vorteile dieser Optimierungen und Sicherheitserweiterungen nutzen
können.</p>
<p>Die erste wichtige Änderung betrifft die Mechanismen für Unteranfragen und
Umleitungen. Der Apache 1.3 besaß eine Reihe unterschiedlicher Codepfade
für die Optimierung des Verhaltens bei Unteranfragen oder Umleitungen.
Mit der Einführung von Patches für die Version 2.0 wurden diese Optimierungen
(und das Serververhalten) infolge der Codeduplikation schnell unwirksam.
Alle Codeduplikationen wurden wieder in die Funktion
<code>ap_process_internal_request()</code> verlagert, um eine mangelnde
Synchronisation zu verhindern.</p>
<p>Das bedeutet, dass viel vom vorhandenen Code 'entoptimiert' wurde. Es ist
das vorrangige Ziel des Apache HTTP-Projekts, eine robuste und korrekte
Implementierung des HTTP-Server-RFC zu realisieren. Zu den weiteren Zielen
gehören die Sicherheit, die Skalierbarkeit und die Optimierung. Neue Methoden
sollen den Server optimieren (über die Leistungen des Apache 1.3 hinaus), ohne
anfälligen oder unsicheren Code.</p>
</summary>
<section id="processing"><title>Der Zyklus der Anfragebearbeitung</title>
<p>Alle Anfragen durchlaufen die Routine
<code>ap_process_request_internal()</code> aus der Datei
<code>request.c</code>, auch Unteranfragen und Umleitungen. Übergibt ein
Modul generierte Anfragen nicht an diesen Code, dann muss sich der Entwickler
vergegenwärtigen, dass das Modul durch zukünftige Veränderungen an der
Anfragebearbeitung nicht mehr funktionieren kann.</p>
<p>Um Anfragen zu rationalisieren, kann der Entwickler die angebotenen Hooks
nutzen, um den Zyklus früher zu verlassen oder um die Apache-Hooks
zu umgehen, die irrelevant (und CPU-aufwändig) sind.</p>
</section>
<section id="parsing"><title>Die Phase der Anfrageanalyse</title>
<section id="unescape"><title>Entschlüsselung der URL</title>
<p>Der <code>parsed_uri</code>-Pfad der Anfrage wird nur einmal zu Beginn
der internen Anfragebearbeitung entschlüsselt.</p>
<p>Dieser Schritt wird übergangen, wenn das Flag <code>proxyreq</code>
gesetzt oder das Element <code>parsed_uri.path</code> nicht gesetzt ist.
Das Modul hat keine weitere Kontrolle über diese einmalige Entschlüsselung, eine
fehlgeschlagene oder mehrfache Entschlüsselung der URL wirkt sich
auf die Sicherheit aus.</p>
</section>
<section id="strip"><title>Entfernen von Parent- und This-Elementen aus dem
URI</title>
<p>Alle <code>/../</code>- und <code>/./</code>-Elementwerden von
<code>ap_getparents()</code> entfernt. Auf diese Weise wird dafür gesorgt, dass
der Pfad (nahezu) absolut ist, bevor die Anfragebearbeitung fortgesetzt wird.</p>
<p>Dieser Schritt kann nicht ausgelassen werden.</p>
</section>
<section id="inital-location-walk"><title>ap_location_walk() - 1</title>
<p>Jede Anfrage wird von der Funktion <code>ap_location_walk()</code>
bearbeitet. Damit wird sichergestellt, dass die
<directive type="section" module="core">Location</directive>-Abschnitte
konsistent für alle Anfragen wirksam werden. Handelt es sich um eine interne
Umleitung oder um eine Unteranfrage, können einige oder alle Resultate
von <code>ap_location_walk</code>-Aufrufen vorangegangener oder
übergeordneter Anfragen genutzt werden, so dass dieser Schritt nach der
Verarbeitung der eigentlichen Anfrage generell sehr effizient ist.</p>
</section>
<section id="translate_name"><title>translate_name</title>
<p>In diesem Schritt können Module den Dateinamen ermitteln oder den
angegebenen URI ändern. Das Modul <module>mod_vhost_alias</module>
wandelt beispielsweise den Pfad des URI in den konfigurierten virtuellen Host
um, das Modul <module>mod_alias</module> wandelt den Pfad in einen
Alias-Pfad um und wenn die Anfrage an den Kernel zurückgegeben wird,
wird die <directive module="core">DocumentRoot</directive> der Ressource
der Anfrage vorangestellt.</p>
<p>Verweigern alle Module diese Phase, wird der Fehlercode <code>500</code>
an den Browser zurückgegeben und der Fehler "Umwandlung nicht möglich"
automatisch protokolliert.</p>
</section>
<section id="map_to_storage"><title>Hook: map_to_storage</title>
<p>Nachdem die Datei oder der korrekte URI ermittelt wurde, werden die entsprechenden
Verzeichniskonfigurationen miteinander vermischt. Das Modul
<module>mod_proxy</module> vergleicht und vermischt beispielsweise die
entsprechenden
<directive module="mod_proxy" type="section">Proxy</directive>-Abschnitte.
Ist der URI nichts anderes als eine lokale (nicht Proxy)
<code>TRACE</code>-Anfrage, dann behandelt der Kernel die Anfrage und
gibt <code>DONE</code> zurück. Antwortet kein Modul auf diesen Hook mit
<code>OK</code> oder <code>DONE</code>, führt der Kernel den Dateinamen
der Anfrage noch einmal für die Abschnitte <directive
module="core" type="section">Directory</directive> und <directive
module="core" type="section">Files</directive> aus. Handelt es sich bei dem Dateinamen der
Anfrage nicht um einen absoluten, zulässigen Dateinamen, wird eine Note für die spätere
Beendigung gesetzt.</p>
</section>
<section id="location-walk"><title>ap_location_walk() - 2</title>
<p>Jede Anfrage muss einen zweiten <code>ap_location_walk()</code>-Aufruf
durchlaufen. Damit wird sichergestellt, dass eine umgewandelte Anfrage
immer noch Gegenstand der konfigurierten <directive
module="core" type="section">Location</directive>-Abschnitte ist. Die
Anfrage übernimmt wieder einige oder alle Resultate des oben angeführten
<code>location_walk</code>-Aufrufs, so dass dieser Schritt fast immer
sehr effizient ist, es sei denn, der umgewandelte URI ist einem grundsätzlich
anderen Pfad oder virtuellem Host zugeordnet.</p>
</section>
<section id="header_parser"><title>Hook: header_parser</title>
<p>Die Hauptanfrage bearbeitet dann die Client-Header. Damit werden die
verbleibenden Schritte der Anfragebearbeitung vorbereitet, um die Client-Anfrage
besser bedienen zu können.</p>
</section>
</section>
<section id="security"><title>Die Sicherheitsphase</title>
<p>Muss noch dokumentiert werden. Der Code ist:</p>
<example><pre>
switch (ap_satisfies(r)) {
case SATISFY_ALL:
case SATISFY_NOSPEC:
if ((access_status = ap_run_access_checker(r)) != 0) {
return decl_die(access_status, "check access", r);
}
if (ap_some_auth_required(r)) {
if (((access_status = ap_run_check_user_id(r)) != 0)
|| !ap_auth_type(r)) {
return decl_die(access_status, ap_auth_type(r)
? "check user. No user file?"
: "perform authentication. AuthType not set!",
r);
}
if (((access_status = ap_run_auth_checker(r)) != 0)
|| !ap_auth_type(r)) {
return decl_die(access_status, ap_auth_type(r)
? "check access. No groups file?"
: "perform authentication. AuthType not set!",
r);
}
}
break;
case SATISFY_ANY:
if (((access_status = ap_run_access_checker(r)) != 0)) {
if (!ap_some_auth_required(r)) {
return decl_die(access_status, "check access", r);
}
if (((access_status = ap_run_check_user_id(r)) != 0)
|| !ap_auth_type(r)) {
return decl_die(access_status, ap_auth_type(r)
? "check user. No user file?"
: "perform authentication. AuthType not set!",
r);
}
if (((access_status = ap_run_auth_checker(r)) != 0)
|| !ap_auth_type(r)) {
return decl_die(access_status, ap_auth_type(r)
? "check access. No groups file?"
: "perform authentication. AuthType not set!",
r);
}
}
break;
}</pre>
</example>
</section>
<section id="preparation"><title>Die Vorbereitungsphase</title>
<section id="type_checker"><title>Hook: type_checker</title>
<p>Die Module haben eine Gelegenheit, den URI oder Dateinamen im Vergleich
zur Zielressource zu testen und MIME-Informationen für die Anfrage zu setzen.
Sowohl <module>mod_mime</module> als auch
<module>mod_mime_magic</module> benutzen diese Phase für einen Vergleich
des Dateinamens oder Inhalts mit der vom Administrator vorgenommenen
Konfiguration und setzen den Inhaltstyp, die Sprache, den Zeichensatz und den
Anfrage-Handler. Einige Module können zu diesem Zeitpunkt ihre Filter oder
andere Parameter für die Anfragebearbeitung setzen.</p>
<p>Verweigern alle Module diese Phase, wird der Fehlercode <code>500</code>
an den Browser zurückgegeben und der Fehler "Typen nicht gefunden"
automatisch ins Fehlerprotokoll geschrieben.</p>
</section>
<section id="fixups"><title>Hook: Fixup-Phase</title>
<p>Viele Module werden in einigen der oben aufgeführten Phasen 'beschnitten'.
In Fixup-Phase stellen die Module ihre Eigentümerschaft wieder her oder sorgen für
die entsprechenden Werte in den Header-Feldern der Anfrage. Dies ist nicht
unbedingt das sauberste Verfahren, ist aber oft die einzige Option.</p>
</section>
</section>
<section id="handler"><title>Die Handler-Phase</title>
<p>Diese Phase ist <strong>nicht</strong> Betsandteil der Verarbeitung
durch <code>ap_process_request_internal()</code>. Viele Module bereiten
eine oder mehrere Unteranfragen vor dem Erzeugen von Inhalten vor. Nachdem
der Kernel oder ein anderes Modul <code>ap_process_request_internal()</code>
aufgerufen hat, wird <code>ap_invoke_handler()</code> aufgerufen, um
die Anfrage zu erzeugen.</p>
<section id="insert_filter"><title>Hook: insert_filter</title>
<p>Module, die den Inhalt in irgendeiner Form umwandeln, können ihre
Werte einfügen und vorhandene Filter überschreiben. Hat der Benutzer außerhalb
der Reihenfolge einen etwas erweiterten Filter konfiguriert, dann kann das Modul
daher die Reihenfolge nach Bedarf ändern. Es gibt keinen Ergebniscode, deshalb
sollte den Aktionen in diesem Hook besser unterstellt werden, dass er immer
erfolgreich ist.</p>
</section>
<section id="hook_handler"><title>Hook: Handler</title>
<p>Abschließend hat das Modul die Möglichkeit, die Anfrage über den
Handler-Hook zu bedienen. Beachten Sie, dass nicht jede vorbereitete Anfrage
an den Handler-Hook gesendet wird. Viele Module wie zum Beispiel
<module>mod_autoindex</module> erzeugen für einen angegebenen URI
Unteranfragen, die niemals bedient werden, sondern sie nur für den Benutzer
aufführen. Denken Sie daran, den erforderlichen Abbau der oben angeführten
Hooks nicht in dieses Modul einzubinden, sondern Poolbereinigungen für den
Anfragepool zu registrieren, um Ressourcen wie erforderlich freizugeben.</p>
</section>
</section>
</manualpage>
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic