German translation ebcdic.xmle.de

[Jobst Giesecke]

Title: Der EBCDIC-Port des Apache

Plattform-spezifische Anmerkungen

Warnung: Dieses Dokument wurde bezüglich der Veränderungen mit Version 2.0 des Apache HTTP-Servers noch nicht aktualisiert. Einige der Angaben können noch relevant sein, sind aber mit Vorsicht zu verwenden.

Die Version 1.3 des Apache HTTP-Servers war die erste Version mit einem Port zu einem Mainframe, der nicht den ASCII- sondern den EBCDIC-Zeichensatz verwendet.

(Das waren die SIEMENS-Mainframes mit dem Betriebssystem BS2000/OSD. Dieses Mainframe-Betriebssystem besitzt heute ein von SVR4 abgeleitetes POSIX-Subsystem).

Ursprünglich wurde der Port aufgenommen,

• um die Portierbarkeit des Apache HTTP-Servers für diese Plattform nachzuweisen,
• um einen "würdigen und fähigen" Nachfolger für den ehrwürdigen CERN-3.0-Daemon zu finden (der einige Jahre zuvor portiert wurde) und
• um zu belegen, dass das Preforking-Prozessmodell des Apache das Accept-Fork-Serve-Modell der CERN um den Faktor 5 oder mehr übertreffen kann.

Dieses Dokument beschreibt einige der Designentscheidungen für den Port zu diesem Rechner.

Eines der Ziele, die mit dem EBCDIC-Port erreicht werden sollten, war die Bereitstellung einer ausreichenden Abwärtskompatibilität zum CERN-Server (EBCDIC), um den Wechsel zum neuen Server einfach und attraktiv zu gestalten. Das erforderte eine konfigurierbare Methode für die Entscheidung, ob ein HTML-Dokument im ASCII-Format (dem einzigen Format, das der alte Server akzeptiert hat) oder im EBCDIC-Format (das native Dokumentformat des POSIX-Subsystems und deshalb das einzige realistische Format, in welchem die anderen POSIX-Werkzeuge wie grep oder sed mit den Dokumenten arbeiten konnten) gespeichert werden soll. Die aktuelle Lösung ist das "Pseudo-MIME-Format", welches der Apache-Server entgegennimmt und interpretiert (siehe unten). Zukünftige Versionen werden dieses Problem vielleicht mit der Definition eines "ebcdic-Handler" für alle umzuwandelnden Dokumente lösen.

Da alle Ein- und Ausgaben des Apache auf dem BUFF-Datentyp und seinen Methoden basieren, war die einfachste Lösung das Hinzufügen der Umwandlung in den BUFF-Behandlungsroutinen. Die Umwandlung muss zu jeder Zeit eingeschaltet werden können, daher wurde ein BUFF-Flag hinzugefügt, das festlegt, ob für ein BUFF-Objekt zurzeit die Umwandlung aktiviert ist oder nicht. Dieses Flag wird an verschiedenen Punkten im HTTP-Protokoll modifiziert:

• Es wird vorm Eingang einer Anfrage gesetzt (weil die Anfrage und die Anfrage-Header immer das ASCII-Format haben).
• Es wird gesetzt/zurückgesetzt, wenn der Anfragerumpf empfangen wird - in Abhängigkeit vom Inhaltstyp des Anfragerumpfs (weil der Anfragerumpf ASCII-Text oder eine Binärdatei enthalten kann).
• Es wird vor dem Senden eines Antwort-Header gesetzt, (weil die Zeilen des Antwort-Header immer im ASCII-Format sind).
• Es wird gesetzt/zurückgesetzt, wenn der Rumpf der Antwort gesendet wird - in Abhängigkeit vom Inhaltstyp des Antwortrumpfes (weil der Rumpf der Antwort Text oder eine binäre Dtei enthalten kann).

1. Die wichtigen Änderungen im Quellcode werden mit #ifdef in zwei Kategorien unterteilt:

   #ifdef CHARSET_EBCDIC

   Code, der von jedem EBCDIC-Rechner benötigt wird. Hierzu gehören die Zeichenumwandlungen, Unterschiede bei zwei Zeichensätzen, Flags, die anzeigen, welcher Teil des HTTP-Protokolls umgewandelt werden muss und welcher nicht usw.

   #ifdef _OSD_POSIX

   Code, der nur für das Mainframe-Betriebssystem SIEMENS BS2000/OSD benötigt wird. Hier handelt es sich um Unterschiede in den Include-Dateien und um Fragen der Socket-Implementierung, die nur für das Betriebssystem BS2000/OSD relevant sind.

2. Die Möglichkeit zur Umwandlung zwischen ASCII und EBCDIC auf Socket-Ebene (unter BS2000 POSIX gibt es eine Socket-Option, die dies unterstützt) wurde absichtlich nicht gewählt, weil der Byte Stream auf Ebene des HTTP-Protokolls aus einer Mischung Protokoll-bezogener Strings und nicht Protokoll-bezogener Rohdaten besteht. HTTP-Protokoll-Strings werden immer im ASCII-Format kodiert (die GET-Anfrage, alle Header:-Zeilen, die Chunking-Informationen usw.) während die Dateitransferteile (z.B. GIF-Bilder, CGI-Ausgaben usw.) normalerweise vom Server einfach "durchgereicht" werden sollten. Diese Trennung von "Protokoll-String" und "Rohdaten" spiegelt sich im Servercode in Funktionen wie bgets() oder rvputs() für Strings sowie in Funktionen wie bwrite() für binäre Daten wieder. Eine allgemeine globale Umwandlung wäre daher nicht angebracht.

   (Bei Textdateien müssen selbstverständlich Maßnahmen getroffen werden, dass EBCDIC-Dokumente immer im ASCII-Format bedient werden).

3. Der Port besitzt daher eine Server-interne integrierte Umwandlung auf Protokollebene (die der Compiler in EBCDIC-Strings umgewandelt hat), die somit für alle vom Server umgewandelten Dokumente gilt. Die fest kodierten ASCII-Sequenzen \012 und \015, die im Servercode allgegenwärtig sind, bilden eine Ausnahme: sie sind bereits die binäre Kodierung der ASCII-Zeichen \n und \r und müssen nicht ein zweites Mal ins ASCII-Format umgewandelt werden. Diese Ausnahme ist nur für vom Server erzeugte Strings relevant; externe EBCDIC-Dokumente enthalten normalerweise keinen Zeilenvorschübe im ASCII-Format.

4. Bei der Untersuchung der Aufrufhierarchie der BUFF-Managementroutinen wurden eine "EBCDIC/ASCII-Umwandlungsschicht" hinzugefügt, die bei jeder puts-, write-, get- und gets-Routine passiert wird, sowie ein Umwandlungs-Flag, mit dem die Umwandlungen en passant ein- oder ausgeschaltet werden können. Normalerweise durchläuft ein Dokument auf dem Weg von den ursprünglichen Ausgangdaten (eine Datei oder CGI-Ausgabe) zum Ziel (der anfordernde Client) zweimal diese Schicht: Datei -> Apache und Apache -> Client.

   Der Server kann jetzt die Header-Zeilen einer CGI-Skriptausgabe im EBCDIC-Format lesen und dann feststellen, dass der Rest der Skriptausgabe das ASCII-Format hat (wie bei der Ausgabe eines WWW-Zählerprogramms: der Rumpf des Dokuments enthält ein GIF-Bild). Die gesamte Header-Verarbeitung erfolgt im nativen EBCDIC-Format und der Server stellt dann anhand des zu liefernden Dokumenttyps fest, ob der Rumpf des Dokuments (mit Ausnahme der Chunking-Information) bereits ein ASCII-Dokument ist oder aus dem EBCDIC-Format umgewandelt werden muss.

5. Bei Textdokumenten (MIME-Typ text/plain, text/html usw.) kann eine implizite Umwandlung ins ASCII-Format benutzt werden oder sie können (wenn die Benutzer es für eine schnellere Bedienung vorziehen, Dokumente im ASCII-Rohformat zu speichern, oder weil sich die Dateien in einem montierten NFS-Verzeichniszweig befinden) ohne Umwandlung ausgeliefert werden.

   Beispiel:

   Benutzen Sie folgende Direktiven, um Dateien mit dem Suffix .ahtml ohne implizite Umwandlung im ASCII-Rohformat als text/html-Dokument (und Dateien mit dem Suffix .ascii als text/plain-Datei) zu liefern::

   AddType text/x-ascii-html .ahtml
   AddType text/x-ascii-plain .ascii

   In ähnlicher Weise kann jeder MIME-Typ text/foo, der mit AddType ein MIME-Typ text/x-ascii-foo definiert wird, als "ASCII-Rohdaten" gesendet werden.

6. Dokumente, die keine Texte sind, werden immer ohne Umwandlung "binär" gesendet. Für Dateitypen wie GIF/ZIP/AU scheint dies die sinnvollste Form zu sein. Dabei ist es selbstverständlich erforderlich, dass der Benutzer sie mit dem Schalter rcp -b binär auf den Mainframe kopiert.

7. Bei vom Server ausgewerteten Dateien wird immer vom nativen Format des Rechners (z.B. EBCDIC) ausgegangen und die Umwandlung nach der Verarbeitung durchgeführt.

8. Bei CGI-Ausgaben stellt das CGI-Skript fest, ob eine Umwandlung erforderlich ist oder nicht: Durch setzen des entsprechenden Inhaltstyps können Textdateien umgewandelt oder GIF-Ausgaben unverändert durchgereicht werden. Ein Beispiel für Letzteres ist das Programm wwwcount, das ebenfalls portiert wird.

Alle Dateien, deren Content-Type:-Header nicht mit text/ beginnt, werden vom Server als binäre Dateien betrachtet und sind nicht Gegenstand irgendeiner Umwandlung. Beispiele für binäre Dateien sind GIF-Bilder, gzip-komprimierte Dateien usw.

Beim Austausch binärer Dateien zwischen dem Mainframe-Host und einem Unix-Rechner oder Windows-PC, muss der ftp-Befehl binary (TYPE I) oder der Befehl rcp -b des Mainframe-Host benutzt werden (der Schalter -b wird vom Unix rcp-Befehl nicht unterstützt).

Die Standardannahme des Servers ist, dass Textdateien (z.B. alle Dateien, deren Content-Type:-Header mit text/ beginnt), im Zeichensatz des Host-Rechners gespeichert werden (EBCDIC).

SSI-Dokumente müssen zurzeit ausschließlich im EBCDIC-Format gespeichert werden. Für eine Umwandlung vor der Verarbeitung ins ASCII-Format wurden keine Vorkehrungen getroffen.

Modul	Status	Anmerkungen
core	+
mod_access	+
mod_actions	+
mod_alias	+
mod_asis	+
mod_auth	+
mod_auth_anon	+
mod_auth_dbm	?	Mit eigener libdb.a
mod_autoindex	+
mod_cern_meta	?
mod_cgi	+
mod_digest	+
mod_dir	+
mod_so	-	Keine Shared Libraries
mod_env	+
mod_example	-	(Nur Test)
mod_expires	+
mod_headers	+
mod_imap	+
mod_include	+
mod_info	+
mod_log_agent	+
mod_log_config	+
mod_log_referer	+
mod_mime	+
mod_mime_magic	?	Noch nicht portiert
mod_negotiation	+
mod_proxy	+
mod_rewrite	+	Nicht getestet
mod_setenvif	+
mod_speling	+
mod_status	+
mod_unique_id	+
mod_userdir	+
mod_usertrack	?	Nicht getestet

Modul	Status	Anmerkungen
mod_jserv	-	JAVA wird noch portiert.
mod_php3	+	mod_php3 Funktioniert gut mit LDAP und GD und FreeType-Bibliotheken.
mod_put	?	Nicht getestet
mod_session	-	Nicht getestet

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