Das Response-Objekt sendet Informationen zum Browser
Das Benutzen des Request-Objekts zum Zugriff auf Client-Informationen
Die Benutzung der Objekte Session und Application, um einen Zustand aufrechtzuerhalten
4
Web-Applikationsentwicklung mit ASP-Objekten
Damit Sie die Möglichkeiten, die Ihnen ASP bietet, optimal nutzen können, ist es notwendig, daß Sie ein wenig über Objekt-orientierte Programmierung (OOP) Bescheid wissen. Es gibt jede Menge hervorragender Bücher, die dieses Feld abdekken; dieses Kapitel soll keine generelle Einführung in dieses Thema geben, sondern nur einige wichtige Grundlagen erörtern.
Die Grundlage bzw. das Fundament der Objekt-orientierten Programmierung ist das Objekt. Es genügt im Rahmen dieses Kapitels, wenn Sie Hintergrundwissen über die Namenskonventionen von Objekten erhalten.
Ein Objekt ist eine abstrakte Abbildung eines konkreten Gegenstandes. Objekte können miteinander verbunden werden bzw. wiederum andere Objekte enthalten. Man kann sich ein Objekt als eine Art Computer vorstellen; der Computer kann wiederum andere Objekte enthalten, wie beispielsweise Laufwerke, die als Objekte Dateien beherbergen.
Jedes Objekt besitzt Eigenschaften, die durch Attribute definiert werden. Die Eigenschaften eines Objektes teilen Ihnen als Anwender spezifische Daten über das Objekt oder dessen Inhalt mit. Eigenschaften können von Objekt zu Objekt verschieden sein und legen pro Objekt dessen Status und Qualitäten fest. Um bei unserem Beispiel zu bleiben: Ein Computer kann ein PC, Macintosh oder Mainframe sein. Diese Rechner können wiederum angeschaltet oder ausgeschaltet sein.
Jedes Objekt wird durch Methoden definiert, die festlegen, auf welche Art und Weise Objekte mit anderen kommunizieren. Im weitesten Sinne gleichen Methoden Funktionen - im OOP-Umfeld nennt man sie jedoch Methoden.
Zum Abschluß gibt es den Begriff der Collections oder auch Sammlung genannt. Darunter sind Gruppen von Objekten des gleichen Typs zu verstehen. Ein Objekt und eine Collection sind beides Container - jedoch unterschiedlichen Typs. Ein Objekt hat das Bestreben, mehrere Collections zu enthalten. Dazu ein kleines Beispiel: ASP benutzt nur fünf einfache Objekte, um seine Aufgaben zu erfüllen. Jedes Objekt hat seine eigenen Eigenschaften, Methoden und Collections. Jede Collection wiederum hat eigene Eigenschaften.
In ASP gibt es beispielsweise das Objekt Request, das wiederum eine Vielzahl von Eigenschaften und Collections beinhaltet, die definieren, wie sich ein Client-Browser bei Anfragen verhält. Eine dieser Collections wird Form genannt. Diese Collection enthält nur Informationen und deren zugehörige Eigenschaften, die vom Anwender eingegeben wurden. Der feine Unterschied zwischen Objekten und Collections ist folgender: Objekte sind in der Lage, verschiedene Level von Informationen zu beherbergen - Collections nicht. Collections bestehen aus einfach strukturierten Informationen.
Folgende Objekte stehen unter ASP zur Verfügung:
Verstehen Sie die Funktionsweise dieser fünf Objekte, verstehen Sie ASP - zumindest was die Grundlagen betrifft. Diese Kapitel ist nicht dafür gedacht, in die Tiefen der ASP-Objekte hinabzusteigen, vielmehr erhalten Sie einen Einblick in die Anwendungsweise dieser Objekte.
Bevor Sie daran gehen, ASP-Objekte in Ihre Programmierung einzubinden, ist es notwendig, einiges über die Funktionsweise des World Wide Web zu erfahren und über die Prinzipien des Informationsaustausches in diesem Medium. Damit der Browser Informationen vom WWW-Server und umgekehrt erhält, bedarf es gewisser Methoden und Regeln, die einen einwandfreien Informationsfluß gewährleisten. Verantwortlich dafür zeichnet sich das HTTP-Protokoll.
HTTP basiert auf Client/Server- bzw. Frage/Antwort-Regeln. Es gibt drei wichtige Dinge, die Sie über HTTP wissen sollten:
Ein Client-Browser, der sich den Inhalt einer bestimmten Web-Site anschauen möchte, muß diese Informationen logischerweise vom Server anfordern. Der Client-Browser sendet einen Request, der den URL (Uniform Ressource Locator) der angeforderten Seite sowie zusätzliche Informationen enthält. Diese zusätzlichen Informationen (Zeit, Browser-Version usw.) sind im sogenannten HTTP-Header enthalten.
Nachdem der Server einen Request für eine bestimmte Seite erhalten hat, geschehen verschiedene Dinge:
1. Der Server stellt fest, ob die entsprechende Seite existiert.
2. Der Server verarbeitet den HTTP-Header.
3. Der Server stellt den Typ und die Extension der jeweiligen Seite fest und ob diese vom MIME unterstützt wird.
4. Der Server überprüft die Seite auf ausführbare ASP-Scripts - falls notwendig. Im Normalfall wird die Seite zurückgeschickt, noch bevor sie verarbeitet wurde. Sie können jedoch ASP und das Objekt Response dazu benutzen, dies zu verhindern.
5. Der Server erstellt einen HTTP-Header und sendet den Inhalt. Der HTTP-Header muß den Client-Browser über zwei Dinge informieren:
|
Dieser kleine Ausflug in die Welt der HTTP-Requests deckt bei weitem nicht alle Möglichkeiten ab. Dies resultiert aus der Tatsache, daß sich dieses Buch hauptsächlich mit ASP beschäftigt. Microsoft entwickelte ASP derart, daß Sie nur bedingt mit HTTP konfrontiert werden und auch ohne größeres Hintergrundwissen in Sachen HTTP Applikationen erstellen können. |
Nichtsdestotrotz gibt es eine Vielzahl von Applikationen, die Ihnen Wissen im Bereich MIME und HTTP abverlangen. Sie finden sämtliche MIME-Typen, die vom IIS unterstützt werden, in der IIS-Dokumentation. Weiterführende Informationen über MIME-Typen sind ebenfalls in der RFC 1521 zu finden. Zusätzliche HTTP-Response-Codes der HTTP-1.0-Spezifikation sind in der RFC 1945 festgelegt. Des weiteren sind Informationen über HTTP und MIME unter der Internet-Adresse http://ds.internic.net sowie http://ds.internic.net/rfc/rfc2068.txt verfügbar.
Tabelle 4.1: Die HTTP-Status-Codes
Code |
Beschreibung |
200 |
Der Request war erfolgreich und es wurden sämtliche Daten versandt. Sie werden diesen Code innerhalb Ihres Browsers niemals sehen, jede Seite, die erfolgreich geladen wurde, beinhaltet jedoch diesen Code. |
301 |
Der angeforderte Inhalt befindet sich an einer neuen Stelle. Ist der neue Standort der Information bekannt, so wird Ihr Browser sich automatisch dorthin verbinden. Beachten Sie jedoch, daß einige ältere Browser diese Funktion nicht unterstützen. |
302 |
Der angeforderte Inhalt befindet sich vorübergehend an einer neuen Stelle. Der Code wird bearbeitet wie unter 301. |
404 |
Der angeforderte Inhalt konnte auf dem entsprechenden Server nicht lokalisiert werden. Die Nachricht wird auf dem Browser des Anwenders ausgegeben. |
500 |
Der Server gibt einen internen Fehler aus, so daß der Request nicht bearbeitet werden kann. |
Tabelle 4.2: Die gebräuchlichsten MIME-Typen und Subtypen
Typ/Subtyp |
Beschreibung |
text/html |
HTML-Datei spezifiziert, daß der Client-Browser HTML-Code anzeigen soll. |
text/plain |
Dieser Typ indiziert Plain-ASCII-Text und teilt dem Browser weiterhin mit, daß er nur diesen Text anzeigen soll. |
image/gif |
Dieser Typ beschreibt eine GIF-Grafik-Datei und teilt dem Browser mit, daß er diese Grafik anzeigen soll oder eine entsprechende Applikation zu starten ist, die es ermöglicht, die Grafik anzuzeigen. |
image/jpeg |
Dieser Typ beschreibt eine JPEG-codierte Grafik-Datei. Diese wird auf die gleiche Art vom Client-Browser behandelt wie eine GIF-Grafik-Datei. |
Headers werden vom Client verwendet, um Informationen zu versenden. Der Server informiert den Client durch Header darüber, daß Informationen zum Transfer anstehen.
Dieser Austausch von Headern und Kommandos benötigt einiges an Programmierarbeit - selbst bei kleineren Applikationen. Zum Glück ist ASP in der Lage, Ihnen die schwierigsten Teile im Zusammenhang mit dem HTTP-Protokoll abzunehmen, so daß Sie nur die Grundlagen verstehen müssen.
Das Response-Objekt sendet Informationen zum Browser
Da Sie jetzt über die Grundlagen Bescheid wissen, ist es an der Zeit, diese mit ASP in Einklang zu bringen. Im weiteren Verlauf dieses Kapitels lernen Sie, wie Sie Informationen und Steuerungen erstellen und auf den Weg zum Client-Browser schicken. Später werden Sie den genau entgegengesetzten Informationsfluß kennenlernen - vom Client-Browser zum Server.
Kontrolle der HTTP-Ausgaben
Es gibt verschiedene Wege, um die HTTP-Ausgabe zu kontrollieren bzw. zu steuern. Die folgenden ASP-Eigenschaften und Methoden können separat oder gemeinsam genutzt werden, um die benötigten Resultate zu erhalten:
Einer der Hauptgründe zur Manipulation von HTTP ist der, daß sogenannte on-the-fly-Grafiken generiert werden können (grafische Seitenzähler oder Request-Authentifizierung).
Der Client-Browser benötigt wenigstens ContentType und Status, um Informationen zu verarbeiten. Im Normalfall generiert der IIS automatisch sämtliche Header für Sie. Anwender, die hierauf keinen Wert legen, können unter Zuhilfenahme von ContentType und Status diesen Automatismus umgehen. Die Syntax lautet wie folgt:
Response.ContentType = type/subtype
Der ContentType muß einem MIME-Type/Subtype-Schema und der MIME-Spezifikation entsprechen. Sie sollten diesen Code benutzen, um dem System einen unbekannten MIME-Typ bekannt zu machen bzw. einen MIME-Typ zu ändern. Die Syntax lautet wie folgt:
Response.Status = status
Status sollte den Status-Code sowie eine Beschreibung enthalten. Dieser Header wird immer zusammen mit der Eigenschaft ContentType verwandt, um on-the-fly-Grafiken zu erstellen. Weiterhin können Sie die Eigenschaft benutzen, um eine notwendige Authentifizierung durchzuführen (Status 401).
|
Alle Response-Eigenschaften müssen gesetzt sein, bevor irgendwelche HTML- oder Bildschirmausgaben an den Browser gesendet werden; anderenfalls wird eine Fehlermeldung generiert. Diese Statements sollten am Anfang Ihres ASP-Scripts erscheinen. |
Eine Methode, die sich auf die Status-Eigenschaft bezieht, ist Redirect. Diese Methode teilt dem Browser mit, wo eine neue Seite zu finden ist und gestattet eine automatische Umleitung.
Die Redirect-Methode stellt zwei Dinge sicher, damit der Client-Browser den Standort der neuen Web-Seite findet. Zum einen sendet die Methode einen HTTP-Status-Header mit dem Code 302 Object Moved wie folgt:
HTTP/1.0 302 Object Moved
Location URL
Im Anschluß daran generiert die Methode automatisch eine neue URL in Ihrer HTML-Seite. Alle anderen Ausgaben werden ignoriert. Clients ohne automatische Redirection werden ebenfalls unterstützt. Die Syntax lautet wie folgt:
Response.Redirect(URL)
Die Methode AddHeader erlaubt es Ihnen, Header selbst zu definieren. Sie sollten die Benutzung des Unterstriches (_) in Ihrem Header vermeiden; benutzen Sie statt dessen einen Bindestrich (-). Die korrekte Syntax lautet wie folgt:
Response.AddHeader headername, headervalue
Diese Methode können Sie jedoch nicht dazu benutzen, einen existierenden Header zu entfernen, da ansonsten ein Fehler generiert werden würde. AddHeader ist nur für fortgeschrittene Anwender zu empfehlen. In den meisten Fällen wird Ihr Browser gar nicht wissen, was er mit dem Header anfangen soll, dementsprechend werden Sie diese Methode vielleicht niemals verwenden.
Die BinaryWrite-Methode wird dazu benutzt, Daten ohne Übersetzung direkt in den HTTP-Datenstrom zu schreiben. Diese Methode ist besonders geeignet, kleine Grafiken, Multimedia- oder andersartige Dateien zu verschicken. Die Syntax lautet wie folgt:
Response.BinaryWrite data
Um zu sehen, wie diese Methoden funktionieren, werden wir eine kleine Applikation erstellen - einen grafischen Seitenzähler. Plazieren Sie den folgenden Tag in Ihren HTML-Code, wo immer Sie möchten:
<IMG SRC="count.asp">
Die Datei count.asp ist keine Grafik, vielmehr erstellt sie eine Grafik. Das Listing 4.1 zeigt alle notwendigen Schritte, um ein Bild zum Client-Browser zu schicken.
Listing 4.1: Count.asp sendet ein erstelltes Bild an den Browser
<% Response.Status("200")
Response.ContentType("image/gif")
ô numpic is magically generated here.
BinaryWrite numpic
%>
Kontrolle über die Verarbeitung von ASP-Scripts
Ein Sachverhalt, über den Sie unbedingt Bescheid wissen sollten, ist der Aspekt, wie der Server Ihre Scripts verarbeitet und zum Client-Browser schickt. Im Normalfall wird ein Script gesendet, während der Browser eine Seite lädt. Sie haben jedoch die Möglichkeit, Inhalte zwischenzuspeichern. Diese zwischengespeicherten Inhalte werden erst dann zum Client-Browser geschickt, wenn das Script komplett verarbeitet wurde oder die Methoden Flush oder And aufgerufen wurden (werden zu einem späteren Zeitpunkt erläutert). Benutzen Sie die Zwischenspeicherung, um Informationen zu testen oder auf Fehler zu prüfen, bevor diese zum Anwender gesendet werden. Ist die Buffering-Methode aktiviert, empfängt der Server vom Client sogenannte keep-alive-Requests. Diese veranlassen den Server, die Verbindung nach einem Request offen zu halten bzw. diese erst zu beenden, wenn die Anfrage vollzogen wurde. Dies spart sehr viel Zeit, da der Server die Verbindung zum Client-Browser nicht erneut aufbauen muß. Negativ schlägt zu Buche, daß für derartige Verbindungen hohe Bandbreiten benötigt werden, die in der Praxis nur selten zur Verfügung stehen.
Buffering wird von der Buffer-Eigenschaft gesteuert. Diese kann entweder True (1) oder False (0) sein. Zum Setzen der Eigenschaft gehen Sie bitte nach folgender Syntax vor:
Response.Buffer = [TRUE|FALSE]
Per Voreinstellung ist das Buffering ausgeschaltet. Diesen Wert können Sie über den Registry-Eintrag ändern. Benutzen Sie dazu BufferingOn. Die Buffer-Eigenschaft muß zu Beginn jedes Scripts definiert werden, noch bevor der Header beginnt.
Die Flush-Methode arbeitet mit der Page-Buffering-Eigenschaft zusammen. Um den Inhalt aus dem Buffer zu lesen, noch bevor das Ende des Scripts erreicht ist, muß folgende Syntax verwendet werden:
Response.Flush
Ist die Eigenschaft Response.Buffer auf TRUE gesetzt, so führt der Aufruf von Flush zu einer Fehlermeldung.
Die End-Methode stoppt die Ausführung eines ASP-Scripts, so daß alle Kommandos nach End ignoriert werden.
Die Clear-Methode löscht den Inhalt einer zwischengespeicherten Seite, aber nicht deren Header. Benutzen Sie die Clear-Methode dazu, den Anwender daran zu hindern, die Ausgabe einer Seite bis zum Anfang von Clear einzusehen.
Um zu sehen, wie alle Eigenschaften miteinander agieren, sehen Sie im Anschluß ein Beispiel, in dem der Anwender dazu aufgefordert wird, sein Geburtsdatum einzugeben:
Birthday (mandatory): <input name="birthday">
Sollten Sie die Post-Methode benutzen, um die Daten an den Server zu schicken, so können Sie mit Hilfe des folgenden Scripts prüfen, ob das Geburtstagsdatum auch tatsächlich eingegeben wurde.
<%Response.Buffer%>
<HTML><HEAD>
<TITLE>Your Birthday </TITLE></HEAD>
if Request.Form("birthday") = "" then
Response.Clear
Response.Redirect("fill-out-form.htm")
Response.End
Else%>
<BODY>
Your birthday is <%=Request.Form("birthday")%>
<%end if%>
</BODY>
</HTML>
Die Eigenschaften Expires und ExpiresAbsolute
Um Zeit beim Web-Surfen zu sparen, speichern viele Client-Browser die Inhalte der zuletzt besuchten Sites auf der lokalen Festplatte. Sobald der Anwender auf eine Web-Site zugreift, schaut der Browser im Cache-Speicher nach und lädt die Daten vom lokalen Massenspeicher. Ist kein adäquater Inhalt zu finden, so kontaktiert der Web-Browser den entsprechenden Server. Ändern Sie als Internet-Informationsanbieter oft den Inhalt Ihrer Seiten, so ist es möglich, daß der User nicht immer sämtliche neuen Daten erhält. Die Eigenschaften Expires und ExpiresAbsolute teilen dem Client-Browser mit, wie lange die jeweilige Seite auf der lokalen Festplatte bzw. dem Arbeitsspeicher vorhanden sein soll. Ist keine Eigenschaft spezifiziert, so bleibt die Seite nicht im Cache des Client-Browsers. Die Syntax für Expires lautet wie folgt:
Response.Expires = number
number ist die Zeit in Minuten, bevor eine Seite gewissermaßen verfällt. Wird der Wert auf Null gesetzt, so findet keine Speicherung statt.
ExpiresAbsolute spezifiziert die Zeit und das Datum, bis zu welchem die Web-Seite zwischengespeichert wird. Wurde keine Zeit definiert, so wird die Seite nur bis Mitternacht des jeweiligen Tages gehalten. Datum und Zeit müssen im GMT-Format angegeben werden (RFC 1123). Folgende Syntax ist notwendig:
Response.ExpiresAbsolute = [date time]
Sollten Sie VBScript verwenden, so müssen Datum und Uhrzeit in Doppelkreuzen (#) eingebunden werden. Eine Seite, die beispielsweise an meinem Geburtstag im Jahre 1998 auslaufen würde, lautet wie folgt:
Response.RespiresAbsolute = #July 10, 1998 16:00:00#
Der IIS kann so konfiguriert werden, daß er in der Lage ist, Requests aufzuzeichnen. Jeder Zugriff auf eine Seite wird als separater Eintrag in einer Datenbank festgehalten. Die IIS-Dokumentation enthält dazu weiterführende Informationen. Die AppendToLog-Methode hängt dem Server-Log einen bestimmten String an, sobald eine Datei ausgeführt wird. Um dem Server-Log einen String anzuhängen, benutzen Sie bitte folgende Syntax:
Response.AppendToLog String
Die Write and ImplicitWrite-Methode
Benutzen Sie die Response.Write-Methode, um Text direkt in den Datenstrom zu schreiben. Methoden und Variablen innerhalb der Write-Methode agieren verdeckt, so daß nur das Resultat auf dem Client-Browser erscheint. Das folgende ein Beispiel benutzt die Write-Methode, um den Wert der Variablen count auszulesen:
Response.Write(,,The Counter says" & count)
Weiterhin haben Sie die Möglichkeit, Shortcuts der Write-Methode wie folgt zu benutzen:
The Counter says <%=count%>
Das Gleichheitszeichen muß unmittelbar nach den <%-Zeichen folgen. In der Praxis eignet sich die volle Syntax der Write-Methode jedoch besser.
Erstellung eines Cookies mit der Cookie-Collection
Cookies sind wunderbare kleine Helfer, die dafür sorgen, daß der Client-Browser und Server Informationen zwischenspeichert oder Statusinformationen über unterschiedliche Seiten hinweg beibehält. Im einfachsten Fall enthält ein Cookie Informationen, die der Client lokal abspeichert und auf die der Server später zurückgreifen kann. Der Client schickt Cookies als Teil eines HTTP-Requests an den Server zurück. Cookies sind in der Lage, jedwede Art von Informationen zu speichern und decken einen großen Anwendungsbereich ab. Cookies werden Sie wesentlich detaillierter in einem späteren Kapitel kennenlernen.
Ein Cookie läßt sich auf vier Weisen beschreiben: Zuerst einmal müssen alle Cookies einen Namen und ein Wertepaar enthalten. Weiterhin können Cookies sogenannte Keys (zusätzliche Namen und Wertepaare) enthalten. Sobald ein Cookie über Keys verfügt, nennt man es »Dictionary«. Cookies besitzen Eigenschaften und Attribute. Jedes Cookie besitzt das Attribut HasKeys, das entweder TRUE oder FALSE sein kann, in Abhängigkeit davon, ob das Cookie ein Dictionary ist oder nicht. In der nächsten Version von ASP wird Microsoft mit Sicherheit mehr Attribute den Cookies zuweisen.
Cookies haben vier optionale Eigenschaften, die gesetzt werden können, sowie ein weitere Eigenschaft, die sehr wichtig ist und deshalb den Status Read-Only hat (Tabelle 4.3).
Tabelle 4.3: Die Cookie-Eigenschaften
Name der Eigenschaft |
Beschreibung |
Spezifiziert die Domäne, auf die ein Request durchgeführt werden muß, damit das Cookie zum Server zurückgeschickt werden kann. In anderen Worten ausgedrückt heißt dies, daß diese Eigenschaft definiert, auf welche Domain sich das Cookie bezieht. | |
Diese Eigenschaft setzt das Datum und die Uhrzeit, bis zu welcher das Cookie vorgehalten wird. Wurde kein Wert definiert, wird das Cookie gelöscht, sobald der Anwender den Browser verläßt. | |
Spezifiziert den Pfad, der dem Client übertragen werden muß, damit er das Cookie bei Bedarf an die richtige Lokalität übertragen kann. | |
Diese Eigenschaft ist entweder TRUE oder FALSE. Es muß ein sichere Verbindung bestehen, um das Cookie an den Server zu senden. |
Um eine Eigenschaft zu setzen, führen Sie bitte folgende Schritte durch:
Response.Cookies(cookiename).Property = PropertyValue
Um den Namen eines Cookies und dessen Wert zu setzen, führen Sie bitte folgendes durch:
Response.Cookies(cookiename) = cookievalue
Um die Key-Werte zu setzen, geben Sie bitte folgendes ein:
Response.Cookies(cookiename)(keyname) = keyvalue
Keys werden zu einem späteren Zeitpunkt in diesem Kapitel besprochen. Sollten Sie mit der Programmiersprache Perl vertraut sein, so werden Sie feststellen, daß Cookies sehr stark Arrays ähneln.
|
Sollte ein Cookie bereits existieren und Sie möchten diesem neue Keys oder Eigenschaften zuweisen, so müssen Sie die alten überschreiben. |
Da Cookies im Header gespeichert werden, müssen diese definiert werden, bevor der erste HTML-Tag im Script erscheint, es sei denn, daß Sie das Page-Buffering aktiviert haben. In diesem Fall, werden keine Header bis zum Script-Ende geschrieben oder bis die Flush-Methode aufgerufen wird.
Stellen Sie sich doch einmal vor, daß Sie eine gewaltige Suchmaschine betreiben. Sie möchten Informationen über die letzten Zugriffe von Besuchern auf die Suchmaschine abspeichern. Um dies durchzuführen, bedarf es des Einsatzes von Cookies, die eine große Zeitspanne »überleben«, bis sie verfallen. Das Listing 4.2 zeigt den Code für eine Cookie, das die Informationen bis zum nächsten Besuch einer Web-Seite vorhält.
Listing 4.2: Beispiel für ein einfaches Cookie
<%
Response.Cookies("searchstring") = "MSDN AND Interdev"
Response.Cookies("searchstring").Expires = "July 31, 2000"
Response.Cookies("searchstring").Domain = "www.microsoft.com"
Response.Cookies("searchstring").Path = "/search"
Response.Cookies("Type").Secure = FALSE
%>
Schreiben Sie dieses Cookie erneut, so werden die Informationen, die aktuell in diesem gespeichert sind, gelöscht.
Das Benutzen des Request-Objekts zum Zugriff auf Client-Informationen
Kommuniziert ein Browser mit einem Server auf Basis von HTTP, so sendet der Browser neben dem Namen der angeforderten Seiten eine Menge weiterer Informationen. Anbei eine Liste von Informationen, die ebenfalls mit über das Internet gesendet werden:
All diese Informationen werden verschlüsselt und im HTTP-Header festgehalten, und es ist nicht immer einfach, diese wieder zu entschlüsseln. ASP übernimmt die Aufgabe der Entschlüsselung, Dekodierung und die Organisation aller Informationen für Sie. Sie müssen sich lediglich darum kümmern, in welcher Form Sie diese Informationen nutzen möchten. Mit diesen Informationen sind Sie in der Lage, folgende Dinge durchzuführen:
ASP speichert die Informationen in Collections innerhalb des Request-Objekts. Durch Verwendung des Calls Request.collection sind Sie in der Lage, die Informationen zu extrahieren, welche Sie benötigen.
Die ServerVariables-Collection
Die erste Collection, mit der Sie sich vertraut machen, ist ServerVariables. Diese Collection speichert Informationen über den Client-Browser, Server und Anwender. Die verfügbaren Informationen und deren Benutzung finden Sie in Tabelle 4.4. Die Syntax lautet wie folgt:
Request.ServerVariables("variablename")
Sollten Sie mit CGI vertraut sein, so werden Sie bestimmt die Variablen aus Tabelle 4.4 erkennen. Es gibt noch weitere Variablen, die Microsoft implementierte, um eine erweiterte Funktionalität zu gewährleisten. Die Variablen in der folgenden Tabelle müssen in Anführungszeichen gesetzt werden, wenn sie sich auf die Collection beziehen sollen.
Tabelle 4.4: Die gebräuchlichsten ServerVariablen und deren Anwendungsgebiete
Variable |
Beschreibung |
Diese Variable kennzeichnet den Datentyp des Inhalts und wird benutzt, wenn der Client Informationen zum Server versendet. Als Beispiel sind an dieser Stelle sogenannte »Uploads« zu erwähnen (HTTP-POST- und PUT-Requests). | |
Diese Variable beschreibt den Pfad zum aktuellen Script. | |
Diese Variable führt ein Virtual-to-Physical-Mapping durch. Dies ist besonders dann hilfreich, wenn Sie Zugriff auf Ihr Script haben möchten, das auf einem Remote-Server liegt, auf den Sie keinen Zugriff haben. | |
Diese Variable beinhaltet eine URL-verschlüsselte Information, die mittels der GET- oder POST-Methode versendet wird. | |
Darunter versteht man die IP-Adresse des Hosts, der einen Request initiiert. | |
Diese Variable bezeichnet den Domänennamen des Hosts, der einen Request veranlaßt. | |
Darunter versteht man die Methode, die benutzt wird, um einen Request zu erstellen. | |
Diese Variable beinhaltet den virtuellen Pfad des Scripts, das ausgeführt werden soll. | |
Diese Variable beherbergt den Host-Namen oder die IP-Adresse des Servers. | |
Diese Variable beinhaltet den Namen und die Version der Software, die auf dem Server läuft. Das Format lautet name/version. |
|
ALL_HTTP (nicht aufgeführt in Tabelle 4.4) beinhaltet alle Header, die der Client bisher gesendet hat. |
Die Form- und QueryString-Collections
Diese wichtige Collection innerhalb des Request-Objektes ist für die Extrahierung von Informationen aus HTML-Formularen oder Querys (Anfragen), die vom Browser an den Server gesendet werden, verantwortlich. Es gibt zwei Wege, wie der Client Informationen an den Server verschicken kann - die GET- und die POST-Methode. Bevor Sie jetzt tiefer in die Materie der Collections eintauchen, ist es notwendig, mehr über die unterschiedlichen Methoden des Informationsaustauschs zwischen Browser und Server zu erfahren.
Bevor der Browser Informationen verschickt, kodiert er diese nach einem Schema, das URL-Encoding genannt wird. Nach diesem Schema werden name/value-Paare durch Gleichheitszeichen ersetzt und unterschiedliche Paare durch das »&«-Zeichen getrennt.
name1=value1&name2=value2&name3=value3
Leerzeichen werden entfernt und durch ein Plus-Zeichen (+) ersetzt. Andere, nicht alphanumerische Zeichen, werden durch hexadezimale Werte, die laut RFC 1738 definiert sind, ersetzt. Nachdem die Information verschlüsselt wurde, begibt sie sich auf die Reise zum Server.
Die GET-Methode sendet die kodierten Anwenderinformationen zu der Web-Seite, die diese anforderte. Die Seite und alle kodierten Informationen sind durch ein Fragezeichen (?) voneinander getrennt.
http://www.test.com/form.asp?name1=value1&name2=value2&name3=value3
Die GET-Methode erstellt einen langen String, der im Server-Log und in der Browser-Statuszeile aufgezeichnet bzw. angezeigt wird. Dies stellt in der Praxis ein nicht zu unterschätzendes Sicherheitsrisiko dar, da die Informationen für jedermann sichtbar sind. Benutzen Sie die Get-Methode deshalb niemals, um Paßwörter oder andere sensible Daten aus einem HTML-Formular auszulesen. Des weiteren hat die Get-Methode eine Größenbeschränkung - der Request-String darf maximal 1024 Zeichen enthalten. Wenn möglich, meiden Sie diese Methode. Sie werden jedoch im weiteren Verlauf dieses Buches sehen, daß ASP diese Methode gern benutzt, um Daten von Web-Seite zu Web-Seite zu transportieren, ohne das <FORM>-Tag zu benutzen.
|
Dieses Buch beschäftigt sich nur kurz mit Formularen, so daß Sie sich ein gutes HTML-Buch besorgen sollten, um sich in diese Problematik einzuarbeiten. Nichtsdestotrotz verändert sich der HTML-Standard in sehr kurzen Zeitabständen, so daß Sie des öfteren mal unter http://www.w3.org nachschauen sollten, um neueste Informationen zu bekommen. |
Die Post-Methode transferiert Informationen mit Hilfe des HTTP-Headers. Sämtliche relevanten Informationen werden kodiert und als QUERY-STRING in den Header plaziert. Mittels der Post-Methode können Sie jedoch nur Daten versenden, die ausführbar und in der Lage sind, den Query-String zu lesen - andernfalls erhalten Sie eine Fehlermeldung. Listing 4.3 beinhaltet den Code eines einfachen Formulars, das wir als Beispiel das ganze Kapitel hindurch verwenden wollen. Die Ausgabe des kompletten Formulars sehen Sie in Abbildung 4.1.
Listing 4.3: Ein einfaches HTML-Eingabeformular
1: <HTML>
2: <HEAD>
3: <TITLE>Sample Form</TITLE>
4: </HEAD>
5: <BODY>
6: <P Align=center> This is a Sample Form </P>
7: <FORM action="test.asp" method=POST>
8: <TABLE><TR>
9: <TD>Name:</TD>
10: <TD><INPUT name="name"></TD></TR>
11: <TR><TD>Nick Name:</TD>
12: <TD><INPUT name="name"></TD></TR>
13: <TR><TD>Password:</TD>
14: <TD><INPUT type=password name="pass"></TD></TR>
15: <INPUT type=hidden name="hide" value="a hidden value">
16: </TABLE>
17: <INPUT type=submit> <INPUT type=reset>
18: </FORM>
19: </BODY>
20: </HTML>
Abbildung 4.1: |
Wenn Sie einmal die Zeile 7 aus Listing 4.3 durch folgende ersetzen, so erhalten Sie eine Fehlermeldung (siehe Abbildung 4.2), da test.html nicht ausführbar ist:
<form action=test.html method=POST>
Abbildung 4.2: |
In diesem Beispiel handelt es sich bei test.html um eine Datei, die einen leeren Bildschirm auf Ihrem Browser ausgibt.
Ersetzen Sie die Zeile 7 des Listings durch folgenden Code, erscheint keine Fehlermitteilung:
<form action test.html method=GET>
Aus Abbildung 4.3 ersehen Sie, daß selbst das versteckt eingegebene Paßwort in der Statuszeile des Browsers erscheint.
Abbildung 4.3: |
Nachdem alle Informationen den Server erfolgreich erreicht haben, müssen diese dekodiert werden. Für Web-Entwickler ist dies mitunter ein erhebliches Problem - für Sie jedoch nicht. ASP übernimmt diese Aufgaben automatisch für Sie und implementiert im Anschluß daran alle Informationen in die entsprechenden Collections. Zwei Collections innerhalb des Request-Objektes beinhalten entsprechende Informationen - die Form-Collection der Post-Methode und die QueryString-Collection der Get-Methode.
Die Form-Collection findet immer dann Verwendung, wenn Informationen zu extrahieren sind, die mittels der Post-Methode versandt wurden.
Request.Form(variablename)[(index)|.Count]
Die Request.Form(variablename)-Methode dekodiert automatisch den verschlüsselten String, sobald Sie ihn über einen gültigen variablename aufrufen. Benötigen Sie Zugriff auf die kodierten Daten, so rufen Sie Request.Form ohne Variablen auf.
Die Methode count ist ein Stolperstein, über den viele ins Trudeln geraten, wenn sie sich mit HTML-Formularen (Forms) beschäftigen. Eine Form-Variable ist in der Lage, viele Werte anzunehmen (gleich einem Array). Count gibt die Anzahl der Einträge im Array zurück (1, wenn die Variable kein Array ist und 0, wenn die Variable in keiner Collection existiert).
Das Argument index wird dazu benutzt, um einen bestimmten Wert aus einer Variablen zu bekommen, solange diese ein Array ist. Index-Nummern beginnen mit 1 (nicht 0). Sollten Sie eine Variable mit mehreren Werten aufrufen, die kein Index-Argument besitzt, ist das Ergebnis dieser Aktion ein String, der mit Kommas getrennt ist und alle entsprechenden Werte enthält.
Die QueryString-Collection hilft Ihnen beim Extrahieren und Dekodieren von Informationen, die über die GET-Methode versandt wurden.
Request.QueryString(variablename)[(index)|.Count]
Das Verhalten der Request.QueryString(variablename)-Methode gleicht der aus dem vorangegangenen Kapitel. Möchten Sie Zugriff auf die unkodierten Daten haben, so benutzen Sie bitte Request.QueryString ohne Parameter.
Ein einfaches Beispiel
Benutzen Sie den HTML-Code aus Listing 4.3, um ein Formular zu erstellen. Listing 4.4 ist ein ASP-Script, welches Informationen dekodiert und im Browser ausgibt.
Listing 4.4: Test.asp dekodiert die Login-Informationen aus Listing 4.3
1: <HTML>
2: <% Select Case Request.ServerVariables("Request_Method")
3: Case "GET"
4: If Request.QueryString("name").Count > 1 then %>
5: Name = <%=Request.QueryString("name")(1)%> <BR>
6: Nick Name = <%=Request.QueryString("name")(2)%> <BR>
7: <%else%>
8: Name = <%=Request.QueryString("name")%> <BR>
9: <%end if%>
10: Password = <%=Request.QueryString("pass")%> <BR>
11: Hidden Field = <%=Request.QueryString("hide")%> <BR>
12: Raw Data: = <%=Request.QueryString%>
13: <%Case "POST"
14: If Request.Form("name").Count > 1 then %>
15: Name = <%=Request.Form("name")(1)%> <BR>
16: Nick Name = <%=Request.Form("name")(2)%> <BR>
17: <%else%>
18: Name = <%=Request.Form("name")%> <BR>
19: <%end if%>
20: Password = <%=Request.Form("pass")%> <BR>
21: Hidden Field = <%=Request.Form("hide")%> <BR>
22: Raw Data: = <%=Request.Form%>
23: <%end select%>
24: </HTML>
Zeile 2 stellt fest, welche Methode benutzt wurde, um die Informationen zu übertragen. In den meisten Fällen werden Sie über die jeweilige Methode Bescheid wissen und automatisch die richtige Collection benutzen. Eine falsche Collection würde im Browser-Fenster einen Fehler hervorbringen. Die Ausgabe ist in Abbildung 4.4 zu sehen.
Abbildung 4.4: |
Cookies müssen geschrieben werden, bevor sie empfangen werden können. In den vergangenen Kapiteln haben Sie einiges über die Erstellung von Cookies erfahren. Der Client-Browser sendet Cookies innerhalb des HTTP-Headers (verschlüsselt). Dazu ein kleines Beispiel für ein Cookie mit dem Namen name und dem Wert Bradley&Ethan:
GET /index.html HTTP/1.0
HTTP_COOKIE: name=Bradley+%26+Ethan
Glücklicherweise müssen Sie den Header nicht sortieren oder etwa sämtliche Strings dekodieren. ASP dekodiert das Cookie und plaziert es automatisch in der entsprechenden Cookie-Collection. Sie müssen nur noch die jeweilige Collection aufrufen:
variable = Request.Cookies(cookiename)
Request.Cookies(»name«) gibt den Text Bradley&Ethan aus, ohne daß Sie genau über den HTTP-Header Bescheid wissen müssen.
Sollte ein Cookie mehr als ein name/value-Paar enthalten, so nennt man es Dictionary (das Attribut HASKEYS wurde auf TRUE gesetzt). Nun betrachten wir ein Cookie mit der Bezeichnung name, das zwei name/value-Paare besitzt. Der Schlüssel oder auch Name des ersten Paares ist names mit dem Wert Bradley&Ethan; der Schlüssel für das zweite Paar ist ages mit den Werten 20&17. Um ein Cookie mit diesen Schlüsseln zu lesen, ist folgende Syntax erforderlich:
variable = Request.Cookies(cookiename)(keyname)
Um den Schlüssel ages für das Cookie name einzusehen, geben Sie bitte folgendes ein:
Request.Cookies("name")("ages")
Agieren Sie vorsichtig bei der Benutzung von Cookies, da die Cookies-Collection unterschiedliche Attribute bereitstellt. Verfügt der Aufruf Request.Cookies über keine Key-Werte, so werden sämtliche name/value-Paare unverschlüsselt dargestellt. Benutzen Sie das folgende Beispiel-Cookie mit den Keys ages und names, um einen entsprechenden Aufruf zu definieren:
Request.Cookies(cookiename)
Das Resultat aus diesem Aufruf ist folgendes:
AGES=20+%26+17&NAMES=Bradley+%26+Ethan
Sollten Sie nicht sicher sein, ob ein Cookie ein Dictionary ist, so überprüfen Sie, ob der Aufruf Request.Cookies.HasKeys den Wert TRUE (1) oder FALSE (0) erbringt. Das Listing 4.5 stellt fest, ob ein Cookie über Keys verfügt und druckt im positiven Fall die Werte aller Keys aus (siehe Abbildung 4.5).
Listing 4.5: Die Überprüfung der Keys und deren Werte
1: <HTML>
2: <%if Request.Cookies("name").Haskeys = 1 then %>
3: Cookie has keys! <BR>
4: <%for each key in Request.Cookies("name")%>
5: Key <%=key%> = <%=Request.Cookies("name")(key)%> <BR>
6: <%next
7: else%>
8: No Keys for cookie! <BR>
9: Name = <%=Request.Cookies("name")%> <BR>
10: <%end if%>
11: </HTML>
Abbildung 4.5: |
|
Sollte ein Browser zwei Cookies mit demselben Namen versenden, wird nur das Cookie mit der tieferen Pfadstruktur in der Cookies-Collection abgespeichert. |
Die ClientCertificate-Collection
Diese Collection enthält die Client-Certificate-Information (wie im X.509-Standard definiert) für SSL3/PCT1-Requests. SSL3 und PCT1 sind Sicherheitsprotokolle, die Ihre Informationen kodieren und vor unberechtigten Zugriffen über das Web schützen. Zertifikate sind verschlüsselte Codes, die auf eindeutige Weise einen Client oder Server identifizieren. Existiert ein Zertifikat auf Client und Server, wird eine Public-Key-Verschlüsselung benutzt, um verschlüsselte Inhalte zu übertragen.
Der IIS (oder Peer Web Server) muß konfiguriert werden, damit er in der Lage ist, zertifizierte Informationen zu verarbeiten. Per Voreinstellung ist er nicht in der Lage, diese Informationen zu bearbeiten. Die Thematik um den X.509-Standard ist sehr komplex und soll an dieser Stelle nur rudimentär Erwähnung finden.
Der Zugriff auf Daten mit Hilfe von Schleifen
Sie können sehr viel Zeit sparen, wenn Sie dem NAME-Attribut im Scrpit die entsprechenden Variablen zuweisen.
Das Listing 4.6 ist ein einfaches HTML-Formular, welches typische User-Informationen enthält, die zu einem späteren Zeitpunkt mit Hilfe von Schleifen in eine ASP-Datei transferiert werden.
Listing 4.6: Der HTML-Code für das einfache Beispiel-Formular
<HTML>
<Body>
<TITLE>A Simple Form</TITLE>
<P ALIGN=CENTER> A SIMPLE FORM
<BR>
Please fill out all information for fields that
not apply answer N/A.
<FORM ACTION=/SCRIPTS/SIMPLE.ASP METHOD=POST>
<TABLE><TR>
<TD>FIRST NAME:</TD>
<TD><INPUT NAME="FNAME"></TD></TR>
<TR><TD>LAST NAME:</TD>
<TD><INPUT NAME="LNAME"></TD></TR>
<TR><TD>PHONE: </TD>
<TD><INPUT NAME="PHONE"></TD></TR>
<TR><TD>EMAIL:</TD>
<TD><INPUT NAME="EMAIL"></TD><TR>
</TABLE>
CHILDRENõS FIRST NAME:<BR>
<INPUT NAME="CHILDREN"><BR>
<INPUT NAME="CHILDREN"><BR>
<INPUT NAME="CHILDREN"><BR>
<INPUT NAME="CHILDREN"><BR>
<INPUT TYPE=SUBMIT><INPUT TYPE=RESET>
</FORM>
</BODY>
</HTML>
Abbildung 4.6 zeigt das Listing in Aktion.
Abbildung 4.6: |
Sie können jeden variablename erhalten, indem Sie einen Request.Form(variablename)-Aufruf starten. Sollten Sie Asp-Codes erstellen, so ist es in der Praxis nicht durchführbar, immer wieder im HTML-Code nachzuschauen, um das Attribut NAME zu finden, das den variablename enthält. Ein eleganter Weg, diese Probleme zu umgehen, ist die Benutzung von Schleifen (iterator-loops).
Als »iterator« bezeichnet man eine Dummy-Variable, die in for- oder foreach-Schleifen verwendet wird. Der folgende Script-Teil gibt jedes name/value-Paar eines HTML-Formulares in Listing 4.6 aus.
<%foreach iterator in Request.Form%>
The variable <%=iterator%> is <%Request.Form(iterator)<BR>
<%next%>
Dieser Code würde das folgende Resultat erbringen, wenn die Daten aus Abbildung 4.6 Anwendung fänden:
Fname = Dolores
Lname = Glover
Phone = 770-555-3722
CHILDREN = Kelly, Bradley, Ethan
Der Name innerhalb eines HTML-Formulars kann, wie Sie bereits wissen, ein Array sein.
Um die Werte aus diesem zu extrahieren, bedarf es des folgenden Scripts:
<% for each key in Request.Form
for index 1 to Request.Form(key).Count%>
<%=key%> = <%=Request.Form(key)(index)%> <BR>
<%next
next%>
Die Ausgabe sieht entsprechend anders aus:
Fname = Dolores
Lname = Glover
Phone = 770-555-3722
CHILDREN = Kelly
CHILDREN = Bradley
CHILDREN = Ethan
Sie können ebenfalls eine andere Form der for-each-Schleife verwenden. Im folgenden Script bekommen Sie die gleiche Bildschirmausgabe, indem Sie key und item in einer for each-Schleife anstelle einer for/next-Schleife verwenden.
<% for each key in Request.Form
for each item in Request.Form(key)%>
<%=key%> = <%=Request.Form(item)%> <BR>
<%next
next%>
Sie können Iterator-Schleifen ebenfalls verwenden, um den Inhalt von Informationen zu testen und zu extrahieren. Dazu bedarf es des folgenden Codes:
<%for each key in Request.Form
if Request.Form(key)= "" then%>
You left the field <%=key%> blank! Please go back and fill out the form
Âcorrectly
<%exit loop
end if
next%>
Das Server-Objekt ist das vielleicht am wenigsten gebrauchte Objekt überhaupt. Dieses Objekt enthält eine Eigenschaft und vier Methoden. Microsoft bezeichnet dieses Objekt als Utility-Objekt, da es ASP um sogenannte Custom-Objekte erweitert, die spezielle Aufgaben übernehmen. Die Methoden sind folgende:
Das Verhalten Ihres Web-Server wird maßgeblich durch den Server-Manager bestimmt bzw. kontrolliert. Die einzige Steuerung, die Sie durch das Server-Objekt haben werden, ist die, wie der Server Ihre ASP-Scripts verarbeitet. Das Script-Buffering wird durch das Response-Objekt gesteuert. Sie haben jedoch die Möglichkeit, den TimeOut des Scripts wie folgt zu beeinflussen:
Server.ScriptTimeOut(seconds)
Scripts, die länger als die spezifizierte Zeit laufen, werden terminiert, um freie Systemressourcen zu schaffen. Der entsprechende Wert beträgt per Voreinstellung 90 Sekunden. Um diesen Wert zu ändern, müssen Sie sich in die Registry begeben, um den Wert zu ändern.
|
Sie sollten den Wert von ScriptTimeOut nur dann ändern, wenn Sie planen, ihn größer als den Standardwert zu definieren. Stellen Sie diesen Wert kleiner als 90 Sekunden ein, passiert gar nichts, da der IIS mit dem Script erst dann fortfährt, wenn der entsprechende Wert erreicht wurde. |
Die Methoden HTMLEncode und URLEncode
Es wird Zeiten geben, da Sie sich wünschen, Ihre Daten-Strings zu dekodieren, um diese anderen Applikationen oder Methoden zur Verfügung zu stellen. Sie denken vielleicht, daß diese Methoden zum Response-Objekt gehören, doch dem ist nicht unbedingt so, da Sie vielleicht mehr möchten, als die kodierten Daten nur zum Browser zu schicken. Vielleicht möchten Sie die Daten kodieren, bevor diese in einer Datei oder Datenbank abgespeichert werden, so daß sich diese Methoden eigentlich mehr auf das Server-Objekt beziehen.
Die URL-Verschlüsselung ersetzt Leerzeichen durch Pluszeichen (+) sowie alle nicht-alphanumerischen durch hexadezimale Werte (nach RFC 1783).
variablename = Server.URLEncode("<h1>Quantum Consulting Services</H1>")
speichert den String
%3CH1%3EQuantum+Consulting+Services%3C%2fH1%3E
in variablename.
In HTML gibt es eine Menge spezieller und nicht-alphanumerischer Zeichen. Um diese in vernünftiger Art und Weise anzuzeigen, muß ein Mapping auf die entsprechenden hexadezimalen Codes oder jenen nach der RFC 1738 stattfinden. Benutzen Sie das kaufmännische UND (&), gefolgt vom Code und einem Semikolon (;), oder benutzen Sie das &-Zeichen, gefolgt von einem Doppelkreuz (#) sowie dem hexadezimalen Code, dem abschließend ein Semikolon folgt.
Um den String
<H1>Kelly & Sharonõs Page</H1>
auf dem Client-Browser anzuzeigen, sollte der HTML-Code wie folgt aussehen:
<H1> Kelly & Sharonõs Page </H1>
Glücklicherweise müssen Sie sich nicht mit den jeweiligen Codes »herumschlagen«, alles was Sie benötigen, ist die HTMLEncode-Methode. Um den entsprechenden Code korrekt anzuzeigen, müssen Sie nur folgendes durchführen:
<%=Server.HTMLEncode("<h1> Kelly & Sharonõs Page </h1>")%>
Das Server-Objekt hat Informationen über den virtuellen, relativen und physikalischen Pfad Ihres Servers, so daß es in der Lage ist, Mappings durchzuführen. Sie benötigen die Möglichkeit des Mappings von Pfaden, um Verzeichnisse zu erstellen oder Dateien auf dem Server zu manipulieren. Benutzen Sie die MapPath-Methode, um einem physikalischen Pfad einen entsprechenden virtuellen oder relativen zuzuweisen. Die Syntax lautet wie folgt:
variablename = Server.MapPath(pathname)
Beginnt pathname mit einem Slash oder Backslash, so führt diese Methode ein Mapping auf einen virtuelle Pfad durch. Andernfalls wird pathname relativ zu einem Verzeichnis gemappt, wo sich die ASP-Datei befindet, welche die entsprechende Methode aufgerufen hat. Haben Sie Ihren Web-Server und ASP so eingestellt, daß nur Default-Werte Anwendung finden, so würden Sie folgendes Ergebnis einer ASP-Datei im Verzeichnis c:\inetpub\scripts erhalten:
c:\inetpub\scripts directory:
<%=Server.MapPath("/scripts")%>
<%=Server.MapPath("scripts")%>
Der Browser würde folgendes anzeigen:
c:\inetpub\scripts
c:\inetpub\scripts\scripts
|
Die MapPath-Methode überprüft nicht, ob der entsprechende Pfad auch wirklich existiert. |
Primär werden Sie das Server-Objekt dazu benutzen, um Server-Komponenten zu erstellen. Um was es sich dabei genau handelt, werden Sie im vierten Tag dieses Buches erfahren. Server-Komponenten erstellen Sie mit Hilfe der CreateObject-Methode:
Set objectname = Server.CreateObject(ProgID)
Sie müssen den Befehl Set in Verbindung mit der CreateObject-Methode verwenden. ProgID ist der registrierte Name Ihres Objektes. Mehr über Registrierung erfahren Sie im nächsten Kapitel. Es ist wichtig im Hinterkopf zu behalten, daß objectname nicht das geiche ist wie die vier im ASP enthaltenen Objekte. Ein bereits erstelltes Objekt können Sie mit folgender Syntax zerstören:
Set objectname = Nothing
Über die CreateObject-Methode erstellte Beispielobjekte werden zerstört, sobald die Web-Seite fertig bearbeitet wurde.
Die Benutzung der Objekte Session und Application, um einen Zustand aufrechtzuerhalten
Eines der größten Probleme beim Umgang mit HTTP ist der nicht-verbindungsorientierte Zustand von HTTP. Das Web-Protokoll verbindet sich, sendet Informationen und schließt anschließend wieder die Verbindung, um Ressourcen freizugeben. Theoretisch stellt dies kein Problem dar, solange Sie nur Inhalte anzeigen möchten, doch sobald es um Interaktion mit dem Anwender geht, gibt es damit diverse Probleme.
Damit Browser und Server miteinander interagieren können, müssen gewisse Informationen bzw. Zustände über mehrere Requests hinweg gespeichert werden. CGI-Programmierer haben im Laufe der Zeit eine Menge Wege gefunden, um diese unter Zuhilfenahme diverser HTML- und CGI-Umgebungsvariablen durchzuführen. In unserem Fall übernimmt der Server sämtliche Tätigkeiten, um seinen Status eigenständig vorzuhalten. Netscape implementierte die derzeit professionellste Lösung, die auch von anderen Unternehmen übernommen wurde - Cookies. Ein Cookie ist im einfachsten Fall eine Art Container, der Informationen in Form eines Arrays enthält. Obwohl Cookies für die meisten Anwendungsfälle eine gute Alternative darstellen, bedarf es doch immer noch einigen Programmieraufwandes, um den Zustand aller Variablen über mehrere Requests hinweg festzuhalten.
ASP versetzt Sie jedoch glücklicherweise in die Lage, den Zustand von Variablen »einzufrieren«, ohne daß Sie über Cookie-Logik, HTTP-Header oder andere schwer zu handhabende Dinge Bescheid wissen müssen. Microsoft gibt Ihnen zwei Objekt-Container in die Hand, welche alle relevanten Informationen beherbergen. ASP speichert den Zustand von Variablen wesentlich einfacher als CGI oder HTML.
|
ASP benutzt derzeit Cookies, um den Status von Variablen über mehrere Requests hinweg abzuspeichern, indem die Objekte Session und Application Anwendung finden. Einige Browser unterstützen jedoch keine Cookies, so daß eine Zustandsspeicherung über mehrere Seiten hinweg nicht stattfinden kann. |
Der Unterschied zwischen beiden Objekten liegt in deren Anwendungsbereich. Im Rahmen des Anwendungsbereiches wird definiert, welche Informationen für welchen Anwender verfügbar sind.
Informationen, die im Session-Objekt gespeichert werden, sind nur jenen Clients verfügbar, welche die Informationen in diesem Objekt erstellt haben. Diese Informationen werden auch »Session-Scope« genannt. Im Application-Objekt sind Informationen abgelegt, die jeder Anwender abrufen kann, der Zugriff auf die entsprechende ASP-Applikation hat. Diese Informationen werden auch als »Information-Scope« bezeichnet. Variablen und Objekte, die im Rahmen eines Scripts erstellt wurden, jedoch nicht im Session- oder Application-Objekt gespeichert sind, verfallen, nachdem das Script beendet wurde. Diese Variablen und Objekte bezeichnet man als »Page-Scope«.
Gefahren beim Umgang mit den Session- und Application-Objekten
Die Objekte Session und Application beinhalten Variablen, Arrays und andere Objekte. Es gibt nur drei Gefahren bzw. »Klippen«, die Sie beim Umgang mit diesen Objekten umschiffen müssen:
Session(Array)(arrayindex) = value
Dieser Code legt value nicht an der Position arrayindex des Array ab, welcher im Session-Objekt gespeichert ist. Der Code würde ebenfalls einen Fehler für das Application-Objekt hervorbringen, da beide Objekte als Collection implementiert wurden. Im vorangegangenen Code wurde value in den Index der Collection arrayindex aufgenommen und überschreibt bereits existierende Objekte in der Collection. Sollten Sie den Wunsch haben, Informationen innerhalb eines Arrays des Application- oder Session-Objekts zu ändern, so erstellen Sie bitte als erstes eine Arbeitskopie. Führen Sie nur innerhalb dieser Kopie Ihre Änderungen durch, und speichern Sie abschließend die Kopie im Session- oder Application-Objekt.
Set Session("objname") = Server.CreateObject("componentobject")
|
Sollten Sie Objekte abspeichern, so müssen Sie ebenfalls den Typ des Threading-Modells des Objekts beachten. Mehr dazu erfahren Sie am sechsten Tag. Lediglich Objekte, die Free- und Apartment-Threaded sind, können in Application- und Session-Objekten abgespeichert werden. |
Ein neues Session-Objekt wird immer dann erstellt, wenn ein Anwender keine Session-ID an das ASP-Script übergibt. Der Server erkennt, ob sich ein Browser derzeit innerhalb einer Session befindet, da das SessionID-Cookie mit einem Request versendet wird. Session-Informationen werden solange vorgehalten, bis die Session.Abandon-Methode aufgerufen wird oder die Eigenschaft Session.TimeOut aktiviert ist. Der Standardwert für TimeOut beträgt 20 Minuten. Nach jedem neuen oder aufgefrischtem Request wird der Taktgeber zurücksetzt.
Jede Session hat eine eindeutige ID, die vom Server bei seiner Installation festgelegt wird. Diesen Wert können Sie verändern, indem Sie die Eigenschaft Session.SessionID modifizieren. Diese Eigenschaft ist Read-Only.
Ein Application-Objekt wird vor dem ersten Session-Objekt erstellt. Das Application-Objekt wird nicht zerstört, bis der Server heruntergefahren oder bis die Datei global.asa (wird später noch erläutert) modifiziert wurde und alle Anwender keine Verbindung mehr haben.
Da eine Vielzahl von Anwendern Zugriff auf das Application-Objekt haben, müssen Sie auf das Konkurrenz-Verhalten eine Auge werfen. Damit bezeichnet man die Problematik, wenn zwei Anwender versuchen, die gleichen Daten zur selben Zeit zu modifizieren. Es gibt kein Problem, wenn mehrere User gleichzeitig versuchen, Daten zu lesen, doch wenn Sie Informationen im Application-Objekt ändern müssen, benötigen Sie einen exklusiven Zugriff auf diese Datei. Einen exklusiven Zugriff erhalten Sie mittels der Lock-Methode wie folgt:
Application.Lock
Nachdem Sie alle notwendigen Änderungen durchgeführt haben, sollten Sie Ihren exklusiven Zugriff wieder freigeben, damit auch andere Anwender Zugriff auf diese Datei zur Modifikation haben. Die Zugriffsrechte können Sie wie folgt wieder herstellen:
Application.UnLock
Um die Anwendung der beiden Objekte Application und Session zu veranschaulichen, ist es notwendig, sich eine Applikation zu betrachten, innerhalb derer Sie Informationen über die Post-Methode aus einem Formular erhalten haben und die Sie zur späteren Weiterverarbeitung speichern möchten. Diese Information wird nur von einem User benötigt, so daß die Daten im Session-Objekt abgespeichert werden können. Der folgende Code speichert alle Informationen aus dem Formular in das Session-Objekt, indem es Schleifen verwendet:
<% For each key in Request.Form
Session(key)=Request.Form(key)
next %>
Es spielt keine Rolle, wie groß das Formular ist oder wie die Information aufgerufen wurde - Sie haben die Informationen zur späteren Weiterverarbeitung mit nur drei Zeilen Code realisiert.
Möchten Sie obendrein noch wissen, wie viele Anwender sich in Ihr Formular eingetragen haben, so müssen Sie einen Zähler implementieren. Diese Zählerinformationen sollen und müssen für jedermann einsichtig sein, so daß Sie diese Daten im Application-Objekt abspeichern müssen. Modifizieren Sie den Code dazu wie folgt:
<%Application.Lock
Application("numfilled-out")=Application("numfilled-out") +1
Application.Unlock
For each key in Request.Form
Session(key)=Request.Form(key)
next %>
Die Session- und Application-Objekte können von einer Seite oder einem Event (Ereignis) aus modifiziert werden.
Die global.asa-Datei bezieht sich direkt auf das Application- und Session-Objekt. Es hat zwei Aufgaben:
Die Datei global.asa darf nur diese Bezeichnung tragen und muß sich im Root-Verzeichnis der entsprechenden ASP-Applikation befinden. Innerhalb von global.asa befinden sich zwei Container - der Objekt-Container <OBJECT> und der Script-Container <SCRIPT>. Der Code wird zwischen <SCRIPT></SCRIPT>-Tags und Objekt-Deklarationen zwischen <OBJECT>-Tags plaziert.
Der <OBJECT>-Tag hat die folgenden Attribute:
<OBJECT RUNAT=Server SCOPE=Scope ID=Identifier
Â{PROGID="progID"|CLASSID="ClassID"}>
Dem RUNAT-Attribut können Sie entweder den Parameter Application oder Session zuweisen. Der identifier ist der Name, den Sie dem Objekt zuweisen, das Sie erstellen möchten.
Objekte werden erst erstellt, wenn Sie im Script aufgerufen werden. Diese Vorgehensweise spart System-Ressourcen und Zeit.
Der <SCRIPT>-Tag verfügt über folgende Attribute:
<SCRIPT LANGUAGE=ScriptLanguage RUNAT=SERVER>
|
Objekte sind »Self-Contained«. Sie sollten deshalb keinen <OBJECT>-Tag innerhalb eines <SCRIPT>-Tags plazieren. Code oder anderweitige Deklarationen sollten nicht außerhalb des <SCRIPT>- oder <OBJECT>-Tags programmiert werden. |
Die Application- und Session-Objekte haben jeweils zwei Events - OnStart und OnEnd. Sollten Sie VBScript verwenden, wird jedes Ereignis als SUB definiert und besitzt die Form Object_Event als Application_OnStart, Application_OnEnd, Session_OnStart oder Session_OnEnd:
<SCRIPT LANGUAGE=ScriptLanguage RUNAT=SERVER>
SUB Object_Event
'Your event code here
END SUB
'Other Event SUBs written in VBScript
</SCRIPT>
Nicht alle Objekte oder Methoden sind in allen Ereignissen verfügbar. Dies wird Ihnen spätestens dann klar, wenn Sie begreifen, wie Applikationen Ereignisse verwenden, um die Datei global.asa zu starten. Prozeduren, die Sie erstellen, sind nur lokal innerhalb der Datei global.asa verfügbar und können nicht direkt aus der ASP-Datei gestartet werden.
Das Listing 4.7 ist ein Beispiel für eine global.asa-Datei:
Listing 4.7: Ein Beispiel für die global.asa-Datei
1: <SCRIPT LANGUAGE=VBScript RUNAT=SERVER>
2: SUB Application_OnStart
3: 'load count from file if it exists
4: END SUB
5:
6: SUB Session_OnStart
7: Application.Lock
8: Application("count") = Application("count") + 1
9: Application.Unlock
10: END SUB
11:
12: SUB Application_OnEnd
13: 'code to write to the count file
14: END SUB
15: </SCRIPT>
Die Startsequenz für die global.asa-Datei
Application-Objekte werden erstellt, sobald der Anwender sich zum ersten Mal zu einer ASP-Applikation verbindet und eine Session eröffnet. Sobald das Application-Objekt erstellt wurde, schaut der Server nach der Datei global.asa. Existiert die Datei, wird das Script für Application_OnStart ausgeführt. Die Erstellung des Objektes startet das Session_OnStart-Ereignis. Das Script, das sich in gobal.asa befindet, wird gestartet, bevor die Objekt-Erstellung abgeschlossen ist. Sobald das Session-Objekt seine zeitliche Limitierung erreicht oder die Methode Session.Abandon aufgerufen wird, wird das Ereignis Session_OnEnd aufgerufen. Der Code für Session_OnEnd in global.asa wird ausgeführt, bevor das Session-Objekt zerstört wird. Sobald der Server einem Shut-Down unterzogen wird, reagiert das Application_OnEnd-Ereignis. Sämtliche Sessions werden gelöscht und der Session_OnEnd ausgeführt.
Bevor die Datei global.asa sich verändert, führt der Server eine neue Kompilierung durch. Um eine Re-Kompilierung durchzuführen, muß der Server die aktuellen Application- und Session-Objekte löschen und einen Neustart durchführen. Zuerst verarbeitet der Server alle aktiven Requests. Der Server wird im Anschluß daran keine weiteren Requests mehr bearbeiten, bis Application_OnEnd ausgeführt wurde. Anwender, die während dieses Vorganges zum Server eine Verbindung herzustellen, bekommen die Fehlermeldung The request cannot be processed while the application is restarted. Nachdem die aktiven Prozesse verarbeitet wurden, geschieht das folgende:
1. Die aktive Session wird verlassen. Diese Aktion löst das Session_OnEnd-Ereignis für jede Session aus.
2. Die Applikation wird abgebrochen, was das Application_OnEnd-Ereignis auslöst.
3. Weitere Requests starten das Application-Objekt neu und erstellen neue Session-Objekte. Diese Aktionen lösen die Ereignisse Application_OnStart und Session_OnStart aus.
Spezielle Ereignis-Betrachtungen
Jedes Ereignis hat seine eigenen Betrachtungsweisen und »Marotten«. Tabelle 4.5 hilft Ihnen, diese kleinen Widrigkeiten und Fallstricke zu erkennen.
Tabelle 4.5: Ereignis-Restriktionen
Ereignis |
Betrachtung |
Application_OnStart |
Die einzigen ASP-Objekte, die diesem Ereignis innewohnen, sind Server und Application. Der Aufruf der anderen drei ASP-Objekte bringt eine Fehlermeldung. |
Session_OnStart |
Sämtliche Standard-ASP-Objekte sind diesem Ereignis zuweisbar. Ruft das Ereignis die Methoden Redirect oder End auf, so wird das folgende Script und die angeforderte Seite nicht dargestellt. Aus diesem Grund sollten Sie diese Methoden erst am Ende Ihres Scripts aufrufen. Sie sollten die Redirect-Methode in diesem Ereignis benutzen, um sicherzustellen, daß der Anwender mit der korrekten Seite startet und nicht in die Mitte einer ASP-Applikation springt. |
Application_OnEnd |
Nur die Application- und Server-Objekte sind im Rahmen dieses Ereignisses verfügbar. |
Session_OnEnd |
Nur die Objekte Application, Server und Session sind in diesem Ereignis verfügbar. Sie können nicht die Methode Server.MapPath aufrufen. |
Verständnis für die global.asa-Datei
Nun, da Sie einiges über die Fakten wissen, sehen Sie sich bitte noch mal das Listing 4.7 an. Die gesamte Datei beschäftigt sich hauptsächlich damit aufzuzeichnen, wie viele Sessions auf dem Server gestartet wurden. Sobald die Applikation startet, enthält Zeile 3 den Code, der den aktuellen Zählerstand aus einer Datei lädt. Jede neue Session erhöht den Zählerstand um den Faktor Eins. Zeile 7 greift auf das Objekt Application zu, Zeile 8 erhöht den Zähler um den Faktor Eins und Zeile 9 verläßt die Counter-Routine wieder. Dieser Mechanismus wird nur beim Start jeder neuen Session durchgeführt.
Sobald die Applikation beendet wird, schreibt Zeile 13 die Anzahl der Sessions auf die Festplatte, bis die Applikation von neuem gestartet wird.
Zusammenfassung
ASP besitzt fünf wesentliche Objekte, welche die ganze Palette der Arbeit übernehmen. Sie können andere Objekte hinzufügen, um die Funktionalität des Servers zu erweitern - für die meisten Aufgaben sollten jedoch die fünf Standard-Objekte ausreichen. Das Request-Objekt wird benutzt, um Client-Informationen zu empfangen, das Response-Objekte sendet Daten zum Client. Das Server-Objekt ist Ihr Utility-Objekt, das verschiedene Aufgaben ausführt. Zu guter Letzt werden die Objekte Application und Session dazu benutzt, den Status des Servers festzustellen. Um in die Sphären eines erfolgreichen Web-Entwicklers aufzusteigen, sollten Sie sich weiter im Bereich des HTTP-Protokolls und MIME-Typen weiterbilden.
Was kommt als nächstes?
Im nächsten Kapitel erlernen Sie alles über die Erstellung von Custom-Objekten. Sie können diese Art von Objekten dazu benutzen, um die Fähigkeiten von ASP zu erweitern, damit der Server erweiterte Aufgaben erfüllen kann.
Fragen und Antworten
Frage:
Wie viele Objekte enthält ASP standardmäßig?
Antwort:
Fünf.
Frage:
Welche sind die drei wichtigsten Eigenschaften HTTPs?
Antwort:
Es ist nicht-verbindungsorientiert, Medien-abhängig und besitzt keinen Status.
Frage:
Ist die Datei global.asa notwendig?
Antwort:
Nein. Sie ist ein optionaler Weg, den Code auszuführen, der auf einem Ereignis beruhen soll.
Beispiele
1. Benutzen Sie die Expire-Eigenschaft, und konfigurieren Sie den Code so, daß Sie die Informationen im Cache des Users der letzten 24 Stunden ausgelesen werden können.
2. Besuchen Sie die Web-Site http://ds.internic.net/rfc/rfc2068.txt, und lesen Sie über neueste Entwicklungen im Bereich HTTP und MIME.
Ein Imprint des Markt&Technik Buch- und Software-Verlag GmbH. , Krefeld.
