> Wie erstelle ich ein Script (VBScript), so das Cookies erstellt werden, nicht auf dem Server sondern beim Client.
Cookies werden immer auf dem Client erstellt. Hier mal der Ausschnitt aus der Hilfe (http://localhost/iishelp/) Verwalten von Sitzungen Eine der Schwierigkeiten bei der Entwicklung einer erfolgreichen Webanwendung liegt darin, Benutzerinformationen �ber den Verlauf eines Besuchs oder einer Sitzung zu verwalten, w�hrend die Benutzer sich in einer Anwendung von einer Seite zur anderen bewegen. HTTP ist ein statusfreies Protokoll; das bedeutet, dass der Webserver alle HTTP-Anforderungen nach einer Seite als unabh�ngige Anforderungen behandelt. Der Server hat keine Informationen �ber vorhergehende Anforderungen, selbst wenn sie nur Sekunden vor der aktuellen Anforderung ausgef�hrt wurden. Dadurch wird das Schreiben von Anwendungen erschwert, wie z. B. das Schreiben eines Onlinekatalogs, bei dem die Anwendung eventuell die Katalogelemente nachverfolgen muss, die von einem Benutzer beim Springen zwischen verschiedenen Katalogseiten ausgew�hlt wurden. ASP stellt eine eindeutige L�sung f�r das Problem der Verwaltung von Sitzungsinformationen bereit. Durch Verwenden des Session-Objekts von ASP sowie einer speziellen von Ihrem Server generierten Benutzer-ID k�nnen Sie intelligente Anwendungen erstellen, die jeden Besucher identifizieren und Informationen sammeln, die die Anwendung dann zur Nachverfolgung der Benutzereinstellungen oder -auswahl verwenden kann. Wichtig ASP weist die Benutzer-ID mitilfe eines HTTP-Cookies zu; bei dem es sich um eine kleine im Browser des Benutzers gespeicherte Datei handelt. Wenn Sie also eine Anwendung f�r Browser erstellen, die keine Cookies unterst�tzen, oder wenn die Browser der Kunden so eingestellt sind, dass Cookies abgelehnt werden, sollten Sie die Features zur Sitzungsverwaltung von ASP nicht verwenden. Starten und Beenden von Sitzungen Eine Sitzung kann auf vier Arten beginnen: Ein neuer Benutzer fordert einen URL an, dereine ASP-Datei in einer Anwendung identifiziert, und die Datei Global.asa f�r diese Anwendung enth�lt eine Session_OnStart-Prozedur. Ein Benutzer speichert einen Wert im Sitzungsobjekt. Es wird automatisch eine neue Sitzung gestartet, wenn der Server eine Anforderung empf�ngt, die kein g�ltiges Informationen zu SessionID und Cookies enth�lt. Ein Benutzer fordert eine ASP-Datei in einer Anwendung an, und die Datei Global.asa der Anwendung verwendet das <OBJECT>-Tag, um eine Instanz f�r ein Objekt mit einem Sitzungsbereich zu erstellen. Weitere Informationen zum Verwenden des <OBJECT>-Tags f�r das Instanziieren eines Objekts finden Sie unter ... Verwenden von Komponenten und Objekten. Eine Sitzung endet automatisch, wenn Benutzer bis zum Ablauf einer bestimmten Zeitspanne eine Seite in einer Anwendung weder angefordert noch aktualisiert haben. Der Standardwert ist 20 Minuten. Sie k�nnen die Standardeinstellung f�r eine Anwendung �ndern, indem Sie die Eigenschaft Timeout auf dem Eigenschaftenblatt Anwendungsoptionen im IIS-Snap-In einstellen. Legen Sie diesen Wert in �bereinstimmung entsprechend den Anforderungen der Webanwendung und der Speicherkapazit�t des Servers fest, Wenn Sie z. B. davon ausgehen, dass Benutzer, die Ihre Webanwendung durchsuchen, nur wenige Minuten auf den einzelnen Seiten verbringen, liegt es in Ihrem Interesse, den Timeoutwert im Vergleich zur Standardeinstellung deutlich zu senken. Eine gro�e Zeitspanne f�r das Sitzungstimeout kann viele aktive Sitzungen zur Folge haben, was sich negativ auf die Speicherressourcen des Servers auswirken kann. Wenn Sie ein Timeoutintervall f�r eine bestimmte Sitzung festlegen m�chten, das k�rzer als das Standardtimeout der Anwendung ist, k�nnen Sie auch die Timeout-Eigenschaft des Sitzungsobjekts einstellen. So legt z. B. das folgende Skript ein Timeoutintervall von 5 Minuten fest. <% Session.Timeout = 5 %> Sie haben zudem die M�glichkeit, das Timeoutintervall so festzulegen, dass der Standardwert (der durch die Sitzungstimeout-Eigenschaft festgelegte Wert) �berschritten wird. Anmerkung Timeout ist nur g�ltig bei Sitzungen, die einen Status haben. W�hrend einer statusfreien Sitzung enth�lt das Sitzungsobjekt weder Inhalt noch statische Objekte. Diese Art der Sitzung endet automatisch nach der Verarbeitung der Anforderung und wird bei der n�chsten Anforderung von demselben Browser erneut erstellt. Wenn Sie eine Sitzung absichtlich beenden m�chten, k�nnen Sie die Abandon-Methode des Sitzungsobjekts verwenden. So k�nnen Sie beispielsweise eine Schaltfl�che Beenden in einem Formular bereitstellen, wobei der ACTION-Parameter auf den URL einer ASP-Datei festgelegt ist , die den folgenden Befehl enth�lt. <% Session.Abandon %> Anmerkung Alle Anforderungen eines Benutzers, die in einer Warteschlange eingereiht werden, um vor der Initierung von Session.Abandon ausgef�hrt zu werden, werden im Kontext der abgebrochenen Sitzung ausgef�hrt. Nach dem Ausf�hren von Session.Abandon werden neue eingehende Anforderungen nicht der Sitzung zugeordnet. Informationen zu SessionID und Cookies Wenn ein Benutzer eine ASP-Datei in einer bestimmten Anwendung zum ersten Mal anfordert, generiert ASP eine SessionID. Eine SessionID ist eine Zahl, die aus einem komplexen Algorithmus erzeugt wurde und alle Sitzungen eines Benutzers eindeutig bezeichnet. Zu Beginn einer neuen Sitzung speichert der Server die SessionID im Webbrowser des Benutzers als Cookie. Das SessionID-Cookie ist mit einem Schlie�fachschl�ssel vergleichbar, da ASP Informationen f�r die Benutzer in einem �Schlie�fach� auf dem Server speichern kann, w�hrend der Benutzer oder die Benutzerin im Verlauf einer Sitzung mit einer Anwendung interagiert. Das SessionID-Cookie des Benutzers, das im Header der HTTP-Anforderung �bertragen wird, erm�glicht den Zugriff auf diese Informationen auf dieselbe Art, wie der Zugriff auf den Inhalt eines Schlie�faches mithilfe eines Schlie�fachschl�ssels m�glich ist. Wenn ASP eine Anforderung f�r eine einer Seite empf�ngt, wird der Header der HTTP-Anforderung auf ein SessionID-Cookie �berpr�ft. Nach dem Speichern des SessionID-Cookies im Browser des Benutzers verwendet ASP dasselbe Cookie erneut, um die Sitzung nachzuverfolgen, selbst wenn der Benutzer eine andere ASP-Datei oder eine ASP-Datei anfordert, die in einer anderen Anwendung ausgef�hrt wird. Wenn der Benutzer die Sitzung absichtlich beendet oder das Sitzungstimeout zul�sst und anschlie�end eine weitere ASP-Datei anfordert, beginnt ASP mithilfe desselben Cookies mit einer neuen Sitzung. Ein Benutzer empf�ngt nur dann ein neues SessionID-Cookie, wenn der Serveradministrator den Server neu startet und dadurch die im Arbeitsspeicher gespeicherten SessionID-Einstellungen l�scht oder wenn der Benutzer den Webbrowser neu startet. Durch erneutes Verwenden des SessionID-Cookies minimiert ASP die Anzahl der Cookies, die an den Browser gesendet werden. Wenn Sie zudem feststellen, dass Ihre ASP-Anwendung keine Sitzungsverwaltung ben�tigt, k�nnen Sie verhindern, dass ASP Sitzungen nachverfolgt und SessionID-Cookies an Benutzer sendet. Unter den folgenden Bedingungen sendet ASP die SessionID-Cookies nicht: Wenn der Sitzungszustand einer Anwendung deaktiviert ist. Wenn eine ASP-Seite als ohne Session definiert ist, es sich also um eine Seite handelt, die das <%@ EnableSessionState=False %> -Tag enth�lt. Weitere Informationen erhalten Sie unter ASP-Seiten ohne Session. Sie sollten dar�ber hinaus beachten, dass SessionID-Cookies nicht als dauerhafte Methode f�r die Nachverfolgung von Benutzern �ber mehrere Besuche auf einer Website hinweg angesehen werden k�nnen. Die im Arbeitsspeicher des Servercomputers gespeicherten SessionID-Informationen k�nnen leicht verloren gehen. Wenn Sie Benutzer, die Ihre Webanwendung besuchen, �ber l�ngere Zeit nachverfolgen m�chten, m�ssen Sie eine Benutzeridentifizierung durch Speichern eines speziellen Cookies im Webbrowser des Benutzers erstellen und die Cookieinformationen in einer Datenbank speichern. Weitere Informationen finden Sie unter Verwenden von Cookies. Speichern und Entfernen von Daten im bzw. aus dem Sitzungsobjekt Das Sitzungsobjekt verf�gt �ber ein dynamisches, zugeordnetes Array, in dem Sie Informationen speichern k�nnen. Sie k�nnen skalare Variablen und Objektvariablen im Sitzungsobjekt speichern. Um eine Variable im Sitzungsobjekt zu speichern, m�ssen Sie einem benannten Eintrag einen Wert im Sitzungsobjekt zuweisen. So speichert der folgende Befehl beispielsweise zwei neue Variablen im Sitzungsobjekt: <% Session("Vorname") = "Johannes" Session("Nachname") = "Schmitt" %> Wenn Sie Informationen aus dem Sitzungsobjekt abrufen m�chten, m�ssen Sie auf den benannten Eintrag zugreifen. So k�nnen Sie z. B. den aktuellen Wert von Session("Vorname") anzeigen: Willkommen <%= Session("Vorname") %> Sie haben die M�glichkeit, Benutzereinstellungen im Sitzungsobjekt zu speichern und anschlie�end auf diese Einstellungen zuzugreifen, um zu ermitteln, welche Seite an den Benutzer zur�ckgegeben werden soll. So k�nnen Sie es einem Benutzer z. B. erm�glichen, eine Textversion des Inhalts auf der ersten Seite der Anwendung anzugeben und diese Auswahl auf alle nachfolgenden Seiten anzuwenden, die der Benutzer in der Anwendung besucht. <% If Session("Aufl�sung") = "Niedrig" Then %> Dies ist die Textversion der Seite. <% Else %> Dies ist die Multimediaversion der Seite. <% End If %> Sie k�nnen auch eine Objektinstanz im Sitzungsobjekt speichern, obwohl dadurch eine Verminderung der Serverleistung zu erwarten ist. Weitere Informationen finden Sie unter Festlegen des G�ltigkeitsbereichs eines Objekts . Es kann sich gelegentlich als sinnvoll erweisen, im Sitzungsobjekt gespeicherte Elemte zu l�schen. So kommt es z. B. relativ h�ufig vor, dass Benutzer, die online einkaufen, ihre Meinung �ndern und die Liste der ausgew�hlten Elemente verwerfen, um sich f�r andere Produkte zu entscheiden. In einem solchen Fall empfiehlt es sich, das Sitzungsobjekt durch L�schen der ungeeigneten Werte zu aktualisieren. Die Contents-Auflistung des Sitzungsobjekts enth�lt alle Variablen, die f�r eine Sitzung gespeichert wurden (also Variablen, die ohne Verwendung des HTML-Tags <OBJECT> gespeichert wurden). Durch Verwenden der Remove-Methode der Contents-Auflistung k�nnen Sie einen Verweis auf eine Variable, der f�r den Sitzungszustand hinzugef�gt wurde, selektiv entfernen. Im folgenden Skript wird die Verwendung der Remove-Methode zum Leeren eines Elements (in diesem Fall Benutzerrabattinformationen) aus dem Sitzungsobjekt veranschaulicht: <% If Session.Contents("Bestellmenge") <= 75 then Session.Contents.Remove("Rabatt") End if %> Sie k�nnen gegebenenfalls auch die RemoveAll-Methode der Contents-Auflistung verwenden, um alle f�r die Sitzung gespeicherten Variablen zu l�schen: Session.Content.RemoveAll() Bei Verwendung der Remove-Methode k�nnen Sie w�hlen, ob Elemente nach Namen oder Index gel�scht werden sollen. Im folgenden Skript wird veranschaulicht, wie der Zyklus bei Werten, die im Sitzungsobjekt gespeichert sind, durchlaufen wird und wie Werte nach dem Index bedingt entfernt werden: <% For Each intQuote in Session.Contents If Session.Contents(intQuote) < 200 Then Session.Contents.Remove(intQuote) End If Next %> Verwalten von Sitzungen auf mehreren Servern Die ASP-Sitzungsinformationen werden auf dem Webserver gespeichert. Damit Skripts auf Sitzungsinformationen zugreifen k�nnen, muss ein Browser Seiten von demselben Webserver anfordern. Bei einem Cluster aus Webservern (wobei sich viele Webserver die Aufgabe teilen, auf Benutzeranforderungen zu antworten) werden Benutzeranforderungen nicht immer an denselben Server weitergeleitet. Stattdessen verteilt eine spezielle Software alle Anforderungen f�r den URL der Site an einen beliebigen freien Server � dieser Vorgang wird als Lastenausgleich bezeichnet. Durch den Lastenausgleich ist die Verwaltung von Sitzungsinformationen in einem Cluster aus Webservern schwierig. Wenn Sie die ASP-Sitzungsverwaltung auf einer Website mit Lastenausgleich verwenden m�chten, sollten Sie sicherstellen, dass alle Anforderungen innerhalb einer Benutzersitzung an denselben Webserver geleitet werden. Eine M�glichkeit ist das Schreiben einer Session_OnStart-Prozedur, die das ResponseObjekt zum Umleiten des Browsers an den Webserver verwendet, auf dem die Sitzung des Benutzers ausgef�hrt wird. Wenn Sie auf den Seiten der Anwendung ausschlie�lich relative Verkn�pfungen verwenden, werden k�nftige Anforderungen f�r eine Seite an denselben Server weitergeleitet. So k�nnen Benutzer z. B. auf eine Anwendung zugreifen, indem sie den allgemeinen URL f�r eine Site anfordern: http://www.microsoft.com/germany/. Durch den Lastenausgleich wird die Anforderung an einen bestimmten Server (z. B. server3.microsoft.com) weitergeleitet. ASP erstellt eine neue Benutzersitzung auf diesem Server. In der Session_OnStart-Prozedur wird der Browser an den angegebenen Server umgeleitet: <% Response.Redirect("http://server3.microsoft.com/webapps/firstpage.asp";) %> Der Browser fordert die angegebene Seite an, und alle nachfolgenden Anforderungen werden an denselben Server weitergeleitet, so lange nicht auf bestimmte Servernamen in den urspr�nglichen URLs verwiesen wird. Verwenden von Cookies Ein Cookie ist ein Token, das der Webserver in den Webbrowser eines Benutzers einbettet, um den Benutzer zu identifizieren. Wenn derselbe Browser das n�chste Mal eine Seite anfordert, wird das Cookie, das der Browser vom Webserver erhalten hat, gesendet. Mithilfe von Cookies k�nnen Sie ein Reihe von Informationen einem Benutzer zuordnen. ASP-Skripts k�nnen die Werte von Cookies mithilfe der Cookies-Auflistung der Response- und Request-Objekte abrufen und auch festlegen. Festlegen von Cookies Um den Wert eines Cookies festzulegen, sollten Sie Response.Cookies verwenden. Wenn das Cookie nicht bereits vorhanden ist, wird durch Response.Cookies ein neues erstellt. Wenn Sie z. B. ein Cookie mit dem Namen ("VisitorID") mit einem zugeordneten Wert ("49") an den Browser senden m�chten, sollten Sie den folgenden Befehl verwenden, der auf der Webseite vor dem <HTML>-Tag angezeigt werden muss: <% Response.Cookies("VisitorID") = 49 %> Wenn ein Cookie nur w�hrend der aktuellen Benutzersitzung verwendet werden soll, gen�gt es, das Cookie an den Browser zu senden. Wenn Sie jedoch Benutzer auch dann identifizieren m�chten, nachdem sie den Browser angehalten und neu gestartet hat, m�ssen Sie den Browser zwingen, das Cookie in einer Datei auf der Festplatte des Clientcomputers zu speichern. Um das Cookie zu speichern, sollten Sie das Expires-Attribut f�r Response.Cookies verwenden und das Datum auf ein beliebiges Datum in der Zukunft festlegen: <% Response.Cookies("VisitorID") = 49 Response.Cookies("VisitorID").Expires = "31. Dezember 2001" %> Ein Cookie kann mehrere Werte aufweisen; ein solches Cookie wird als indiziertes Cookie bezeichnet. Dem Wert eines indizierten Cookies wird ein Schl�ssel zugewiesen; Sie k�nnen einen Wert f�r einen bestimmten Cookieschl�ssel festlegen. Beispiel: <% Response.Cookies("VisitorID")("49") = "Travel" %> Wenn ein vorhandenes Cookie �ber Schl�sselwerte verf�gt, Response.Cookies jedoch keinen Schl�sselnamen angibt, wurden die vorhandenen Schl�sselwerte gel�scht. Wenn ein Cookie hingegen nicht �ber Schl�sselwerte verf�gt, Response.Cookies jedoch Schl�sselnamen und -werte festlegt, wird der vorhandene Wert des Cookies gel�scht und neue Schl�ssel/Wert-Paare werden erstellt. Abrufen von Cookies Sie k�nnen den Wert eines Cookies mithilfe der Request.Cookies-Auflistung abrufen. Wenn beispielsweise durch die HTTP-Anforderung des Benutzers VisitorID=49 festgelegt wird, ruft die folgende Anwendung den Wert 49 ab: <%= Request.Cookies("VisitorID") %> Um den Schl�sselwert von einem indizierten Cookie abzurufen, verwenden Sie entsprechend den Schl�sselnamen. Angenommen, der Browser eines Benutzers sendet z. B. die folgenden Informationen im Header der HTTP-Anforderung: Cookie: VisitorID=49=Travel Die folgende Anweisung gibt dann den Wert Travel zur�ck: <%= Request.Cookies("VisitorID")("49") %> Festlegen von Cookiepfaden Alle von ASP auf dem Webbrowser des Benutzers gespeicherten Cookies enth�lt Pfadinformationen. Wenn der Browser eine Datei anfordert, die an dem Standort gespeichert ist, der durch den Pfad im Cookie angegeben ist, leitet der Browser automatisch das Cookie an den Server weiter. Standardm��ig entsprechen die Pfade der Cookies dem Namen der Anwendung, die die ASP-Datei enth�lt, die urspr�nglich das Cookie generierte. Wenn beispielsweise eine ASP-Datei, die sich in einer Anwendung namens Benutzeranwendung befindet, ein Cookie generiert, leitet der Browser immer dann das Cookie weiter, wenn der Webbrowser eines Benutzers eine Datei abruft, die sich in dieser Anwendung befindet. Zus�tzlich werden auch alle anderen Cookies, die den Pfad /Benutzeranwendung enthalten, vom Browser weitergeleitet. Wenn Sie einen anderen Pfad f�r ein Cookie als den Standardanwendungspfad festlegen m�chten, k�nnen Sie das Path-Attribut der Response.Cookies-Auflistung von ASP verwenden. Im folgenden Skript wird beispielsweise der Pfad VerkaufsAnw/Kunden/Profile/ einem Cookie namens Einkauf zugewiesen: <% Response.Cookies("Einkauf") = "12" Response.Cookies("Einkauf").Expires = "1. Januar 2001" Response.Cookies("Einkauf").Path = "/VerkaufsAnw/Kunden/Profile/" %> Wenn der Webbrowser, der das Cookie Einkauf enth�lt, eine Datei anfordert, die unter dem im Pfad /VerkaufsAnw/Kunden/Profile/ oder in einem der entsprechenden Unterverzeichnisse liegt, leitet der Browser das Cookie an den Server weiter. Viele Webbrowser, einschlie�lich Microsoft Internet Explorer, Version 4.0 und h�her, und Netscape, ber�cksichtigen die Gro�-/Kleinschreibung des Pfades f�r das Cookie. Wenn also die Gro�-/Kleinschreibung des Pfades einer angeforderten Datei von der Gro�-/Kleinschreibung des gespeicherten Pfades f�r das Cookie abweicht, wird das Cookie vom Browser nicht an den Server gesendet. Bei ASP stehen die virtuellen Verzeichnisse /REISEN und /reisen f�r dieselbe ASP-Anwendung; bei einem Browser hingegen, der die Gro�-/Kleinschreibung eines URL beachtet, handelt es sich bei /REISEN und /reisen um zwei verschiedene Anwendungen. Sie sollten sicherstellen, dass alle URLs auf ASP-Dateien die Gro�-/Kleinschreibung gleicherma�en handhaben, damit gew�hrleistet wird, dass der Browser des Benutzers die gespeicherten Cookies weiterleitet. Sie k�nnen die folgende Anweisung zum Festlegen des Pfades f�r Cookies verwenden, damit der Webbrowser des Benutzers immer dann ein Cookie weiterleitet, wenn der Browser - unabh�ngig von der Anwendung oder vom Pfad - eine Datei vom Server anfordert: Response.Cookies("Einkauf").Path = "/" Sie sollten jedoch beachten, dass durch das Weiterleiten von Cookies an den Server ohne Unterscheidung zwischen Anwendungen ein m�gliches Sicherheitsrisiko entsteht, wenn die Cookies vertrauliche Informationen enthalten, die au�erhalb einer bestimmten Anwendung nicht zug�nglich sein sollten. Beibehalten des Status ohne Cookies Cookies werden nicht von allen Browsern unterst�tzt. Selbst bei Browsern, die Cookies unterst�tzen, deaktivieren einige Benutzer lieber die Unterst�tzung von Cookies. Wenn Ihre Anwendung auf Browser zur�ckgreifen muss, die Cookies nicht unterst�tzen, k�nnen Sie die Sitzungsverwaltung von ASP nicht verwenden. In diesem Fall sind Sie gezwungen, eigene Verfahren zum �bergeben von Informationen von einer Seite zur anderen in Ihrer Anwendung zu schreiben. Es stehen Ihnen dabei zwei grunds�tzliche Ansatzm�glichkeiten zu Verf�gung: Hinzuf�gen von Parametern zur Abfragezeichenfolge eines URLs. Beispiel: http://Server1/Anw1/start.asp?name=Johannes Einige Browser verwerfen jedoch explizite Parameter, die in einer Abfragezeichenfolge �bergeben werden, wenn ein Formular mithilfe der GET-Methode �bermittelt wurde. Hinzuf�gen von verdeckten Werten zu einem Formular. So enth�lt z. B. das folgende HTML-Formular ein verdecktes Steuerelement, das auf dem tats�chlichen Formular nicht angezeigt wird und im Webbrowser der Benutzer ebenfalls nicht sichtbar ist. Das Formular �bergibt mithilfe der HTTP POST-Methode, neben den vom Benutzer bereitgestellten Informationen, einen Wert f�r die Benutzeridentifizierung. <FORM METHOD="POST" ACTION="/scripts/inform.asp"> <INPUT TYPE="text" NAME="Stadt" VALUE=""> < INPUT TYPE="text" NAME="Land" VALUE =""> <INPUT TYPE="hidden" NAME="BenutzerID" VALUE= <%= UserIDNum(i) %> <INPUT TYPE="submit" VALUE="Enter"> Bei dieser Methode ist es notwendig, dass alle Verkn�pfungsziele, die Benutzerinformationen �bergeben, als HTML-Formulare kodiert werden. Wenn Sie nicht mit der Sitzungsverwaltung von ASP arbeiten, sollten Sie die Unterst�tzung von Sitzungen f�r Ihre Anwendung deaktivieren. Wenn dieses Feature jedoch aktiviert ist, sendet ASP ein SessionID-Cookie an alle Browser, die eine Seite anfordern. Sie k�nnen die Unterst�tzung von Sitzungen deaktivieren, indem Sie das Kontrollk�stchen Sitzungszustand aktivieren auf dem Eigenschaftenblatt Anwendungsoptionen im IIS-Snap-In deaktivieren. ASP-Seiten ohne Session Mit ASP haben Sie zudem die M�glichkeit, Seiten ohne Session zu erstellen, mit deren Hilfe Sie das Erstellen von Sitzungsnachverfolgungen nach Bedarf verz�gern k�nnen. Seiten ohne Session f�hren Folgendes nicht aus: Ausf�hren von Session_OnStart -Prozeduren. Senden von SessionID-Cookies. Erstellen von Sitzungsobjekten. Zugreifen auf integrierte Sitzungsobjekte oder Objekte mit Sitzungsbereich, die mithilfe des <OBJECT>-Tags erstellt wurden. Einreihen der Ausf�hrung mit anderen Sitzungsanforderungen. Um eine ASP-Datei ohne Session zu konfigurieren, verwenden Sie Folgendes: <%@ EnableSessionState=False %> Sie sollten dieses Skript vor allen anderen Skripten in der ersten Zeile der ASP-Datei ablegen. In der Standardeinstellung (bei Auslassen dieses Tags) wird das Nachverfolgen von Sitzungen aktiviert. ASP-Seiten ohne Session tragen oftmals dazu bei, die Reaktionszeit des Servers durch Beseitigen potenziell zeitaufwendiger Sitzungsaktivit�ten zu verbessern. Betrachten Sie beispielsweise eine ASP-Seite mit zwei HTML-Rahmen, Rahmen 1 und Rahmen 2, innerhalb einer Rahmengruppe, etwas genauer. Rahmen 1 enth�lt eine ASP-Datei, die ein komplexes Skript ausf�hrt, w�hrend Rahmen 2 eine einfachere ASP-Datei enth�lt. Da ASP Sitzungsanforderungen in sequenzieller Reihenfolge oder seriell ausf�hrt, k�nnen Sie den Inhalt von Rahmen 2 erst dann sehen, wenn das Skript in Rahmen 1 ausgef�hrt wurde. Im Falle einer ASP-Datei ohne Session in Rahmen 1 werden die ASP-Anforderungen nicht l�nger seriell ausgef�hrt, und der Browser rendert den Inhalt von Rahmen 2, bevor das Ausf�hren des Inhalts von Rahmen 1 beendet wird. Leider h�ngt die Art der Verarbeitung mehrerer Anforderungen f�r unterschiedliche Rahmen letztlich von der Konfiguration des Webbrowsers der Benutzer ab. Bestimmte Webbrowser f�hren Anforderungen trotz der Konfiguration der ASP-Dateien ohne Session seriell aus. ------------------------------------------------------------------------ -------- � 1997-1999 Microsoft Corporation. Alle Rechte vorbehalten. | Oft Gefragtes: http://www.aspgerman.com/aspgerman/faq/ | [aspdebeginners] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdebeginners/ = Listenarchiv | Sie knnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdebeginners.asp
