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, Hat der Anwender die Eingabe der URL für [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 [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 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 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 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 <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 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
|
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 | |
|
|
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:
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:
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:
|
|
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 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:
Ö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:
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 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:
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 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:
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 <% ' 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 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:
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:
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:
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.
|
|
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 | |
|
|
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. |
|