German translation modules.xml

[Jobst Giesecke]

Title: Apache 1.3-Module für Apache 2.0 umwandeln

Dokumentation für Entwickler




Dies ist ein erster Versuch, die Erfahrungen zusammenzufassen, die ich
beim Versuch, das Modul  mod_mmap_static für Apache 2.0
umzuwandeln, gesammelt haben. Ein Anspruch auf Vollständigkeit wird
nicht erhoben und wahrscheinlich ist auch nicht alles korrekt, aber es ist
ein Anfang.




    

Diese Routinen müssen jetzt vom Typ apr_status_t sein
und einen Wert diesen Typs zurückgeben. Normalerweise wird der Wert
APR_SUCCESS zurückgegeben, es sei denn, es muss während
der Bereinigung ein Fehler gemeldet werden. Beachten Sie aber, dass beim
Melden eines Fehlers noch nicht der gesamte Code überprüft und
entsprechend reagiert wird.
    

    

Die Initialisierungsroutinen sollten jetzt umbenannt werden, um deutlicher zu
kennzeichnen, wo Sie sich im gesamten Prozess befinden. Daher wird eine
kleine Änderung von mmap_init zu
mmap_post_config vorgenommen. Die übergebenen Argumente
wurden radikal verändert und sehen jetzt folgendermaßen aus:

      

        
apr_pool_t *p
        
apr_pool_t *plog
        
apr_pool_t *ptemp
        
server_rec *s
      
    

    

Viele Datentypen wurden in die APR
verschoben. Das bedeutet, das bei einigen eine Namensveränderung
vorgenommen wurde (siehe oben). Es folgt eine kurze Liste einiger
Änderungen, die Sie wahrscheinlich vornehmen müssen.

      

        
pool wird zu apr_pool_t
        
table wird zu apr_table_t
      
    




    

Die neue Architektur verwendet eine Reihe von Hooks für Ihre
Funktionsaufrufe. Sie müssen dem Modul über die neue Funktion
static void register_hooks(void) hinzugefügt werden.
Die Funktion ist ganz einfach, wenn Sie erst einmal verstanden haben,
was geschehen muss. Jede Funktion, die in einer bestimmten Phase der
Verarbeitung einer Anfrage aufgerufen werden muss, muss registriert werden,
was für Handler nicht gilt. Es gibt eine Reihe von Phasen, in denen Funktionen
hinzugefügt werden können und für jede Phase können Sie sehr genau die relative
Reihenfolge steuern, in der die Funktion aufgerufen wird.

Der folgende Code wurde dem Modul mod_mmap_static
hinzugefügt:
      
static void register_hooks(void)
{
    static const char * const aszPre[]={ "http_core.c",NULL };
    ap_hook_post_config(mmap_post_config,NULL,NULL,HOOK_MIDDLE);
    ap_hook_translate_name(mmap_static_xlat,aszPre,NULL,HOOK_LAST);
};
      

Damit werden zwei aufzurufende Funktionen registriert, von denen ein in
der post_config-Phase (die von nahezu jedem Modul
benötigt wird) und eine in der translate_name-Phase aufgerufen
wird. Beachten Sie, dass es zwar unterschiedliche Funktionsnamen gibt,
das Format aber identisch ist. Wie sieht das Format aus?

      
        ap_hook_Phasen_Name(Funktionsname,
        Vorgänger, Nachfolger, Position);
      

Drei Hook-Positionen werden definiert...

      

        
HOOK_FIRST
        
HOOK_MIDDLE
        
HOOK_LAST
      

Für die Definition der Position benutzen Sie die Position und ändern Sie dann
mit den Vorgängern und Nachfolgern. Jeder der Modifizierer kann eine Liste von
Funktionen sein, die aufgerufen werden sollten, entweder vor oder
nach Ausführung der Funktion (Vorgänger oder Nachfolger).

Beim Modul mod_mmap_static blieb die
post_config-Phase unberücksichtigt, aber
bei mmap_static_xlat  muss sie
aufgerufen werden, nachdem das core-Modul die
Namensumwandlung durchgeführt hat, daher die Verwendung von
aszPre für die Definition eines Modifizierers für die Position
HOOK_LAST.
    

    

Es gibt noch eine Reihe weiterer Phasen, die Sie bei der Moduldefinition
berücksichtigen müssen. Die alte Definition sah folgendermaßen aus:

      
module MODULE_VAR_EXPORT module_name_module =
{
    STANDARD_MODULE_STUFF,
    /* Initialisierer */
    /* Erzeugen der Verzeichniskonfiguration */
    /* Verzeichnisvermischung --- die Vorgabe ist zu überschreiben */
    /* Serverkonfiguration */
    /* Vermischen der Serverkonfiguration */
    /* Befehls-Handler */
    /* Handler */
    /* Dateinamensumwandlung */
    /* check_user_id */
    /* Authentifizierungsüberprüfung */
    /* Zugriffsüberprüfung */
    /* type_checker */
    /* Aufräumen */
    /* Registrierungseinrichtung */
    /* Header-Parser */
    /* child_init */
    /* child_exit */
    /* Leseanforderung senden */
};
      

Die neue Struktur ist um einiges einfacher...
      
module MODULE_VAR_EXPORT module_name_module =
{
    STANDARD20_MODULE_STUFF,
    /* Erzeugen der Verzeichniskonfigurations-Strukturen */
    /* Vermischen der Verzeichniskonfigurations-Strukturen */
    /* Erzeugen der Serverkonfigurations-Strukturen */
    /* Vermischen der Serverkonfigurations-Strukturen  */
    /* Befehls-Handler */
    /* Handler */
    /* Registrieren der Hooks */
};
      

Einiges lässt sich direkt übertragen, anderes nicht. Eine Zusammenfassung
dessen, was geschehen sollte, folgt weiter unten.

Die Phasen, die sich übertragen lassen:

      

        
/* Erzeugen der Verzeichniskonfiguration */
        
/* Erzeugen der Verzeichniskonfigurations-Strukturen */

        
/* Serverkonfiguration */
        
/* Erzeugen der Serverkonfigurations-Strukturen */

        
/* Verzeichnisvermischung */
        
/* Vermischen der Verzeichniskonfigurations-Strukturen */

        
/* Vermischen der Serverkonfiguration */
        
/* Vermischen der Serverkonfigurations-Strukturen */

        
/* Befehlstabelle */
        
/* Befehlstabelle apr_table_t */

        
/* Handler */
        
/* Handler */
      

Die verbleibenden alten Funktionen sollten als Hooks registriert werden.
Bisher sind folgende Hook-Phasen definiert...

      

        
ap_hook_post_config
        
Hier werden die alten _init-Routinen registriert.

        
ap_hook_http_method
        
Die HTTP-Methode einer Anfrage ermitteln (herkömmlich).

        
ap_hook_open_logs
        
Öffnen angegebener Protokolle

        
ap_hook_auth_checker
        
Überprüfen, ob die Ressource eine Autorisierung benötigt.

        
ap_hook_access_checker
        
Überprüfung auf Modul-spezifische Einschränkungen

        
ap_hook_check_user_id
        
Überprüfung der Benutzer-ID und des Passworts

        
ap_hook_default_port
        
Ermitteln des standardmäßigen Ports für den Server

        
ap_hook_pre_connection
        
Erforderliche Vorbereitungen unmittelbar vor der Verarbeitung, aber
        nach dem Akzeptieren.

        
ap_hook_process_connection
        
Ausführen des richtigen Protokolls
        
        
ap_hook_child_init
        
Aufruf, sobald der Kindprozess gestartet ist.

        
ap_hook_create_request
        
??

        
ap_hook_fixups
        
Letzte Möglichkeit für Änderungen vor dem Erzeugen von Inhalt.

        
ap_hook_handler
        
Den Inhalt erzeugen

        
ap_hook_header_parser
        
Untersuchung der Header durch die Module, wird von den meisten
        Modulen nicht benutzt, weil sie hierfür post_read_request
        verwenden.

        
ap_hook_insert_filter
        
Einfügen von Filtern in die Filterkette

        
ap_hook_log_transaction
        
Protokollinformationen zur Anfrage

        
ap_hook_optional_fn_retrieve
        
Ermitteln der als optional registrierten Funktionen

        
ap_hook_post_read_request
        
Wird nach dem Lesen der Anfrage vor weiteren Phasen aufgerufen.

        
ap_hook_quick_handler
        
Wird vor von Cache-Modulen vor der Anfragebearbeitung aufgerufen.

        
ap_hook_translate_name
        
Umwandlung der URI in einen Dateinamen

        
ap_hook_type_checker
        
Ermitteln und/oder Setzen des Dokumenttyps
        
    




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]