Verarbeitung der Klient-Eingaben

Der Extension-Control-Bloc ECB

Der Extension-Control-Bloc (ECB) wird bei jeder Anforderung im Adreßraum des Servers neu angelegt und zur Vermittlung der Ein- und Ausgaben benutzt. Auch bei vielen gleichzeitigen Anforderungen greift jeder Thread auf "seinen" ECB zu. Die Tabelle listet alle Elemente auf, die pro Ausfertigung des Datenblockes vorhanden sind:

Zuerst interessiert der Inhalt des Feldes lpszMethod. Davon hängt ab, wo die weiteren Eingabedaten des Klient zu finden sind. Bei der Methode GET liefert der Browser seine Daten an den sogenannten QueryString lpszQueryString. Bei der Aufrufmethode POST gelangen die vom Klient gesendeten Daten in den Puffer lpbData. Zumindest die ersten 48 KByte davon, aber dieses Maß dürfte selten überschritten werden. Die Daten im Puffer sind im Allgemeinen kodiert. lpszContentType gibt Auskunft darüber, nach welchem Verfahren diese Kodierung stattgefunden hat. Formulardaten liegen in der Regel als "application/x-www-form-urlencoded" vor.

Alle diese Datenfelder können Sie bequem von der ISAPI-DLL aus dem ECB-Block auslesen lassen und weiterbenutzen. Achten Sie aber bitte von vornherein exakt auf die Datentypen. Je nach Compilereinstellung bekommen Sie speziell unter Delphi 4/5 sonst Typkonflikte angezeigt.

Das einzige Problem für Sie beim Variablenabruf stellt die Dekodierung der Content-Daten dar. Hierfür gibt es aber aus der CGI-Programmierung heraus genügend bewährte Algorithmen. Nach geringen Modifizierungen sind diese Quelltexte auch für ISAPI-DLLs verwendbar.

formular-kodierte Daten

Der Anwender habe in seinem Browser ein Formular mit dem Datenfeld Name mit Max Möller und ein Datenfeld Mail mit mm@firma.de ausgefüllt. Anschließen hat er den Submit-Button mit der Aufschrift Abschicken betätigt. Die über die Methode POST an den Server gesandten Daten werden der ISAPI-Erweiterung per ECB übergeben. ECB.lpbData zeigt dann auf einen Zeichenpuffer mit folgendem Inhalt:

Name=Max+M%F6ller&Mail=mm@firma.de&Button=Abschicken

• Feldbegrenzer/Trennzeichen werden als "&" gesendet.
• Das Leerzeichen wird in "+" umkodiert.
• Alle Sonderzeichen werden mit vorangestelltem Prozentzeichen im HEX-Code verschickt.
• Alle üblichen Textzeichen und Ziffern werden unverschlüsselt übertragen.

In nahezu jedem ISAPI-Projekt benötigen Sie deshalb eine Dekodier-Routine, die diese Veränderungen wieder auflöst. Dazu ist die folgende Funktion GetContentData geeignet. Sie finden sie neben anderen Hilfsroutinen in meiner Unit IsapiHlp, die den folgenden Demoprojekten beiliegt.

function GetContentData(var List: TStringList): Boolean;
var pCont: PChar;
    nContentLength, i: Integer;
    sPair: String;
begin
 nContentLength:=ECB.cbAvailable;
 if nContentLength>=0 then begin
  pCont:=ECB.lpbData;
  i:=0;
  sPair:='';
  while i<nContentLength do begin
   case (pCont+i)^ of {Sonderzeichen behandeln}
    '+': sPair:=sPair+' ';
    '%': begin
          sPair:=sPair+Chr((HxToInt((pCont+i+1)^)shl 4)+
          HxToInt((pCont+i+2)^));
          Inc(i,2);
         end;
    '&': begin List.Add(sPair); sPair:='' end;
    else sPair:=sPair+(pCont+i)^;
   end;
   Inc(i,1);
  end;
  List.Add(sPair);
  GetContentData:=true;
 end else GetContentData:=false;
end;

Der mittels ECB.lpbCont übergebene Zeichenpuffer wird hier Schritt für Schritt durchlaufen. Gefundene Sonderzeichen werden umkodiert. Beim Auftreten eines Separators in Form von "&" wird in der Ergebnisliste List ein neuer Eintrag angelegt. Die mit den dekodierten Parameterpaaren gefüllte Liste wird an das aufrufende Programm zurückgegeben.

Die Verwendung einer Ergebnisliste vom Typ TStringList hat den Vorteil, daß Sie später darin bequem nach dem Auftreten eines beliebigen Schlüsselpaares suchen können. Die Anweisung

sName:=Liste.Values['Name']

zieht aus der Stringliste den Wert des Namen heraus, ganz gleich an welcher Position innerhalb der Liste und somit innerhalb des Formulars er steht.

Nicht verschwiegen werden soll, daß GetContentData( ) nicht nachschaut, ob mehr als 48 KByte Eingabedaten vom Formular gesendet wurden. Es wird nur cbAvailable zur Längenbestimmung herangezogen. Erfahrungsgemäß dürften aber bereits Datenmengen von 1 KByte aufwärts bei Formularinhalten die Ausnahme darstellen.

Noch mehr Eingangs-Informationen - die Servervariablen

Zusatzinformationen rufen Sie über die Funktion GetServerVariable ab. Auch diese Prozedur ist in der Unit Isapi deklariert. Sie erfordert als entscheidenden Parameter den Namen der abzufragenden Servervariablen. Welche Variablen laut Microsoft-Spezifikation verfügbar sind, zeigt folgende Tabelle.

Eine Möglichkeit zum komfortablen Abruf einer solchen Variable zeigt Ihnen die folgende Hilfsroutine. Sie liefert das Ergebnis in der Form eines bequem zu handhabenden Pascal-Strings.

function GetVar(ServerVar: PChar): String;
var cBuf: array[0..1535] of Char;
    BufLen: DWORD;
begin
 BufLen:=SizeOf(cBuf);
 FillChar(cBuf,BufLen,#0);
 ECB.GetServerVariable(ECB.ConnID, ServerVar, Addr(cBuf), BufLen);
 GetVar:=cBuf;
end;

Die meisten Servervariablen geben einen relativ kurzen Inhalt zurück. Ausnahmen stellen die Variablen HTTP_ACCEPT und ALL_HTTP dar, die bei manchen Browsern gut einige hundert Zeichen lang sind. Dimensionieren Sie den Rückgabepuffer zur Ergebnisaufnahme für beide bitte nicht zu knapp.

HTTP_ACCEPT liefert Ihnen die Information darüber, welche Typen von Ergebnisdateien der Browser des anfragenden Klient verarbeiten kann. HTTP_ALL verrät viele Details über die Ausstattung des Klient. Eine darin enthaltene Angabe zu HTTP_USER_AGENT referenziert den verwendeten Browser. Falls auch HTTP_UA_PIXELS übermittelt wird, erfahren Sie damit in Ihrem Serverprogramm die Bildschirmauflösung auf dem Klient-Computer. Leider liefern die unterschiedlichen Browser innerhalb der Variablen HTTP_ALL sehr differierende Angaben.

J. Hummel,   2000