Request-Objekt |
Das Objekt Request bietet Zugriff auf den HTTP-Anforderungs-Header und -Body. Es ist wohl das wichtigste integrierte ASP-Objekt, denn es ist das Objekt, durch das Sie auf die Entscheidungen der Anwender reagieren können. Mit Hilfe des Objekts Request lassen sich aufgrund der Benutzereingaben Webseiten dynamisch erzeugen und bedeutungsvolle serverseitige Aktionen (etwa die Aktualisierung einer Datenbank) durchführen.

Wie HTTP funktioniert |
  Das Objekt Request wird nachfolgend ausführlich erläutert. Zunächst ist es jedoch wichtig, dass Sie die Grundlagen des HTTP-Protokolls verstehen und die Verwendung des Request-Objekts nicht länger ein Mysterium bleibt. Doch keine Bange: Es handelt sich nur um eine kurze Übersicht über das HTTP-Protokoll. HTTP: Ein einfaches Beispiel Vermutlich wissen Sie bereits, dass HTTP ein "Transaktions"-Protokoll ist. Der Browser (Client) sendet eine Anforderung an den Server. Dieser befolgt die Anforderung (wenn möglich) und sendet eine Antwort an den Client zurück. Danach vergisst der Server die Transaktion. Der Browser vergisst die Transaktion in der Regel ebenfalls, unter bestimmten Vorraussetzungen aber nicht. HELLOCGI.HTM, eine von einer CGI-Anwendung erzeugte HTML-Seite Um die Interaktion zwischen Webbrowser und Server zu veranschaulichen, soll ein relativ einfaches Beispiel untersucht werden. In Abbildung 7.1 wird in Netscape Navigator ein ganz schlichtes Formular, HELLO.HTM, angezeigt. Darin wird der Anwender zur Eingabe des Namens aufgefordert. Sobald der Anwender auf die Schalfläche Submit klickt, wird eine CGI-Anwendung auf einem WebSite-Server aufgerufen, welche die in Abbildung 7.2. angezeigte Seite zurücksendet. (In diesem Beispiel werden Netscape Navigator und WebSite verwendet, doch ist der Austausch zwischen jedem sonstigen Browser und jedem sonstigen Server mehr oder weniger derselbe. Und obwohl in diesem Beispiel eine CGI-Anwendung verwendet wird, ist der HTTP-Anforderung-Antwort-Zyklus bei einer ASP-Anwendung nahezu identisch. Weitere Erläuterungen zu CGI-ASP-Konvertierungen erhalten Sie in Anhang B.) Zunächst soll ausgeführt werden, wie der Austausch zwischen Browser und Server vom Protokoll behandelt wird: Hat der Anwender die Eingabe der URL für HELLO.HTM abgeschlossen, sendet Navigator den unten angeführten Stream an den Server. send ist im nachfolgenden Ausgabe-Listing eine Socket-Funktion, die einen Stream über ein verbundenes Socket versendet. In der Ausgabe wird das Socket durch 73 identifiziert und 179 ist der Wert, der von der Funktion zurückgegeben wird, und repräsentiert die gesamte gesendete Datenmenge (in Byte).
      [73:send:(179)]GET /hello.htm HTTP/1.0
      Connection: Keep-Alive
      User-Agent: Mozilla/3.0 (Win95; I)
      Host: pc229.west.ora.com
      Accept: image/gif, image/x-xbitmap, image/jpeg,
         image/pjpeg, */*
  Es handelt sich hier um einen Anforderungs-Header. Der Browser bringt zum Ausdruck, dass der Server ein Dokument holen soll, nämlich /HELLO.HTM. Get ist mehr als eine allgemeine Beschreibung dessen, was der Server machen soll, vielmehr bezeichnet es den HTTP-Anforderungstypus. (Weitere Informationen finden Sie in Abschnitt 7.1.2, weiter hinten in diesem Kapitel.) Der Browser teilt dem Server zudem mit, dass er die Version 1.0 des Hypertext-Transfer-Protokolls verwendet. Beachten Sie, dass ein Teil der ersten Zeile in diesem HTTP-Header nicht Teil der tatsächlich gesendeten HTTP-Anforderung ist, sondern aus dem in diesem Beispiel verwendeten TCP/IP-Netzwerkmonitor stammt. Das trifft auf alle HTTP-Segmente in diesem Kapitel zu. Der Server empfängt die vom Browser gesendeten Header (siehe die von unserem Spy-Programm erzeugte Ausgabe unten) und bearbeitet die Anforderung. Die Funktion recv wird verwendet, wenn Daten von einem Socket empfangen werden sollen. Die erste Zahl im Ausgabecode, 21, repräsentiert das vom Server verwendete Socket. "Completed (179)" ist der Rückgabewert der Funktion und besagt in diesem Fall, dass sie normal ausgeführt worden ist, wobei 179 Byte an Daten empfangen worden sind. Beachten Sie, dass dies der vom Browser gesendeten Datenmenge entspricht.
      [21:recv: completed (179)]GET /hello.htm HTTP/1.0
      Connection: Keep-Alive
      User-Agent: Mozilla/3.0 (Win95; I)
      Host: pc229.west.ora.com
      Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
  Der Server sendet das Dokument HELLO.HTM an den Browser:
      [21:send:(535)]HTTP/1.0 200 OK
      Date: Monday, 30-Sep-98 23:33:00 GMT
      Server: WebSite/1.1
      Allow-ranges: bytes
      Accept-ranges: bytes
      Connection: Keep-Alive
      Content-type: text/html
      Last-modified: Monday, 30-Sep-98 23:30:38 GMT
      Content-length: 297

      <HTML>
      <HEAD><TITLE>Hello, World!</TITLE></HEAD>
      <BODY>
      <FORM ACTION="/cgi-win/hello.exe" METHOD="POST">
      What is your name? <INPUT TYPE="text" NAME="name" SIZE=60><BR>
      <INPUT TYPE="submit" VALUE="Submit the form">
      <INPUT TYPE="reset" VALUE="Clear all fields">
      </FORM>
      </BODY> </HTML>
  Hier sendet WebSite insgesamt 535 Byte an den Browser. Der Code setzt sich zusammen aus einem Anforderungs-Header, dann kommt eine Leerzeile und dann das HTML-Dokument selbst. Die Header-Felder bezeichnen unter anderem die Datenmenge in Byte (Content-length) sowie das Format (Content-type) der übertragenden Daten. "200 OK" ist ein Statuscode, der anzeigt, dass die Browser-Anforderung erfolgreich ausgeführt worden ist. Der Server zeigt zudem an, dass er, ebenso wie der Browser, die HTTP-Version 1.0 verwendet. Der Browser ließt die vom Server gesendeten Header und Daten:
      [73:recv: posted]
      [73:recv: completed (260)]HTTP/1.0 200 OK
      Date: Monday, 30-Sep-98 23:33:00 GMT
      Server: WebSite/1.1
      Allow-ranges: bytes
      Allow-ranges: bytes

      Connection: Keep-Alive
      Content-type: text/html
      Last-modified: Monday, 30-Sep-98 23:30:38 GMT
      Content-length: 297

      <HTML>
      <HEAD><TITLE>H
      [73:recv: posted]
      [73:recv: completed (275)]ello, World!</TITLE></HEAD>
      <BODY>
      <FORM ACTION="/cgi-win/hello.exe" METHOD="POST">
      What is your name? <INPUT TYPE="text" NAME="name" SIZE=60><BR>
      <INPUT TYPE="submit" VALUE="Submit the form">
      <INPUT TYPE="reset" VALUE="Clear all fields">
      </FORM>
      </BODY> </HTML>
  Zwar sind zwei recv-Operationen erforderlich, um die Header-Datensätze zusammen mit dem Dokument abzurufen, doch entspricht die in diesen beiden Operationen insgesamt gelesene Datenmenge der vom Server gesendeten Datenmenge. Im Browser wird das Formular angezeigt, mit einem Eingabefeld für den Namen des Anwenders. Wenn der Anwender das Formular ausfüllt und auf Submit klickt, wird Folgendes an den Server gesendet:
      [70:send:(232)]POST /cgi-win/hello.exe HTTP/1.0
      Referer: http://pc229.west.ora.com/hello.htm
      Connection: Keep-Alive
      User-Agent: Mozilla/3.0 (Win95; I)
      Host: pc229.west.ora.com
      Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
      [70:send:(69)]Content-type: application/x-www-form-urlencoded
      Content-length: 14
      [70:send:(2)]
      [70:send:(16)]name=Jayne+Doe
  Da der Browser Formulardaten übermittelt, ist der HTTP-Anforderungstyp "POST", wie aus dem ersten Header-Datensatz ersichtlich ist. Entsprechend zeigen die Datensätze Content-length und Content-type an, dass der Browser im Body der Anforderung 14 Byte URL-codierte Daten vom Typ x-www-form-urlencoded übermittelt. Diese umfassen die Informationen, die der Anwender in das einzige Datenfeld des Formulars, das Textfeld name eingegeben hat. Die vom Browser im vorigen Schritt übermittelten Header-Datensätze und Formulardaten werden vom Server empfangen. (Da diese grundsätzlich mit dem vom Browser gesendeten Text identisch sind, wird das Listing an dieser Stelle nicht wiederholt.) Die URL (/cgi-win/hello.exe) veranlasst den Server, die CGI-Anwendung HELLO.EXE zu starten und die Daten aus dem Formular an diese Anwendung zu übermitteln. Die CGI-Anwendung erledigt möglicherweise noch einige Verarbeitungsaufgaben und erzeugt dann ein HTML-Dokument und sendet es an den Server. Der Server schickt das HTML-Dokument dann an den Browser zurück, zusammen mit den notwendigen Header-Datensätzen. Demonstriert wird das in der nachfolgenden Ausgabe von WSock32 Spy:
      [18:send:(422)]HTTP/1.0 200 OK
      Date: Monday, 30-Sep-98 23:33:10 GMT
      Server: WebSite/1.1
      Allow-ranges: bytes
      Accept-ranges: bytes
      Connection: Keep-Alive
      Content-type: text/html
      Content-length: 231

      <HTML><HEAD>
      <TITLE>Welcome to this Web Page!</TITLE></HEAD>

      <BODY><H1>Welcome to Our Web Server!</H1><p><p>
      Hello, Jayne Doe! We're glad that you took
      the time out of your busy day to visit us!
      <HR></PRE></BODY></HTML>
Beachten Sie, dass der Server dem Browser mitteilt, dass er ein HTML-Dokument mit 231 Byte sendet. Der Browser empfängt den vom Server gesendeten Datenstrom und verwendet ihn zum Erzeugen der HTML-Seite. Hoffentlich konnte Ihnen diese Beschreibung einen Eindruck davon vermitteln, was beim Datenaustausch zwischen Browser und Server alles passiert. Es ist jedoch wichtig, einige der angeschnittenen Punkte zu vertiefen und einige zusätzliche Funktionen abzudecken, die in diesem Beispiel nicht enthalten sind. HTTP-Anforderungstypen Der Anforderungstyp wird vom Client an den Server übergeben; dadurch weiß der Server, was er mit der ebenfalls vom Browser gelieferten URL machen soll. Zwar umfasst die HTTP-Spezifikation eine Reihe von Anforderungstypen, wie z. B. PUT oder DELETE, doch sind nur zwei Anforderungstypen allgemein gebräuchlich, da nur sie von allen Servern unterstützt werden, nämlich GET und POST. Durch eine GET-Anforderung wird der Server aufgefordert bestimmte Informationen, typischerweise ein Dokument, zu holen und an den Client zu schicken. Enthält die Anforderung zusätzliche Informationen, werden diese als Argumente an die URL angehängt. Durch eine POST-Anforderung hingegen wird der Server mit Informationen beliefert, die an die URL zu "senden" sind. Typischerweise dient sie dazu, den Inhalt eines HTML-Formulars an den Server zu senden oder den Server mit Informationen zu beliefern, die für die serverseitige Verarbeitung benötigt werden. Die Informationen selbst sind im Body der Anforderung enthalten. Die meisten Server können Daten, die über POST oder GET empfangen worden sind, intern nicht verarbeiten. In der Regel werden POST- und GET-Anforderungen, die ebenfalls Daten an den Server senden, von Hilfsprogrammen oder DLLs (CGI- und ISAPI-Anwendungen und ISAPI-Filter) verarbeitet. Sowohl die POST- wie auch die GET-Anforderung können jede Art von Daten in beliebiger Größe zurückgeben. Auch wenn es beim Übermitteln von Daten an einen Webserver manchmal so scheint als wären die Methoden GET und POST ähnlich, so ist eine Regel unumstößlich: Eine GET-Anforderung darf niemals etwas ändern. Schreiben Sie kein ASP-Skript, das als Antwort auf eine GET-Anforderung z. B. Änderungen an einer Datenbank vornimmt. Die Gründe hierfür werden ausführlich erläutert in Abschnitt 7.1.3. Formulareinreichung Ein Anwender füllt die Eingabefelder eines Formulars aus. Beim Senden des Formulars werden die Daten in den einzelnen Feldern des Formulars an den Server übertragen, der sie an ASP weiterleitet. Diese Daten werden im Format name=value gesendet, wobei name den Namen bezeichnet, der dem Feld über das Attribut NAME des <INPUT>-Tags zugewiesen wurde, und value den Wert, der in das Feld eingetragen wurde. Angenommen, der Anwender trägt "Archie" in ein Feld für den Vornamen ein, so könnte der Browser den String first_name=Archie senden. Wurde im Formularcode METHOD=GET verwendet, werden die Formulardaten als Argument an die URL angehängt. Umfasst das Formular viele Felder oder Felder mit langen Text-Strings, kann die gesamte URL recht umfangreich und unhandlich werden. Zudem liegt die Obergrenze für die Anzahl an Zeichen in einer GET-Anforderung, meist um die 2000, viel niedriger als in einer POST-Anforderung. Wird im Formularcode hingegen METHOD=POST verwendet, werden die name=value-Paare als Body der Anweisung gesendet und nicht an die URL angehängt. POST-Anforderungen haben den Vorteil, dass die meisten Server beim Extrahieren von Daten aus dem Body einer Anforderung eine bessere Performance aufweisen als beim Extrahieren aus einer URL im Anforderungs-Header. Verwenden Sie für Formulare, die eine Änderung vornehmen sollen oder irreversible Aktionen auslösen (das ist meistens der Fall), immer die Methode POST. POST ist sicherer und effizienter; GET sollte nie für Änderungsvorgänge herangezogen werden. Beim Entwickeln von ASP-Skripts können Sie selbst entscheiden, ob Sie die Weiterleitung von Daten an das Programm über die GET-Methode unterstützen wollen. HTTP-Anforderungen und -Antworten Header sind der am meisten missverstandene Teil des HTTP-Protokolls. Doch kann das Verständnis ihrer Aufgabe das Verständnis der Eigenschaften und Methoden der ASP-Objekte Request und Response sehr viel einfacher gestalten. Eine beliebige Internet-Email-Nachricht beispielsweise besteht aus zwei Teilen, dem Header und dem Body. Der Header umfasst mehrere Zeilen, die den Body der Nachricht beschreiben und möglicherweise auch Routing-Informationen und Kodierungen. Header und Body sind durch eine Leerzeile getrennt. (Weitere Information über die Header-Syntax bietet der RFC-822-Standard.) Eine HTTP-Nachricht (Anforderung wie auch Antwort) ist entsprechend aufgebaut. Die erste Zeile ist anders, doch die restlichen Zeilen bis zur ersten Leerzeile sind die gleichen Header wie in einer E-Mail-Nachricht. Der Header beschreibt die Anforderung und, wenn vorhanden, ihren Inhalt oder die Antwort samt Inhalt. Die Anforderung In Abschnitt 7.1.1 haben Sie eine Reihe von Anforderungen vom Browser kennen gelernt. Hier ein weiteres Beispiel einer einfachen HTTP-Anforderung:
    POST /cgi-win/hello.exe HTTP/1.0
    Accept: image/gif, image/jpeg, */*
    User-Agent: Mozilla/2.0N (Windows; I; 32Bit)
    Content-type: application/x-www-form-urlencoded
    Content-length: 14
    [mandatory blank line]
    name=Jayne+Doe
Die erste Zeile, die so genannte Anforderungszeile, beschreibt den Anforderungstyp (auch Methode) – in diesem Fall POST –, die URL und schließlich die Version des vom Client verwendeten HTTP-Protokolls. Die zweite Zeile beschreibt, welche Arten von Dokumenten der Client akzeptieren kann. Die dritte Zeile ist ein Extra-Header, der von HTTP nicht benötigt wird. Er gibt Name und Version der Client-Software an. Danach kommen, wie bereits in Abschnitt 7.1.1 erwähnt, zwei Zeilen, die die im Anforderungs-Body enthaltenen Informationen beschreiben. Das alles, bis hin zur obligatorischen Leerzeile, ist Teil des HTTP-Anforderungs-Headers. Neben den hier angeführten Beispielzeilen können in diesem Abschnitt auch andere Zeilen vorkommen. Angenommen, der Browser sendet Informationen, die in einem "Cookie" enthalten sind, so wird das ebenfalls im Anforderungs-Header enthalten sein. Nach der obligatorischen Leerzeile kommt der HTTP-Anforderungs-Body. In den meisten Fällen ist dieser Teil der Anforderung leer (etwa wenn der Browser nur eine statische Seite anfordert und selbst keine Informationen sendet). Wird jedoch die Methode POST verwendet, so befinden sich die an den Webserver zu sendenden Informationen in diesem Teil der Anforderung. Die Antwort Hier ein Beispiel einer einfachen HTTP-Antwort:
    HTTP/1.0 200 OK
    Date: Thursday, 02-Nov-95 08:44:52 GMT
    Server: WebSite/1.1
    Last-modified: Wednesday, 01-Nov-95 02:04:33 GMT
    Content-type: text/html
    Content-length: 8151
    [mandatory blank line]
    <HTML><HEAD>
    <TITLE>...
Die erste Zeile der Antwort ist wiederum HTTP-spezifisch, es ist die so genannte Statuszeile. Sie enthält die Version des vom Server verwendeten Protokolls, sowie einen Statuscode mit Bedeutung (Reason-Phrase). Der Server verwendet Statuscode und Reason-Phrase, um dem Browser mitzuteilen, ob er in der Lage war, auf die Anforderung des Browsers zu antworten. In diesem Fall wurde die Browser-Anforderung nach einem Dokument erfüllt. Die zweite Zeile zeigt an, wann der Server die Anforderung bearbeitet hat. Dann kommt eine Header-Zeile, welche die Server-Software und die Version nennt. Die vierte Zeile zeigt an, wann das angeforderte Dokument zuletzt geändert worden ist. Die letzten beiden Zeilen beschreiben den Datentyp und Größe in Byte des angeforderten Dokuments. Danach kommt genau eine Leerzeile und dann der Body der Nachricht, der die Dokumentdaten enthält, die der Server für die Anzeige im Browser zurücksendet. Wie schon bei der HTTP-Anforderung wird alles oberhalb der obligatorischen Leerzeile als Teil des HTTP-Headers betrachtet. Alles unterhalb dieser Zeile gehört zum Body der Antwort. Dieses Kapitel behandelt das ASP-Objekt Request, mit dem Sie sowohl auf den Header als auch auf den Body der HTTP-Anforderung zugreifen können. Das nächste Kapitel erläutert das ASP-Objekt Response, mit dem Sie auf die HTTP-Antwort des Webservers Einfluss nehmen können. Die HTTP-Anforderung und das ASP-Objekt Request Wie bereits erwähnt, ermöglicht Ihnen das ASP-Objekt Request Zugriff auf Header und Body einer HTTP-Anforderung, die vom Client-Browser an den Webserver gesendet worden ist. Das Verfahren beim Abrufen von Informationen aus der HTTP-Anforderung ist für ASP-Skripts und CGI-Anwendungen grundsätzlich gleich. Ausnahmen entstehen nicht durch den eigentlichen Anforderungsmechanismus, sondern durch die Art, wie beide Anwendungstypen vom Webserver geladen werden (CGI- im Gegensatz zu ISAPI-Filter). Dies wurde in den ersten beiden Kapiteln dieses Buchs erläutert. Wie auch bei CGI-Anwendungen kann der Client-Browser Informationen an ein ASP-Skript auf zwei Arten senden. Zunächst kann er die Informationen über ein HTML-Formular und die Methode GET senden:
    <HTML>
    <HEAD><TITLE>Welcome to the Corp.</TITLE></HEAD>
    <BODY>
    <FORM ACTION=" http://mycorp.com/secure.asp" METHOD="GET">
    First name: <INPUT TYPE="text" NAME="first_name" SIZE=60><BR>
    Last name: <INPUT TYPE="text" NAME="last_name" SIZE=60><BR>
    <INPUT TYPE="submit" VALUE="Submit the form">
    <INPUT TYPE="reset" VALUE="Clear all fields">
    </FORM>
    </BODY> </HTML>
Wenn der Client eine GET-Anforderung sendet, werden die Informationen über die Anforderung als Name/Wert-Paar an das Ende der Anforderungs-URL angehängt. Dabei beginnen die Informationen mit einem Fragezeichen und sind durch Et-Zeichen getrennt. Jeder Name entspricht einem Element im Formular. Angenommen, der Anwender gibt Horatia und Thompson in die beiden Felder des Beispiels ein und klickt auf die Schaltfläche Submit . Was den Server anbelangt, ist die Einreichung des Formulars dann identisch mit der folgenden URL-Einreichung:
    http://mycorp.com/secure.asp?first_name=horatia&last_name=thompson
Dies ist ein wichtiger Punkt. Betrachten Sie einmal die folgende Codezeile:
    http://mycorp.com/secure.asp?first_name=horatia&last_name=thompson
Würde der Anwender diese Zeile in das Adressfeld des Browsers eingeben oder auf einen Link zu dieser URL klicken, so würde der Webserver die resultierende HTTP-Anforderung genauso behandeln als würde sie als Teil eines Formulars und mit Hilfe der GET-Anforderung gesendet. Aus Ihrer ASP-Anwendung heraus sind diese Informationen über die QueryString-Kollektion des Request-Objekts zugänglich. Hier ein Beispiel:
    <%
    strFirstName = Request.QueryString("first_name")
    %>
Mit diesem Code wird die Variable strFirstName initialisiert und auf den im Parameter first_name gesendeten Wert gesetzt. Die QueryString-Kollektion wird weiter hinten in diesem Kapitel ausführlich erläutert. Wie bei CGI-Anwendungen können Sie Informationen an ein ASP-Skript auch mit Hilfe der Methode POST senden. In diesem Fall wären die Informationen nicht mehr Teil des HTTP-Anforderungs-Headers, sondern Teil des Bodys des Anforderungsobjekts:
    <HTML>
    <HEAD><TITLE>Welcome to the Corp.</TITLE></HEAD>
    <BODY>
    <FORM ACTION="http://mycorp.com/secure.asp" METHOD="POST">
    First name: <INPUT TYPE="text" NAME="first_name" SIZE=60><BR>
    Last name:<INPUT TYPE="text" NAME="last_name" SIZE=60><BR>
    <INPUT TYPE="submit" VALUE="Submit the form">
    <INPUT TYPE="reset" VALUE="Clear all fields">
    </FORM>
    </BODY> </HTML>
Beim Einreichen dieses Formulars entsteht eine HTTP-Anforderung, die in etwa folgenden Inhalt hat:
    POST /secure.asp HTTP/1.0
    Accept: image/gif, image/jpeg, */*
    User-Agent: Mozilla/2.0N (Windows; I; 32Bit)
    Content-type: application/x-www-form-urlencoded
    Content-length: 35
    [mandatory blank line]
    first_name=horatio&last_name=aubrey
Damit Ihre Anwendung die in der HTTP-Anfrage gesendeten Informationen verarbeitet, verwenden Sie die Form-Kollektion des Request-Objekts:
    <%
    strFirstName = Request.Form("first_name")
    %>
Dadurch wird die Variable strFirstName initialisiert und auf den im Parameter first_name gesendeten Wert gesetzt. Die Form-Kollektion wird weiter hinten in diesem Kapitel ausführlich erläutert.

ASP-Objekt Request |
Die Eigenschaften, Kollektionen, Methoden und Ereignisse des ASP-Objekts Request sind nachfolgend aufgelistet. Zusammenfassung zum Objekt Request Eigenschaften TotalBytes Kollektionen ClientCertificate Cookies Form QueryString ServerVariables Methoden BinaryRead Ereignisse Keine

Anmerkungen/Fehlerbehebung |
In der vorangegangenen Beschreibung von ASP in Verbindung mit den Methoden GET und POST haben Sie bereits erfahren, dass Informationen aus einem GET mit Hilfe der QueryString-Kollektion abgerufen werden und aus einem POST mit Hilfe der Form-Kollektion. Das stimmt zwar, doch gibt es noch einen einfacheren Weg, bei dem Sie gar keine Kollektion festlegen brauchen. Betrachten Sie den folgenden Beispielcode:
    strName = Request("name")
Dieser Code liefert den Wert des Schlüssels name, und zwar unabhängig von der Kollektion, in der er sich befindet, da IIS alle Kollektionen durchsucht. Wenn Sie einen Wert in dieser Weise angeben, durchsucht ASP alle Request-Objekt-Kollektionen in der folgenden Reihenfolge: QueryString Form Cookies ClientCertificate ServerVariables Die Variable, die Sie initialisieren, erhält den Wert aus dem ersten Name/Wert-Paar, bei dem der Name dem angeforderten String entspricht. Wenn ein Name/Wert-Paar in mehreren Kollektionen vorkommt, liefert die obige Codesequenz also einfach das zuerst gefundene Paar, es sei denn Sie geben zusätzlich an, welche Kollektion gemeint ist. Wie auch andere Kollektionen des ASP-Objektmodells unterstützen alle in diesem Kapitel besprochenen Kollektionen des Objekts Request die Eigenschaften Item und Key, die Methode Count und das Konstrukt For..Each.

TotalBytes |
Var = Request.TotalBytes
Die Eigenschaft TotalBytes ist ein reiner Lesewert, der die vom Client im HTTP-Anforderungs-Body an den Server gesendete gesamte Datenmenge (in Byte) bezeichnet. Diese Eigenschaft ist wichtig, wenn man mit Hilfe der BinaryRead-Methode des Request-Objekts Daten aus dem Anforderungs-Body liest.
Parameter
Var Dieser Parameter wird auf die Größe (in Byte) des HTTP-Anforderungs-Bodys gesetzt, wenn Daten an den Webserver gesendet werden. Denken Sie daran, dass die Eigenschaft TotalBytes ein reiner Lesewert ist.
Beispiel
In diesem Beispiel wird vorausgesetzt, dass der Anwender auf das folgende Formular geantwortet hat:
    <HTML>
    <HEAD><TITLE>File Upload Form</TITLE></HEAD>
    <BODY>
    <FORM ENCTYPE = "multipart/form-data"
    ACTION= "http://mycorp.com/secure.asp" METHOD="POST">
    Select a file to upload:
    <INPUT TYPE="file" NAME="filename"><BR>
    <INPUT TYPE="submit" VALUE="Submit the form">
    </FORM>
    </BODY> </HTML>
Anhand der Eigenschaft TotalBytes können Sie feststellen, wie groß die HTTP-Anforderung insgesamt ist (in Byte), die an den Webserver gesendet worden ist:
    <%
    ' The following code retrieves the total number of
    ' bytes sent in the user's HTTP request. This variable
    ' is then used to determine how many bytes to retrieve
    ' using the Request object's BinaryRead method.
    Dim lngTotalByteCount
    Dim vntRequestData

    lngTotalByteCount = Request.TotalBytes

    vntRequestData = Request.BinaryRead(lngTotalByteCount)

    %>
Hinweise
Meist ist es nicht nötig, auf Daten im HTTP-Anforderungs-Body auf der niedrigen Ebene zuzugreifen, wie sie von der Methode BinaryRead des Request-Objekts bereitgestellt wird. Daher brauchen Sie den Wert der TotalBytes-Eigenschaft normalerweise nicht abzurufen. In den meisten Fällen verwenden Sie die Form- oder die QueryString-Kollektion, um auf die Request-Daten zuzugreifen. Im obigen Beispiel repräsentiert der Wert vntRequestData die gesamte Menge an gesendeten Daten und nicht einfach die Größe der hochgeladenen Datei, d. h. dass auch der gesamte Multipart-Header in dieser Gesamtmenge enthalten ist. Um vom obigen Upload nur die Größe des Dateiinhalts abzurufen, müssten Sie die Header-Informationen ausfiltern.

ClientCertificate |
    strKeyName = Request.ClientCertificate.Key(3)
    strKeyValue = Request.ClientCertificate.Item(strKeyName)
  Die ClientCertificate-Kollektion des Request-Objekts bietet Zugriff auf die Zertifizierungsfelder des digitalen Zertifikats des Clients. Client-Zertifikate werden an den Webserver gesendet, wenn ein Client-Browser das Secure-Sockets-Layer-Protokoll unterstützt und über dieses mit einem Webserver verbunden ist (d. h. die URL beginnt mit https:// anstelle von http://). Wenn Sie beispielsweise Internet Explorer verwenden und mit einer Internet-Information-Server-Website verbunden sind, auf der SSL läuft, so enthält jede Anforderung, die Ihr Browser stellt, Ihr Client-Zertifikat, falls Sie eines besitzen. Die Felder eines Client-Zertifikats sind durch die Empfehlung X.509 der International Telecommunications Union (ITU) festgelegt. Die ClientCertificate-Kollektion besitzt, wie auch andere ASP-Kollektionen, die folgenden Eigenschaften: Item Gibt den Wert eines bestimmten Elements in der Kollektion zurück. Das gewünschte Element kann mit einer Indexnummer oder einem Schlüssel angegeben werden. Key Repräsentiert den Namen eines bestimmten Elements in der ClientCertificate-Kollektion. So wie der Wert jedes Elements durch die Eigenschaft Item repräsentiert wird, wird der Name jedes Elements durch die Eigenschaft Key repräsentiert. Wenn Sie den Namen eines bestimmten Schlüssels nicht kennen, können Sie ihn durch seine Ordnungszahl abrufen. Angenommen, Sie möchten den Schlüsselnamen des dritten Elements in einer Kollektion wissen und anschließend seinen Wert. Dazu können Sie folgenden Code verwenden:
      strKeyName = Request.ClientCertificate.Key(3)
      strKeyValue = Request.ClientCertificate.Item(strKeyName)
  Wenn Sie andererseits wissen, dass der Schlüsselname des dritten Elements "ISSUER" ist, können Sie den Wert dieses Elements mit Hilfe des folgenden Codes ermitteln:
      strKeyValue = Request.ClientCertificate.Item("ISSUER")
Wie bei anderen ASP-Kollektionen können Sie den Wert eines Felds in der ClientCertificate-Kollektion über die Eigenschaft Item abrufen. Da Item die Standardeigenschaft der Kollektion ist, kann die Syntax abgekürzt werden, so dass die Verwendung der Eigenschaft Item nicht ausdrücklich genannt ist. Hier ein Beispiel:
    strCertIssuer = Request.ClientCertificate("Issuer")
Dies ist eine Abkürzung für:
    strCertIssuer = Request.ClientCertificate.Item("Issuer")
Weitere Informationen zu den Eigenschaften Item, Key und Count einer Kollektion finden Sie im Abschnitt 4.2 in Kapitel 4. Die verfügbaren Key-Werte sind vordefiniert und lauten folgendermaßen: Certificate Ein String, der den gesamten Binärstrom des Zertifikatinhalts umfasst. Der Inhalt wird im Standard-ASN.1-Format (Abstract Syntax Notation One) abgerufen, dem internationalen Standard für die Darstellung von Datentypen und -strukturen. Flags Ein Set an Flags, die zusätzliche Informationen über das Client-Zertifikat bieten. Diese Flags sind Ganzzahlwerte, die durch die Konstanten ceCertPresent und ceUnrecognizedIssuer repräsentiert werden können, wenn die VBScript-Include-Datei cervbs.inc in die Skripts eingebunden ist. (Weitere Information zum Einbinden von Dateien finden Sie in Kapitel 11.) Wie der Name der Konstante schon ahnen lässt, bedeutet ceCertPresent, dass ein Client-Zertifikat vorhanden ist, und ceUnrecognizedIssuer bedeutet, dass das digitale Zertifikat des Clients von einer unbekannten Zertifizierungsstelle ausgegeben worden ist. Issuer Ein String, der aus mehreren Informationsteilen über den Aussteller des digitalen Client-Zertifikats besteht. Wird kein SubKey-Parameter (wird weiter hinten erläutert) beigefügt, wird bei Verwendung des Schlüssels Issuer eine, durch Kommas getrennte, Liste aller Issuer-Unterfeldwerte ausgegeben (z. B. C=US, O=VeriSign, GN=Weissinger usw.). SerialNumber Eine ASCII-Darstellung des Hexadezimalwerts der Seriennummer des Client-Zertifikats. Dieser Wert wird vom Aussteller bereitgestellt. Beim Abrufen des Schlüssels SerialNumber erhalten Sie eine Nummer wie 0A-B7-34-23. Subject Eine Liste durch Komma getrennter Strings, die Informationen über den Besitzer des digitalen Zertifikats liefern. Wird kein SubKey (Unterschlüssel) bereitgestellt, wird die gesamte Liste durch Kommas getrennter Unterfelder abgerufen, ähnlich der für den Schlüssel Issuer beschriebenen Liste. ValidFrom Der Termin, zu dem das Zertifikat gültig wird. Der Wert dieses Schlüssels wird im Datums- und Zeitformat ausgegeben. Ein möglicher Wert des Schlüssels ValidFrom kann beispielsweise 1/29/98 12:01:00 A.M. sein (in des USA). ValidUntil Der Termin, zu dem das Zertifikat ungültig wird. Der Wert dieses Schlüssels wird im Datums- und Zeitformat ausgegeben. Ein möglicher Wert des Schlüssels ValidUntil kann beispielsweise be 1/28/99 11:59:59 P.M. sein (in den USA). Einigen der Schlüsselwerte können Sie einen "Unterschlüssel" zuweisen, um von der Issuer- oder der Subject-Schlüsselliste ein individuelles Unterfeld abzurufen. Angenommen, Sie möchten aus der Issuer-Schlüsselliste den Unterschlüssel für das Ursprungsland abrufen, so verwenden Sie folgenden Code:
    Request.ClientCertificate("IssuerC")
Und wenn Sie den Unterschlüssel für den Ort abrufen wollen, verwenden Sie folgende Syntax:
    Request.ClientCertificate("SubjectL")
Anhand des ASN.1-Bezeichners können Sie vom String-Wert des Certificate-Schlüssels auch einen Wert von einem spezifischen Unterschlüssel abrufen, einschließlich der hier nicht angeführten. Ein ASN.1-Bezeichner ist eine Liste von durch Punkte getrennten Ziffern, ähnlich wie bei einer IP-Adresse. Allerdings ist ein ASN.1-Bezeichner nicht auf 255 Zeichen beschränkt. Hier ein Beispiel: 3.56.7886.34. Folgende Unterschlüssel sind verfügbar: C Das Ursprungsland des Subject oder Issuer. CN Der gewöhnliche Name des Subject-Schlüssels. Dieser Unterschlüssel ist für den Issuer-Schlüssel nicht definiert. GN Der für Subject oder Issuer angegebene Name. I Die Initialen von Subject oder Issuer. L Der Ort von Subject oder Issuer. O Der Unternehmens- oder Firmenname von Subject oder Issuer. OU Der Name der Abteilung innerhalb einer Firma für Subject oder Issuer. S Das Bundesland von Subject oder Issuer. T Die Anrede oder der Titel von Subject oder Issuer.
Beispiel:
    <%

    ' The following code retrieves the country of origin
    ' for the client's certificate issuer.
    strCertIssuerCountry = Request.ClientCertificate("IssuerC")

    %>

    <!-- #include file="cervbs.inc" -->

    <%
    ' The next example code determines whether the
    ' issuer is recognized by using the flags key.
    If Request.ClientCertificate("Flags") _
       and ceUnrecognizedIssuer Then
    %>
       Your identification is in question because your issuer
       is not recognized.
    <%
    Else
    %>
       Welcome to our site.
    <%
    End If

    ' Finally, the following code iterates through the
    ' ClientCertificate collection and writes the key-key
    ' value pairs to the response buffer.
    For Each key In Request.ClientCertificate
       Response.Write "The " & key & " key contains the value "
       Response.Write Request.ClientCertificate(key) & "<BR>"
    Next

    %>
Hinweise
Damit Sie Informationen aus dem digitalen Zertifikat des Clients abrufen können, müssen Sie sicherstellen, dass der Client-Browser für seine Anforderungen an Ihre Site das SSL3.0/PCT1-Protokoll verwendet. Der einfachste Weg ist, ein Element aus der ClientCertificate-Kollektion abzurufen. Sie müssen allerdings sicherstellen, das Ihr IIS-Webserver für die Anforderung von Client-Zertifikaten eingerichtet ist. Sendet der Client kein digitales Zertifikat, so ist jeder Versuch, die ClientCertificate-Kollektion abzufragen, vergeblich. Die ITU-Empfehlung X.509 ist nur eine Empfehlung. Sie ist nicht als offizieller Standard anerkannt. Aus diesem Grund kann es vorkommen, dass die Zertifikate verschiedener Firmen leicht unterschiedlich funktionieren oder nicht alle die Felder enthalten, die Sie versuchen abzurufen. Um sicherzustellen, dass Sie Ihre Clients korrekt identifizieren, empfiehlt es sich, mit der ClientCertificate-Kollektion etwas zu experimentieren, bevor man sich darauf verlässt.

Cookies |
    Set-Cookie: NAME=VALUE; expires=DATE; domain=DOMAIN_NAME;
    path=PATH; secure
Bevor die Cookies-Kollektion erörtert wird, soll kurz das Konzept von HTTP-Cookies vorgestellt werden. Dies ist nur eine kurze Übersicht. Weitere Informationen erhalten Sie entweder auf der "Preliminary Specification" von Netscape unter http://www.netscape.com/newsref/std/cookie_spec.html oder auf "Cookie Central", eine Site, auf der alle cookie-relevanten Informationen zusammenlaufen. Besonders empfehlenswert ist die Seite http://www.cookiecentral.com/unofficial_cookie_faq.htm. Das Problem mit einem zustandslosen Protokoll wie HTTP liegt darin, dass es sowohl Server als auch Client zwingt, eine nicht unerhebliche Menge an Arbeit zu wiederholen. Bei einem wahrhaft zustandslosen Protokoll etwa müsste der Webserver jedes Mal, wenn Sie eine Seite der Site laden, fragen, wer Sie sind, selbst wenn Sie diese Seite von einer anderen Seite derselben Site aus öffnen. Ebenso wäre Ihre Interaktion auf das beschränkt, was Sie auf einer Seite eingeben und speichern können, denn ohne eine Möglichkeit, die Daten aus einer Seite zu speichern, hat eine zweite Seite keine Möglichkeit, an diese Daten zu gelangen. Die Netscape Communications Corp. erkannte dieses Problem schon früh und schuf eine Methode, anhand derer der Webserver kleine Informationseinheiten auf dem Client-Rechner speichern konnte. Diese Informationen werden im Gegenzug jedes Mal dann an den Server gesendet, wenn der Client eine Seite aus demselben Bereich anfordert, von dem er diese Informationen ursprünglich erhalten hat. Diese kleine Informationseinheit ist die Wurzel von Netscapes "Persistent Client State"-Mechanismus, auch "Cookies" genannt. (Es ist interessant zu beobachten, dass gemäß der vorläufigen Spezifikation von Netscape dieses Zustandsobjekt "ohne zwingenden Grund" ein "Cookie" genannt wurde.) Durch die Verwendung von Cookies können Webserver Informationen auf dem Client-Rechner speichern, und zwar auf sichere, einfach abzurufende Art, die fast den gesamten E-Commerce erst möglich macht. Websites können jetzt mitverfolgen, wer Sie sind, wann Sie die Site zuletzt besucht haben und z. B. welche Art von Büchern Sie mögen. Das Konzept der Cookies ist ein sehr einfaches. Cookies werden mit Hilfe eines Set-Cookie-HTTP-Antwort-Headers in dem folgenden Format gesendet (beachten Sie, dass der Set-Cookie-Header nur aus einer Zeile bestehen sollte):
    Set-Cookie: NAME=VALUE; expires=DATE; domain=DOMAIN_NAME;
    path=PATH; secure
  Die Syntax setzt sich aus folgenden Elementen zusammen: NAME=VALUE Das Name/Wert-Paar des Cookies, das der Webserver auf dem Client-Rechner speichern möchte. Der Wert kann jedes beliebige Zeichen enthalten, mit Ausnahme von Leerzeichen, Kommas und Semikola. Dieser Teil des Cookies ist obligatorisch. expires Speichert ein Datum, ab dem der Browser das Cookie wieder löschen kann. Wird kein expires-Attribut angegeben, gilt das Cookie nur für die aktuelle HTTP-Sitzung. Das Format dieses Datums ist wie folgt:
      Wdy, DD-Mon-YYYY HH:MM:SS GMT
Beachten Sie, dass die Uhrzeit in Greenwich Mean Time (GMT) anzugeben ist. domain Jedes Mal, wenn der Anwender eine bestimmte URL aufruft, werden die domain-Attribute aller Cookies auf dem Rechner mit der Domäne der URL verglichen. Wenn das Attribut domain eines Cookies auf dem Rechner des Anwenders dem "Anhang" der URL-Domäne (die letzten zwei Segmente des vollständigen Domänennamens) entspricht, so wird dieses Cookie als Request-Header (mehr dazu später) an diese URL gesendet. Eine Domäne muss mindestens zwei Punkte im Namen haben, damit das domain-Attribut eines Cookies an den Client gesendet wird. www.microsoft.com beispielsweise kann Cookies an Ihren Rechner senden (und macht das auch), aber mydomain.com kann es nicht. Der Wert des zu Microsoft gehörigen Cookie-Attributs domain wäre Microsoft.com. Dieses Cookie würde so an jede URL gesendet, die mit Microsoft.com endet, z. B. www.microsoft.com, home.microsoft.com. Entsprechend können nur Seiten innerhalb dieser Domäne Cookies mit diesem Domänenattribut setzen. www.microsoft.com beispielsweise kann Cookies mit der Domäne Microsoft.com senden, aber www.ora.com kann das nicht. Ist im Cookie, das an den Client-Browser gesendet wird, das Attribut domain nicht angegeben, so ist der Standardwert der Domänenname des Cookie-Senders. Dieser Parameter ist optional. path Die Teilmenge aller URLs innerhalb der vom domain-Attribut des Cookies definierten Domäne. Dieser Wert bestimmt, ob das Cookie an den Server zurückgesendet wird. Wird kein path-Attribut gesendet, so wird als Standard der Pfad des Dokuments, das im Browser angezeigt wird, verwendet. Cookies von der Seite http://www.oreilly.com/newtitles/upcoming.ASP ohne spezielles path-Attribut würden beispielsweise mit dem Standardpfadwert /newtitles/ versendet. Der Browser sendet Cookies von dieser Seite nur an Seiten in diesem Pfad. Der grundlegendste Pfad für eine Domäne ist "/". Dieses Attribut ist optional. Diese Diskussion über Cookie-Pfade bringt einen oft verwirrenden Punkt zur Sprache. Speichert der Browser-Rechner je ein Cookie pro Seite in einem Pfad oder speichert er nur ein Cookie, das er wiederholt verwendet? Die Antwort ist, dass der Browser für jeden einzelnen Cookie-Wert ein Cookie speichert. Es gibt nicht ein Cookie, das alle Cookie-Werte für die aktuelle Seite enthält. Jedes Cookie hat einen eigenen Eintrag. secure Ist bei einem Cookie dieses Attribut angegeben, so weist es den Browser an, dieses Cookie nur an Seiten innerhalb des im path-Attributs angegebenen Pfads zu senden, wenn Server und Browser über einen sicheren Kanal (z. B. HTTPS) kommunizieren. Öffnet der Anwender in seinem Browser eine URL, zu der auf dem lokalen Rechner ein Cookie gespeichert ist, so sendet der Browser einen Request-Header in dem folgenden Format:
    Cookie:Name1=Value1;Name2=Value2;...NameX=ValueX;
Dabei gilt Folgendes: NameX Der Name eines Cookies zu dieser URL. ValueX Der Wert des Cookies mit dem Namen NameX. Als Wert ist ein String zulässig, der keine Leerzeichen, Semikola oder Kommas enthält. Durch ein Beispiel wird das Ganze verständlicher. Angenommen, ein Client öffnet eine URL und sein Browser empfängt folgende HTTP-Antwort-Header:
    Set-Cookie: userid=a.keyton.weissinger; domain=yourbooks.com;
    path=/; expires=Thursday, 10-Nov-2000 23:59:59

    Set-Cookie: usersel=aspbooks; domain=yourbooks.com;
    path=/sales/; expires=Monday, 01-Jan-2010 23:59:59
Das erste Cookie wird zwischen jetzt (bzw. damals) und dem 10. November 2000 um 23:59 Uhr an den Webserver gesendet, wenn der Client eine Seite einer Domäne öffnet, deren letzte zwei Segmente yourbooks.com lauten. Der HTTP-Anforderungs-Header sieht in etwa so aus:
    Cookie: userid=a.keyton.weissinger
Das zweite Cookie wird zwischen jetzt und dem 1. Januar 2010 um 23:59 Uhr an jede Seite in der Domäne yourbooks.com gesendet, deren Pfad /sales/irgendwas lautet. Betrachten Sie beispielweise den folgenden Anforderungs-Header:
    Cookie: usersel=aspbooks
Dieser Header würde an http://www.yourbooks.com/sales/default.ASP oder an http://www.yourbooks.com/sales/final/asp oder sogar an http://www.yourbooks.com/sales/checkout/default.ASP gesendet werden. Wenn schließlich beide Sets an Kriterien erfüllt sind (also userid des ersten Cookies und usersel des zweiten), so wird vom Browser des Anwenders folgender Cookie-Header gesendet:
    Cookie: userid=a.keyton.weissinger; usersel=aspbooks
  Es gibt noch viele Einzelheiten zum Thema Cookies, über die Sie sich bewusst sein sollten, wenn Sie Cookies häufiger einsetzen wollen. Studieren Sie dazu die oben genannten Websites. Die kurze Übersicht ist jetzt abgeschlossen, als Nächstes soll die Cookies-Kollektion des Objekts Request betrachtet werden. Anhand der Cookies-Kollektion des Objekts Request kann Ihre ASP-Anwendung die Werte von Cookies und Cookie-Dictionary-Elementen aus der HTTP-Anforderung des Clients abrufen. Ebenso wie andere ASP-Kollektionen besitzt auch die Cookies-Kollektion die folgenden Eigenschaften: Item Repräsentiert den Wert eines bestimmten Cookies in der Kollektion. Um ein Cookie anzugeben, verwenden Sie eine Indexnummer oder einem Schlüssel. Key Repräsentiert den Namen eines bestimmten Elements in der Cookies-Kollektion. So wie der Wert jedes Elements durch die Eigenschaft Item repräsentiert wird, wird der Name jedes Elements durch die Eigenschaft Key repräsentiert. Wenn Sie den Namen eines bestimmten Schlüssels nicht kennen, rufen Sie ihn mit Hilfe seiner Ordnungszahl ab. Angenommen, Sie möchten den Schlüsselnamen des dritten Elements in der Kollektion erfahren und anschließend dessen Wert abrufen. Hierfür können Sie folgenden Code verwenden:
      strKeyName = Request.Cookies.Key(3)
      strKeyValue = Request.Cookies.Item(strKeyName)
  Wenn Sie andererseits wissen, dass der Schlüsselname des dritten Elements "STATE" ist, können Sie den Wert dieses Elements mit Hilfe des folgenden Codes ermitteln:
      strKeyValue = Request.Cookies.Item("STATE")
Count Repräsentiert die Anzahl der Elemente in der Kollektion. Wie bei anderen ASP-Kollektionen können Sie den Wert eines beliebigen Felds der Cookies-Kollektion über die Eigenschaft Item abrufen. Beachten Sie, dass die Syntax in den hier gegebenen Beispielen und Erläuterungen abgekürzt worden ist, so dass die Verwendung der Eigenschaft Item nicht ausdrücklich gezeigt wird. Hier ein Beispiel:
    strLastSearch = Request.Cookies("LastSearch")
Dies ist nur eine Abkürzung für:
    strLastSearch = Request.Cookies.Item("LastSearch")
Weitere Informationen zu den Eigenschaften Item, Key und Count einer Kollektion finden Sie im Abschnitt 4.2 in Kapitel 4. Ein Cookie in der Cookies-Kollektion kann nicht nur einfache Werte speichern, sondern auch ein Cookie-Dictionary repräsentieren. Ein Dictionary ist ein Konstrukt, das einem assoziativen Array ähnelt, und zwar in sofern als jedes Element des Arrays durch seinen Namen identifizierbar ist. Beachten Sie jedoch, dass ein Cookie zwar ein Cookie-Dictionary enthalten kann, aber keine komplexeren Datentypen, wie etwa Objekte. Um einen bestimmten Wert innerhalb eines Cookie-Dictionarys anzugeben, verwenden Sie einen Unterschlüssel (SubKey). Angenommen, ein bestimmtes Cookie repräsentiert die fünf Farben, die ein Anwender auf einer Webseite ausgewählt hat. Das Cookie selbst soll Colors heißen und die Unterschlüssel haben die folgenden Namen: color1, color2, . . . color5. Um den Wert in color3 zu bestimmen, verwenden Sie in etwa einen Code wie den folgenden:
    strColor3 = Request.Cookies("Colors")("color3")
Um festzustellen, ob für ein bestimmtes Cookie Unterschlüssel bestehen, verwenden Sie die Eigenschaft HasKeys wie folgt:
    blnHasKeys = Request.Cookies("Colors").HasKeys
    If blnHasKeys Then
       strColor3 = Request.Cookies("Colors")("color3")
    End If
Beispiel
    <%
    ' The following code iterates through the Cookies collection.
    ' If a given cookie represents a cookie dictionary, then
    ' a second, internal for...each construct iterates through
    ' it retrieving the value of each subkey in the dictionary.
    Dim strCookie
    Dim strSubKey

    Dim str3rdCookieValue
    Dim strCompanyCookieValue

    For Each strCookie In Request.Cookies
       If Request.Cookies(strCookie).HasKeys Then

          ' The cookie is a dictionary. Iterate through it.
    %>
          The cookie dictionary <%=strCookie%> has the
          following values:
    <%
          For Each strSubKey In Request.Cookies(strCookie)
    %>
                 SubKey: <%= strSubKey %><BR>
                 Value:
             <%=Request.Cookies(strCookie)(strSubKey)%><BR>
    <%
          Next
       Else
          ' The cookie represents a single value.
    %>
          The cookie <%=strCookie%> has the following value:
          <%=Request.Cookies(strCookie)%> <BR>
    <%
       End If

    Next

    ' The following code retrieves the value of the third cookie
    ' in the Cookies collection.
    str3rdCookieValue = Request.Cookies(3)

    ' The following code retrieves the value of the "company"
    ' cookie in the Cookies collection.
    strCompanyCookieValue = Request.Cookies("Company")

    %>
Hinweise
Wenn Sie auf ein Cookie zugreifen, das ein Cookie-Dictionary repräsentiert und keinen Unterschlüssel angeben, erhalten Sie einen String-Wert wie den folgenden:
    FirstSubKey=FirstSubKeyValue&SecondSubKey=SecondSubKeyValue
Teil der Cookie-Struktur auf dem Client-Rechner ist ein Pfad, der die Webseite repräsentiert, von der der Client das Cookie erhalten hat. Ein wichtiger Punkt über das Abrufen von Cookie-Werten kommt ins Spiel, wenn zwei Cookies mit demselben Namen aber unterschiedlichen Pfaden existieren. In einem solchen Fall wird nur das Cookie aus dem tieferen Verzeichnis abgerufen. Wenn etwa die Webseite http://www.MyCompany.com/ContribApp/Contrib1.ASP ein Cookie mit dem Namen UserPref ablegt und eine zweite Webseite mit einem tieferen Pfad, z. B. http://www.MyCompany.com/ContribApp/Addresses/AddrContrib1.ASP, ebenfalls ein Cookie mit dem Namen UserPref ablegt, so wird beim Abrufen eines Cookies mit Namen UserPref nur das zweite UserPref-Cookie zurückgegeben. Wenn Sie versuchen, den Wert eines Unterschlüssels von einem Cookie-Namen abzurufen, der kein Cookie-Dictionary repräsentiert, so ist das Ergebnis Null. Aus diesem Grund ist es wichtig, vorher die Eigenschaft HasKeys zu nutzen. Wie Sie wissen, ist der "HTTP Persistent Client State"-Mechanismus (für die meisten Leute schlicht "Cookies") eine sich ständig weiterentwickelnde Empfehlung. Jeder Cookie-Spezifikationsentwurf bleibt nur sechs Monate gültig. Den momentan aktuellen Entwurf finden Sie unter ftp://ftp.isi.edu/internet-drafts/draft-ietf-http-state-man-mec-08.txt. In diesem Dokument (bzw. seiner jeweils aktuellen Version) werden Sie erfahren, dass die neueste Cookies-Spezifikation die ursprünglich von Netscape vorgeschlagene bei Weitem überbietet. Offensichtlich unterstützt die Cookies-Kollektion des Objekts Request nur einen Teil dieser Spezifikation. Wenn aus dem Entwurf erst einmal ein Standard geworden ist, werden über die Request-Cookies-Kollektion vermutlich weitere Aspekte eines Cookies verfügbar sein.

Form |
    <FORM ACTION = "RecordPrefs.asp" METHOD = POST>
    Name: <INPUT TYPE = TEXT NAME = "Name"><BR>
    Color Pref: <SELECT NAME = "optColor">
    <OPTION VALUE = "red" SELECTED>Red
    <OPTION VALUE = "blue" >Blue
    <OPTION VALUE = "green" >Green
    </SELECT><BR>
    Have a Modem? <INPUT TYPE = CHECKBOX NAME = "Modem"><BR>
    <INPUT TYPE=submit VALUE=submit>
    </FORM>
  Die Form-Kollektion gestattet den Abruf von Informationen, die auf dem Client in ein HTML-Formular eingegeben und mit Hilfe der Methode POST an den Server gesendet worden sind. Die Information befindet sich im Body der vom Client gesendeten HTTP-Anforderung. Ebenso wie andere ASP-Kollektionen besitzt auch die Form-Kollektion die folgenden Eigenschaften: Item Repräsentiert den Wert eines bestimmten Elements in der Kollektion. Das gewünschte Element kann mit einer Indexnummer oder einem Schlüssel angegeben werden. Im Falle der Form-Kollektion repräsentiert die Indexnummer die Nummer des betreffenden Elements im HTML-Formular. Betrachten Sie beispielsweise den folgenden Code für ein HTML-Formular:
      <FORM ACTION = "RecordPrefs.asp" METHOD = POST>
      Name: <INPUT TYPE = TEXT NAME = "Name"><BR>
      Color Pref: <SELECT NAME = "optColor">
      <OPTION VALUE = "red" SELECTED>Red
      <OPTION VALUE = "blue" >Blue
      <OPTION VALUE = "green" >Green
      </SELECT><BR>
      Have a Modem? <INPUT TYPE = CHECKBOX NAME = "Modem"><BR>
      <INPUT TYPE=submit VALUE=submit>
      </FORM>
  Innerhalb von RecordPrefs.ASP ist "Name" das erste Element (Element 1). Das dritte Element ist "Modem." Beachten Sie, dass die Nummerierung bei 1 (eins) beginnt. Key Repräsentiert den Namen eines bestimmten Elements in der Form-Kollektion. So wie der Wert jedes Elements durch die Eigenschaft Item repräsentiert wird, wird der Name jedes Elements durch die Eigenschaft Key repräsentiert. Wenn Sie den Namen eines bestimmten Schlüssels nicht kennen, rufen Sie ihn mit Hilfe seiner Ordnungszahl ab. Angenommen, Sie möchten den Schlüsselnamen des dritten Elements in der Kollektion erfahren und anschließend dessen Wert abrufen. Hierfür können Sie folgenden Code verwenden:
      strKeyName = Request.Form.Key(3)
      strKeyValue = Request.Form.Item(strKeyName)
  Wenn Sie andererseits wissen, dass der Schlüsselname des dritten Elements "STATE" ist, können Sie den Wert dieses Elements mit Hilfe des folgenden Codes ermitteln:
      strKeyValue = Request.Form.Item("STATE")
Beachten Sie, dass Sie sich immer auf die Reihenfolge verlassen können, in der die Formularelemente gespeichert sind. Angenommen, Sie haben acht Elemente in einem eingereichten Formular. Sie können nicht wissen, dass das erste Element im Formular dem ersten Element in der Form-Kollektion entspricht. Aus diesem Grund sollten Sie zur Identifizierung eines bestimmten Elements in einem Formular immer einen Schlüssel-String verwenden. Count Gibt die Anzahl der Elemente in der Kollektion zurück. Wie bei anderen ASP-Kollektionen können Sie den Wert eines beliebigen Felds der Form-Kollektion über die Eigenschaft Item abrufen. Beachten Sie, dass die Syntax in den nachfolgenden Beispielen und Erläuterungen abgekürzt worden ist, so dass die Verwendung der Eigenschaft Item nicht ausdrücklich gezeigt wird. Hier ein Beispiel:
    strFirstName = Request.Form("txtFirstName")
Dies ist nur eine Abkürzung für:
    strFirstName = Request.Form.Item("txtFirstName")
Weitere Informationen zu den Eigenschaften Item, Key und Count einer Kollektion finden Sie im Abschnitt 4.2 in Kapitel 4.
Beispiel
Alle Beispiele zur Form-Kollektion des Objekts Request verwenden das folgende HTML-Formular:
    <HTML>
    <HEAD>
    <TITLE>User Information</TITLE>
    </HEAD>
    <BODY>
    <CENTER>
    <H1>User Information</H1>
    Please enter your user information using the form below:
    <FORM NAME = "frmInfo" ACTION="UserInfo.ASP"
          METHOD = "POST">
    First Name:  <INPUT TYPE="text" NAME = "txtFirstName"><BR>
    Last Name:   <INPUT TYPE="text" NAME = "txtLastName"><BR>
    Zipcode:     <INPUT TYPE="text" NAME = "txtZipCode"><BR>
    Occupation:  <INPUT TYPE="text" NAME = "txtOccupation"><BR>
    Please select your connection speed:
    <SELECT NAME = "optConnSpeed">
    <OPTION VALUE = "28.8" SELECTED>28.8 Modem
    <OPTION VALUE = "ISDN" >ISDN
    <OPTION VALUE = "T1" >T1
    <OPTION VALUE = "T3" >T3
    </SELECT><BR>
    Below, select all the peripherals you have:
    <INPUT TYPE = "checkbox" NAME = "chkPeriph"
           VALUE = "Joystick">Joystick<BR>
    <INPUT TYPE = "checkbox" NAME = "chkPeriph"
           VALUE= "GraphicsAccel">3D Graphics Card<BR>
    <INPUT TYPE = "checkbox" NAME = "chkPeriph"
            VALUE = "Printer">Printer<BR>
    <BR>
    Check here if it's ok to send your information:
    <INPUT TYPE = "checkbox" NAME = "chkSellInfo"><BR>

    <INPUT TYPE = "Submit" VALUE = "Submit User Info">

    </FORM>
    </BODY>
    </HTML>
Sobald auf Client-Seite im Formular auf die Schaltfläche Submit geklickt wird, wird die Formularinformation über die HTTP-Methode Post an den Webserver gesendet, und zwar im Body der HTTP-Anforderung. Der nachfolgende Code könnte in UserInfo.ASP verwendet werden, um im obigen Beispiel die Werte der spezifischen Elemente im Formular frmInfo zu bestimmen. In diesem Code wird vorausgesetzt, dass Sie die genaue Bezeichnung der Felder kennen, die zu verarbeiten sind.
    <%

    ' The following code example demonstrates the use of
    ' the Form collection of the Request object to retrieve
    ' the values entered by the client into an HTML form.
    Dim strFirstName
    Dim strLastName
    Dim strZipCode
    Dim strOccupation
    Dim blnSendInfo
    Dim strConnSpeed
    Dim intPeriphCount
    Dim aryPeripherals( )
    Dim chkItem

    intPeriphCount = 0

    ' Retrieve the information from the form's text boxes.
    strFirstName    = Request.Form("txtFirstName")
    strLastName     = Request.Form("txtLastName")
    strZipCode      = Request.Form("txtZipCode")
    strOccupation   = Request.Form("txtOccupation")

    ' Retrieve the information from the Sell Information
    ' checkbox.
    blnSendInfo     = Request.Form("chkSellInfo")

    ' Determine the connection speed from the Connection
    ' Speed option buttons.
    strConnSpeed    = Request.Form("optConnSpeed")

    ' Populate an array with the peripherals the user has.
    For Each SubKey in Request.Form("chkPeriph")
       ReDim Preserve aryPeripherals(intPeriphCount + 1)
       intPeriphCount = intPeriphCount + 1
       aryPeripherals(intPeriphCount) = _
          Request.Form("chkPeriph")(intPeriphCount)

    Next
    %>
Hinweise
Wenn Sie auf ein Element ohne Index verweisen und dieses Element mehrere Werte enthält, so gibt der Code einen durch Kommas getrennten String zurück. Angenommen, in der Form-Kollektion weiter vorne im Kapitel würde anstelle eines Unterschlüssels mit dem Element chkPeriph die folgende Code-Zeile verwendet werden:
    response.write Request.Form("chkPeriph")
Weiter angenommen, es würden alle drei Optionen ausgewählt (Joystick, GraphicsAccel und Printer), so würde diese Codezeile in dem folgenden String resultieren:
    Joystick, GraphicsAccel, Printer
Ihre Anwendung kann auch nicht analysierte Daten aus der HTTP-Anforderung des Clients abrufen. Um nicht analysierte Daten aus dem HTTP-Anforderungs-Body abzurufen, verwenden Sie Request.Form ohne Parameter. Beachten Sie, dass es problematisch sein kann, nicht analysierte HTTP-Anforderungsdaten, insbesondere Binärdaten, in dieser Weise zu verwenden. Immerhin gibt es verschiedene ActiveX-Steuerelemente und Java-Applets, die für ein Abrufen binärer Daten weitaus effizienter eingesetzt werden können. Um Informationen von einem HTML-Formular an eine ASP-Anwendung zu übermitteln, müssen Sie das Attribut ACTION des Tags <FORM> auf den Namen der Datei einstellen, die die HTML-Formulardaten verarbeitet. Diese ASP-Seite muss sich entweder im selben virtuellen Verzeichnis befinden oder über sein virtuelles Verzeichnis angegeben werden. Sie können das von einer HTML-Seite oder von einer anderen ASP-Datei aus machen. Allerdings ist einer der wichtigsten Anwendungszwecke dieses Vorgangs die Konstruktion einer ASP-Seite, die sich selbst aufruft. Das ist nicht unbedingt schneller, doch seine Entwicklung ist effizienter. Das folgende Beispiel zeigt eine einfache ASP-Anwendung, die ein HTML-Formular erstellt, dessen Eingabedaten von derselben ASP-Anwendung verarbeitet werden:
    <%
    ' UserInfo2.ASP
    ' The following code determines whether the HTML form (see
    ' the bottom portion of the script) has been filled out. If
    ' it has, then some processing takes place and one HTML output
    ' is sent back to the client. If not, the HTML form is sent to
    ' the client.
    If Not IsEmpty(Request.Form("txtFirstName")) And _
       Not IsEmpty(Request.Form("txtLastName")) Then

       ' The form has been filled out and the reply is
       ' a brief thank you.
    %>
       <HTML>
       <HEAD><TITLE>Thank You</TITLE>
       </HEAD>
       <BODY>
       Thank you, <%= Request.Form("txtFirstName")%>
    <%= Request.Form("txtLastName")%> for your information.
    Have a nice day.
       </BODY>
       </HTML>
    <%
    Else
    %>
       <HTML>
       <HEAD><TITLE>Thank You</TITLE>
       </HEAD>
       <BODY>

       <FORM NAME = "frmInfo" ACTION="UserInfo2.ASP"
             METHOD = "POST">
       First Name:  <INPUT TYPE="text" NAME="txtFirstName"><BR>
       Last Name:   <INPUT TYPE="text" NAME="txtLastName"><BR>

       <INPUT TYPE = "Submit" VALUE = "Submit User Info">

       </FORM>
       </BODY>
       </HTML>
    <%
    End If

    %>
Dieses Skript bestimmt zunächst, ob die Formularelemente vom Client ausgefüllt worden sind. Ist das der Fall, so sendet dieses Skript ein kurzes "Thank You" an den Client und das Skript ist beendet. Wurden die Informationen nicht eingegeben, so wird das Formular dem Anwender vorgelegt. Diese Technik, obwohl sie hier nur ein rudimentäres Formular verwendet, ist sehr leistungsstark und kann wesentlich zur Modularisierung Ihres Codes beitragen, eine mitunter schwierige Aufgabe in der ASP-Anwendungsentwicklung. Enthält Ihr HTML-Formular zusätzlich (oder anstelle von) Standard-HTML-Formularelementen auch ActiveX-Steuerelemente, so können Sie auf deren Werte in derselben Weise verweisen. Betrachten Sie etwa das folgende (schlichte) HTML-Formular mit einem einzigen Microsoft-Forms-2.0-Textfeld:
    <FORM NAME = "frmInfo" ACTION="UserInfo.ASP"
          METHOD = "POST">
    First Name:
    <OBJECT NAME = "txtFirstName" WIDTH=211 HEIGHT=20
       CLASSID="CLSID:8BD21D10-EC42-11CE-9E0D-00AA006002F3">
       <PARAM NAME="VariousPropertyBits" VALUE="746604571">
       <PARAM NAME="BackColor" VALUE="16777215">
       <PARAM NAME="MaxLength" VALUE="255">
       <PARAM NAME="Size" VALUE="5574;529">
       <PARAM NAME="Value" VALUE=">
       <PARAM NAME="BorderColor" VALUE="0">
       <PARAM NAME="FontCharSet" VALUE="0">
       <PARAM NAME="FontPitchAndFamily" VALUE="2">
       <PARAM NAME="FontWeight" VALUE="0">
    </OBJECT>
    <INPUT TYPE = "Submit" VALUE = "Submit User Info">

    </FORM>
Um von UserInfo.ASP aus auf den in das Textfeld eingegebenen Wert zu verweisen, können Sie die folgende Codezeile verwenden:
    strFirstName = Request.Form("txtFirstName")
Bei einem HTML-Formular mit ActiveX-Steuerelementen, deren Werte anhand eines client-seitigen Skripts überprüft werden, sollten Sie sicherstellen, dass kein Element (etwa die Schaltfläche zum Einreichen des Formulars) den Namen Submit trägt. Das klingt nach einer Kleinigkeit, aber wenn man sie vergisst, ist es nicht möglich, das Formular zu senden! Denken Sie daran, dass die Daten in der Form-Kollektion nur die Daten im HTTP-Anforderungs-Body repräsentieren. Sie können auch die HTTP-Methode Get verwenden, um die Daten vom Client an den Server zu senden. Sie verwenden Get-Ergebnisse in der Information, die vom Client im HTTP-Anforderungs-Header gesendet werden. Um diese Daten abzurufen, müssen Sie die QueryString-Kollektion des Objekts Request verwenden.

QueryString |
    strKeyName = Request.QueryString.Key(3)
    strKeyValue = Request.QueryString.Item(strKeyName)
  Die QueryString-Kollektion gestattet Ihnen, die vom Client mit Hilfe der HTTP-Methode Get gesendeten Informationen abzurufen mit einem HTML-Formular und Daten, die beim Anfordern der Seite an die URL angehängt worden sind. Die QueryString-Kollektion hat weniger Möglichkeiten als die Form-Kollektion, da die Menge an Daten, die im Header einer HTTP-Anforderung gesendet werden können, eingeschränkt ist. Der Erfahrung nach liegt die Grenze bei ca. 2000 Zeichen. Werden im QueryString mehr Zeichen gesendet, werden diese nicht verarbeitet, wenngleich das Skript noch ausgeführt wird. Ebenso wie andere ASP-Kollektionen besitzt auch die QueryString-Kollektion die folgenden Eigenschaften: Item Gibt den Wert eines bestimmten Elements in der Kollektion zurück. Das gewünschte Element kann mit einer Indexnummer oder einem Schlüssel angegeben werden. Im Fall der QueryString-Kollektion steht die Index-Nummer für die Reihenfolge, in der das Element in der URL vorkommt, bzw. für die Nummer des Elements im HTML-Formular (vorausgesetzt die Daten werden mit Hilfe der Methode GET gesendet). Wird zum Einreichen der Formulardaten hingegen die Methode POST verwendet, erscheinen diese HTML-Elemente nicht in der QueryString-Kollektion, sondern in der Form-Kollektion des Objekts Request. Key Gibt den Wert eines bestimmten Elements in der Kollektion zurück. So wie der Wert jedes Elements durch die Eigenschaft Item repräsentiert wird, wird der Name jedes Elements durch die Eigenschaft Key repräsentiert. Wenn Sie den Namen eines bestimmten Schlüssels nicht kennen, rufen Sie ihn mit Hilfe seiner Ordnungszahl ab. Angenommen, Sie möchten den Schlüsselnamen des dritten Elements in der Kollektion erfahren und anschließend dessen Wert abrufen. Hierfür können Sie folgenden Code verwenden:
      strKeyName = Request.QueryString.Key(3)
      strKeyValue = Request.QueryString.Item(strKeyName)
  Wenn Sie andererseits wissen, dass der Schlüsselname des dritten Elements "STATE" ist, können Sie den Wert dieses Elements mit Hilfe des folgenden Codes ermitteln:
      strKeyValue = Request.QueryString.Item("STATE")
Count Die Anzahl der Elemente in der Kollektion. Wie bei anderen ASP-Kollektionen können Sie den Wert eines beliebigen Felds der QueryString-Kollektion über die Eigenschaft Item abrufen. Beachten Sie, dass die Syntax in den nachfolgenden Beispielen und Erläuterungen abgekürzt worden ist, so dass die Verwendung der Eigenschaft Item nicht ausdrücklich gezeigt wird. Hier ein Beispiel:
    strFirstName = Request.QueryString("FirstName")
Dies ist nur eine Abkürzung für:
    strFirstName = Request.QueryString.Item("FirstName")
Weitere Informationen zu den Eigenschaften Item, Key und Count einer Kollektion finden Sie im Abschnitt 4.2 in Kapitel 4.
Beispiel
    <%
    ' This code iterates through the QueryString collection
    ' and fills an array with the values retrieved.
    Dim item
    Dim aryQueryValues( )
    Dim intItemCount

    intItemCount = 0

    For Each item In Request.QueryString
       ReDim Preserve aryQueryValues(intItemCount + 1)
       aryQueryValues(intItemCount) = _
                      Request.QueryString(item)
       intItemCount = intItemCount + 1
    Next
    %>
Hinweise
Wie auch die Elemente in der Form-Kollektion können die Elemente in der QueryString-Kollektion mehrere Werte repräsentieren. Angenommen, bei Ihrer ASP-Datei wurden Daten vom folgenden HTML-Formular eingereicht:
    <FORM NAME = "frmInfo" ACTION="UserInfo2.ASP"
          METHOD = "GET">
    Below, select all the peripherals you have:
    <INPUT TYPE = "checkbox" NAME = "chkPeriph" VALUE =
       "Joystick">Joystick<BR>
    <INPUT TYPE = "checkbox" NAME = "chkPeriph" VALUE=
       "GraphicsAccel">3D Graphics Card<BR>
    </FORM>
Wenn nun der Anwender beide Kontrollkästchen ankreuzt, würden die resultierenden Informationen in der ASP-Anwendung genau so interpretiert als wäre die ASP-Seite anhand der folgenden URL angefordert worden:
    UserInfo2.ASP?chkPeriph=Joystick&chkPeriph=GraphicsAccel
Um auf das erste Element zu verweisen, können Sie den folgenden Code verwenden (beachten Sie dass, wie auch bei anderen ASP-Kollektionen, die Nummerierung der Elemente bei 1 beginnt):
    strFirstOption = Request.QueryString("chkPeriph")(1)
Im folgenden Code wurde kein Unterschlüssel angegeben:
    strOptions = Request.QueryString("chkPeriph")
In diesem Fall hat strOptions den folgenden Wert:
    Joystick, GraphicsAccel
Wiederum wie bei die Form-Kollektion enthält die QueryString-Kollektion Informationen, die vom Client an den Webserver gesendet worden sind. Diese Information kann in Form von Parameter/Wert-Paaren an das Ende der im HTTP-Anforderungs-Header angeforderten URL angehängt werden oder an die URL im Adressfeld des Browsers oder sie stammt aus einem HTML-Formular, dessen Aktion auf die HTTP-Methode Get gesetzt ist. Es gibt einige Einschränkungen bezüglich der Verwendung der QueryString-Kollektion, von denen die wichtigste die begrenzte Länge des Strings ist. Obwohl diese Länge mit dem verfügbaren Client- und Server-Arbeitsspeicher variiert, sollten Sie damit rechnen, dass Sie mit der QueryString-Kollektion nicht mehr als 1800 Zeichen vom Client zum Webserver senden können. Diese Zeichenlänge wird vom Ende des aufgerufenen Skript-Namens bis an das Ende der an die angeforderte URL angehängten Parameterliste gezählt, und zwar einschließlich der Namen, und nicht nur der Werte, der gesendeten Parameter. Wie auch die Elemente in der Form-Kollektion können die Elemente in der QueryString-Kollektion mehrere Werte enthalten. Um die Anzahl der für ein bestimmtes Element in der Kollektion verfügbaren Werte zu bestimmen, verwenden Sie die Eigenschaft Count des betreffenden Elements. Der Wert der Eigenschaft Count entspricht der Anzahl der Werte im Element und beträgt Null (0), wenn sich das Element nicht in der Kollektion befindet. Um alle Werte eines bestimmten Mehrfachwertelements abzurufen, lassen Sie den Indexparameter des betreffenden Elements weg. Die Werte werden als durch Kommas getrennten String zurückgegeben, der nur die Werte des adressierten Elements enthält. Und wiederum wie bei der Form-Kollektion können Sie mit der QueryString-Kollektion nicht analysierte Daten abrufen. Um unverarbeitete, nicht analysierte QueryString-Kollektionsdaten abzurufen, verwenden Sie die Syntax Request.QueryString ohne einen Elementparameter. Auf die Daten in der QueryString-Kollektion kann auch von der ServerVariables-Kollektion des Objekts Request aus zugegriffen werden. Dazu verwenden Sie den Parameter HTTP_QUERYSTRING . Das wird im Abschnitt über die ServerVariables-Kollektion ausführlich erläutert. Schließlich sollten Sie beachten, dass Sie verschiedene Sonderzeichen kodieren müssen, wenn Sie sie im QueryString verwenden: & Das Et-Zeichen (&) wird von ASP zur Abgrenzung einzelner Parameter/Wert-Paare verwendet, die in die QueryString-Kollektion aufgenommen worden sind. ? Das Fragezeichen kennzeichnet den Anfang des QueryStrings, der in der URL hinter Name und Erweiterung der vom Client angeforderten Datei eingefügt wird. % Das Prozentzeichen wird in der Kodierung von Sonderzeichen verwendet. + Das Pluszeichen wird im QueryString anstelle eines Leerzeichens verwendet. Diese Zeichen lassen sich serverseitig mit Hilfe der Methoden URLEncode und HTMLEncode des Objekts Server und client-seitig durch ein selbst geschriebenes Skript verschlüsseln.

ServerVariables |
    strKeyName = Request.ServerVariables.Key(3)
    strKeyValue = Request.ServerVariables.Item(strKeyName)
  Die ServerVariables-Kollektion enthält mehrere vordefinierte Umgebungsvariablen im Kontext der spezifischen HTTP-Anforderung des Clients an den Webserver. Ebenso wie andere ASP-Kollektionen besitzt auch die ServerVariables-Kollektion die folgenden Eigenschaften: Item Der Wert eines bestimmten Elements in der Kollektion. Das gewünschte Element kann mit einer Indexnummer oder einem Schlüssel angegeben werden. Key Gibt den Wert eines bestimmten Elements in der Kollektion zurück. So wie der Wert jedes Elements durch die Eigenschaft Item repräsentiert wird, wird der Name jedes Elements durch die Eigenschaft Key repräsentiert. Wenn Sie den Namen eines bestimmten Schlüssels nicht kennen, rufen Sie ihn mit Hilfe seiner Ordnungszahl ab. Angenommen, Sie möchten den Schlüsselnamen des dritten Elements in der Kollektion erfahren und anschließend dessen Wert abrufen. Hierfür können Sie folgenden Code verwenden:
      strKeyName = Request.ServerVariables.Key(3)
      strKeyValue = Request.ServerVariables.Item(strKeyName)
  Wenn Sie andererseits wissen, dass der Schlüsselname des dritten Elements "QUERY_STRING" ist, können Sie den Wert dieses Elements mit Hilfe des folgenden Codes ermitteln:
      strKeyValue = _
                Request.ServerVariables.Item("QUERY_STRING")
  Oder einfach diesen Code:
      strKeyValue = Request.ServerVariables("QUERY_STRING")
Count Die Anzahl der Elemente in der Kollektion. Wie bei anderen ASP-Kollektionen können Sie den Wert eines Felds in der ServerVariables-Kollektion über die Eigenschaft Item abrufen. Beachten Sie, dass in den nachfolgenden Beispielen und Erläuterungen (und in nahezu allen Beispielen aus anderen Quellen) die Syntax abgekürzt worden ist, so dass die Verwendung der Eigenschaft Item nicht ausdrücklich gezeigt wird. Hier ein Beispiel:
    strRemoteAddr = Request.ServerVariables("REMOTE_ADDR")
Dies ist nur eine Abkürzung für:
    strRemoteAddr = Request.ServerVariables.Item("REMOTE_ADDR")
  Weitere Informationen zu den Eigenschaften Item, Key und Count einer Kollektion finden Sie im Abschnitt 4.2 in Kapitel 4. Die möglichen Werte für Key sind in der folgenden Liste beschrieben: Wenngleich diese Werte typischerweise in Großbuchstaben dargestellt werden, wird in der Eigenschaft Key nicht zwischen Groß- und Kleinschreiung unterschieden. Beachten Sie, dass die Elementwerte der ServerVariables-Kollektion, wie die Elemente anderer ASP-Kollektionen auch, mit Hilfe einer Indexnummer abgerufen werden können. Allerdings sollten Sie wissen, dass sie in der nachfolgenden Liste in alphabetischer Reihenfolge angeführt werden und nicht in der Reihenfolge, in der die Elemente in der ServerVariables-Kollektion vorkommen. ALL_HTTP Ein langer String mit allen vom Client-Browser gesendeten HTTP-Headern. Jedes der folgenden Elemente kann von diesem Element aus analysiert werden. ALL_RAW Ein langer String mit allen vom Client-Browser gesendeten HTTP-Headern, und zwar in unverarbeitetem Zustand. Der primäre Unterschied zwischen dem Wert ALL_RAW und dem Wert ALL_HTTP besteht darin, dass allen Werten des ALL_HTTP-Elements das Präfix HTTP_ vorangestellt wurde und der Header-Name immer in Großbuchstaben geschrieben ist. Jedes der folgenden Elemente kann von diesem Element aus analysiert werden. APPL_MD_PATH Die IIS-Metabase speichert intern alle Einstellungen des Servers. In seiner Funktionsweise ähnelt es der Windows-Registry, nur beinhaltet die Metabase ausschließlich Informationen über Elemente, die (als Snap-Ins) in die Microsoft Management Console eingefügt worden sind. Dazu können Internet Information Server, Index Server, SQL Server 7.0 und andere gehören. Die Informationen in der Metabase sind fast ausschließlich Installations- und Konfigurationsinformationen. Das Element APPL_MD_PATH der ServerVariables-Kollektion repräsentiert den metabase-spezifischen Pfad zur ISAPI-DLL. Das ist der Metabase-Pfad, von dem aus die ISAPI-DLL aufgerufen wird, nicht sein physischer Speicherort auf dem Server. Auf meinem Windows-95-Rechner (auf dem Personal Web Server ausgeführt wird) ist der Wert dieses Elements wie folgt:
      /LM/W3SVC/1/ROOT
  APPL_PHYSICAL_PATH Der physische Pfad des Elements APPL_MD_PATH. Dieser Wert wird bei der Konvertierung von APPL_MD_PATH durch die IIS abgerufen. Auf meinem System übersetzt sich das in C:\Inetpub\wwwroot\. AUTH_PASSWORD Ist die IIS-Sicherheit auf Standardauthentifizierung gesetzt, so repräsentiert AUTH_PASSWORD das beim Anmelden des Clients beim Webserver in das Feld Authentifizierung eingegebene Kennwort. Wird kein Kennwort angegeben, ist sein Wert ein Null-String. AUTH_TYPE Das auf dem Webserver eingestellte Authentifizierungsverfahren. Dieses Authentifizierungsverfahren wird zur Validierung aller Anwender verwendet, die Skripts auf einem von Windows-NT-Sicherheit geschützten Server anfordern. AUTH_USER Der unverarbeitete beim Authentifizieren des Clients beim Webserver eingegebene Benutzername. CERT_COOKIE Eine eindeutige ID für das digitale Zertifikat des Clients. Der Wert dieses Elements kann als Signatur für das gesamte Zertifikat verwendet werden. Dieses Element hat nur einen Wert für Clients, die das HTTPS-Protokoll unterstützen. Beachten Sie, dass die ClientCertificate-Kollektion alle client-bezogenen Informationen über das digitale Zertifikat enthält. Die ClientCertificate-Kollektion ist einfacher anzuwenden als die HTTP-Header-Informationen. Beachten Sie auch, dass diese CERT_-Elemente in der ServerVariables-Kollektion immer noch vorhanden, aber leer sind (d. h. sie besitzen keinen Wert), wenn der Client kein digitales Zertifikat sendet. CERT_FLAGS CERT_FLAGS repräsentiert einen Zwei-Bit-Wert. Bit #0 wird auf 1 gesetzt, wenn das Client-Zertifikat vorhanden ist. Bit #1 wird auf 1 gesetzt, wenn die Zertifizierungsstelle des Client ungültig ist (d. h., in der Liste der überprüften Zertifikataussteller auf dem Webserver wird dieser Aussteller nicht gefunden). Beachten Sie, dass diese Werte den Konstanten ceCertPresent und ceUnrecognizedIssuer des Flags-Elements der ClientCertificate-Kollektion entsprechen. CERT_ISSUER Der Aussteller des Client-Zertifikats, falls vorhanden. Der Wert dieses Elements ist ein durch Kommas getrennter String, der die Unterfelder zu jedem möglichen Unterelement enthält. Diese sind im Abschnitt zum ClientCertificate-Element Issuer, weiter vorne in diesem Kapitel, beschrieben. CERT_KEYSIZE Die Größe des SSL-Verbindungsschlüssels (Secure Sockets Layer) in Bit (zum Beispiel 64 oder 128). CERT_SECRETKEYSIZE Die Anzahl an Bits im geheimen privaten Schlüssel des Serverzertifikats (zum Beispiel 1024). CERT_SERIALNUMBER Der Wert der Seriennummer des Client-Zertifikats. CERT_SERVER_ISSUER Der Aussteller des Server-Zertifikats. CERT_SERVER_SUBJECT Das Antragstellerfeld (subject)des Server-Zertifikats. Wie auch das Subject-Feld des Client-Zertifikats ist dieser Wert ein durch Komma getrennter String, der die im Abschnitt zum ClientCertificate-Element Subject beschriebenen Unterfelder enthält. CERT_SUBJECT Das Antragstellerfeld (subject) des Client-Zertifikats. Der Wert dieses Elements ist ein durch Kommas getrennter String, der die im Abschnitt zum ClientCertificate-Element Subject beschriebenen Unterfelder enthält. CONTENT_LENGTH Der Gesamtumfang des vom Client gesendeten HTTP-Anforderungs-Bodys. Anhand dieses Werts können Sie den Umfang des unverarbeiteten HTTP-Inhalts im Body der vom Client gesendeten HTTP-Anforderung bestimmen. Dieser Wert beschreibt nicht etwa den Umfang irgendwelcher über den Anforderungs-Header präsentierten Daten (d. h. die mit der Methode GET gesendeten Informationen), sondern nur die Informationen im Anforderungs-Body. CONTENT_TYPE Der MIME-Typ des vom Client gesendeten Inhalts. Wird dieser Wert mit HTTP-Abfragen die angehängte Informationen enthalten (z. B. HTTP-Aktionen aus GET, POST oder PUT) verwendet, so lässt sich damit der Datentyp des Inhalts der Client-HTTP-Anforderung bestimmen. Meist wird für dieses Element der Wert application/x-www-form-urlencoded verwendet. Wenn Sie ein Dateielement in das HTML-Formular einfügen, setzen Sie den Parameter ENCTYPE (und somit den Header CONTENT_TYPE in der Anforderung) auf multipart/form-data. GATEWAY_INTERFACE Die vom Webserver verwendete CGI-Version ( Common Gateway Interface). Dieser String-Wert hat das Format CGI/revision #. Angenommen, Sie sind mit einem IIS-4.0-Webserver verbunden, so ist der Wert dieses Elements CGI/1.1. HTTP_ [HeaderName] Der im HTTP-Header headername gesendete Wert. Um den Wert eines nicht in dieser Liste angeführten HTTP-Headers abzurufen, (einschließlich selbst definierter Header), müssen Sie dem Header-Namen das Präfix HTTP_ voranstellen. Beachten Sie, dass IIS in einem vom Client gesendeten Header namens HTTP_CUSTOM_SELECTION nach einem HTTP-Header sucht, der in der HTTP-Anforderung mit "Custom-Header" bezeichnet worden ist. Anders ausgedrückt: wenn Sie in der ServerVariables-Kollektion nach einem HTTP-Header mit Bindestrichen im Namen suchen, verwenden Sie Unterstriche anstelle der Bindestriche. Beim Versuch, einen nicht vorhandenen Header abzurufen, wird keine Fehlermeldung erzeugt, sondern einfach ein leerer String zurückgegeben. Hier einige Beispiele: HTTP_ACCEPT HTTP_AUTHORIZATION (entspricht dem Element AUTH_TYPE) HTTP_ACCEPT-LANGUAGE HTTP_CONNECTION HTTP_HOST HTTP_REFERER HTTP_USER-AGENT Um von diesen Elementen den Wert zu empfangen, wird ein Code wie der folgende benötigt:
      strUserAgent = _
               Request.ServerVariables("HTTP_USER_AGENT")
HTTPS Der Wert dieses Elements ist der String "ON", wenn die HTTP-Anforderung des Clients mit SSL gesendet worden ist. Andernfalls ist es der String "OFF". HTTPS_KEYSIZE Entspricht dem weiter vorne beschriebenen CERT_KEYSIZE. HTTPS_SECRETKEYSIZE Entspricht dem weiter vorne beschriebenen CERT_SECRETKEYSIZE. HTTPS_SERVER_ISSUER Entspricht dem weiter vorne beschriebenen CERT_SERVER_ISSUER. HTTPS_SERVER_SUBJECT Entspricht dem weiter vorne beschriebenen CERT_SERVER_SUBJECT. INSTANCE_ID Die als String angegebene ID der aktuellen IIS-Instanz. INSTANCE_ID repräsentiert die Nummer der Webserver-Instanz, zu der die Anforderung gehört. Dieses Element macht nur dann Sinn, wenn auf Ihrem Server mehrere Instanzen des Webservers ausgeführt werden. Ansonsten ist der Wert immer 1 und repräsentiert die erste (und einzige) Instanz des Webservers auf dem Rechner. INSTANCE_META_PATH Der Pfad in der Metabase für die IIS-Instanz, an den die HTTP-Anforderung des Clients gesendet wird. Wie bereits weiter vorne im Abschnitt zum ServerVariables-Element APPL_MD_PATH erörtert, speichert die Metabase spezifische Informationen zur Installation und Konfiguration des Webservers. Auf meinem Rechner, auf dem Personal Web Server läuft, ist der Wert dieses Elements z. B. /LM/W3SVC/1. LOCAL_ADDR Die TCP/IP-Adresse des Webservers, der die HTTP-Anforderung des Clients annimmt. Dieses Element der ServerVariables-Kollektion ist insbesondere dann wichtig, wenn sich Ihr Webserver auf einer Serverfarm aus mehreren Rechnern mit eindeutiger IP-Adresse befindet, die alle ihre Anforderungen an denselben Domänennamen beantworten. Wird auf den Server als localhost zugegriffen, so ist sein Wert 127.0.0.1. LOGON_USER Das Windows-NT-Benutzerkonto, unter dem sich der Anwender beim System angemeldet hat, wenn grundlegende Sicherheit oder Windows-NT-Anfrage/Antwort-Sicherheit eingestellt ist. Bei anonymer Sicherheit wird ein leerer String zurückgegeben. PATH_INFO Der virtuelle Pfad der Webseite, auf der der Client die HTTP-Anforderung auslöst. Virtuelle Verzeichnisse werden zunächst dem physischen Verzeichnis zugeordnet, und erst dann an den CGI-Filter gesendet. PATH_TRANSLATED Die Zuordnung virtueller in physische Pfadinformationen des ServerVariables-Elements PATH_INFO. QUERY_STRING Die vom Client hinter dem Fragezeichen (?) gesendeten Werte am Ende der HTTP-Anforderungs-URL. Dieses Element umfasst auch die an den Webserver mittels der HTTP-Methode GET gesendeten Informationen. Alle Informationen in diesem Element sind auch über die QueryString-Kollektion verfügbar (die einfacher anzuwenden ist, da sie keine Analyse der Daten erfordert). REMOTE_ADDR Die TCP/IP-Adresse des Client. REMOTE_HOST Die IP-Adresse, von der der Webserver die HTTP-Anforderung des Clients empfängt. Enthält die HTTP-Anforderung diese Information nicht, so wird der Wert des Elements REMOTE_ADDR gesetzt, und zwar auf einen leeren Wert. REQUEST_METHOD Die Methode, mittels derer der Client die HTTP-Anforderung (GET, POST, HEAD, etc.) gesendet hat. SCRIPT_NAME Der gesamte virtuelle Pfad zum aktuellen Skript. Er enthält nicht die Basisportion der URL, die durch das URL-Element der ServerVariables-Kollektion repräsentiert wird. Dieses Element wird (meist intern) für URLs verwendet, die auf sich selbst verweisen. Dieser Wert ist derselbe wie das Ergebnis aus dem Element PATH_INFO. SERVER_NAME Die TCP/IP-Adresse, DNS oder der Hostname, wie sie in einer URL erscheinen würde, die auf sich selbst verweist. SERVER_PORT Der Server-Port, an den die HTTP-Anforderung des Clients gesendet wird. Typischerweise ist dies bei den meisten Webservern 80 oder 8080. SERVER_PORT_SECURE Wird die HTTP-Anforderung vom Webserver auf einem sicheren Port verwaltet, so wird der Wert 1 zurückgegeben, andernfalls 0. SERVER_PROTOCOL Der Name und die Version des Protokolls, nach dem der Webserver die Client-Anforderung verarbeitet. Wenn der Client etwa mit Microsoft Internet Explorer 4.01 arbeitet und der Webserver mit IIS 4.0, so wird der String "HTTP/1.1" zurückgegeben. SERVER_SOFTWARE Der Name und die Version der Webserversoftware, die die HTTP-Anforderung des Clients verarbeitet. Mit Microsoft IIS 4.0 wiederum wäre ein möglicher Wert für dieses Element der ServerVariables-Kollektion "Microsoft-IIS/4.0". URL Die Basis-URL, die vom Client in der HTTP-Anforderung angefordert wird.
Beispiel
    <%

    ' The following code determines the value of the
    ' LOGON_USER item of the ServerVariables collection. This
    ' code can be used to determine the identity of the
    ' client.
    Dim strUserName

    strUserName = Request.ServerVariables("LOGON_USER")

    %>
Hinweise
Wie die Liste weiter vorne in diesem Abschnitt veranschaulicht, enthält die ServerVariables-Kollektion viele sehr nützliche Informationen, die die HTTP-Anfrage des Clients betreffen. Die vielleicht wichtigsten Elemente erlauben Ihnen, die Identität und die Adresse des Anwenders zu bestimmen. Diese Elemente erlauben Ihnen, Ihre Sicherheitsbemühungen entsprechend anzupassen. Auch können über die ServerVariables-Kollektion viele andere Kollektionen des Objekts Request bezogen werden (in der Regel jedoch mit etwas mehr Mühe ...).

BinaryRead |
MySafeArray=Request.BinaryRead(ByteCount)
Die Methode BinaryRead liest die Anzahl der übertragenen Bytes direkt aus dem HTTP-Anforderungs-Body, der vom Client als Teil einer HTTP-Anforderung mit der Methode Post gesendet worden ist. Die mit der Methode BinaryRead aus einer HTTP-Anforderung gelesenen Daten werden in ein SafeArray übergeben. Ein SafeArray ist ein spezieller Varianten-Array, der zusätzlich zu seinen Elementen die Anzahl der Dimensionen sowie die oberen Grenzen des Arrays enthält. In Wirklichkeit ist SafeArray gar kein Array. Es ist vielmehr eine spezielle Art von Struktur, die intern zur Verwaltung der Informationen im Array-Teil verwendet wird. Die Dimensionen und oberen Grenzen sind von C/C++ aus nur als Elemente der Struktur verfügbar. Sie können diese Werte nicht durch ein Skript manipulieren, ja nicht einmal abrufen.
Parameter
MySafeArray Der Name eines SafeArrays, das zum Speichern der aus einem BinaryRead-Lesevorgang bezogenen Informationen verwendet wird. ByteCount Die von der Methode BinaryRead gelesene Datenmenge in Byte. Typischerweise entspricht der Wert dieser Variablen der mit der Eigenschaft TotalBytes des Objekts Request abgerufenen Datenmenge (siehe weiter vorne).
Beispiel
    <%

    ' The following code determines the total number of bytes
    ' sent in the client's HTTP request. It then reads the
    ' bytes, checks for errors, and if there are none,
    ' reports to the client that the read was successful.
    Dim lngTotalByteCount
    Dim vntRequestData

    On Error Resume Next

    lngTotalByteCount = Request.TotalBytes

    vntRequestData = Request.BinaryRead(lngTotalByteCount)
    If Err = 0 Then
       ' For details about the Response object, see Chapter 8.
       ' For now, suffice it to say the following code sends
       ' information to the client.
       Response.Clear
       Response.Write lngTotalByteCount & _
                      " bytes successfully read.<BR>"
       Response.End
    End If

    %>
Hinweise
Wenn der Client-Teil Ihrer Webanwendung genau kontrollieren könnte, was im HTTP-Anforderungs-Body gesendet wird, so wäre diese Methode unbezahlbar, da sie Ihren Client in die Lage versetzen würde, Informationen auf einer Byte-Ebene hochzuladen (oder Dateien hochzuladen). Allerdings gestaltet sich eine Kontrolle auf Byte-Ebene über die in einer Post-Anforderung gesendeten Daten schwierig. Dennoch gibt es verschiedene Dateiübertragungs-Steuerelemente von Drittherstellern, die eine Integration von Dateiübertragungsfunktionalität in Ihre Anwendung gestattet, und zwar auf einfachere und effizientere Weise. Anzumerken ist noch folgendes: wenn Sie zuvor Informationen aus der Form-Kollektion des Objekts Request abgerufen haben, verursachen nachfolgende Aufrufe an die Methode BinaryRead einen Fehler. Wenn Sie umgekehrt die BinaryRead-Methode des Objekts Request zuerst aufrufen und danach Informationen aus der Form-Kollektion abrufen, wird Ihr Skript ebenfalls einen Fehler erzeugen.