doe 'view source' om te kijken hoe de hidden fields van waarde veranderen.

Een andere manier is om de 'state' als parameters aan de URL te plakken, zoals bijvoorbeeld bij HotBot (searchengine) gebeurt :

De parameters worden er door een script op de server afgestript en doorgegeven aan het programma (de search engine) wat de sessiegegevens van de gebruiker nodig heeft.

Weer een andere manier is het gebruiken van 'cookies' - een bestandje met sessie-informatie

Een programma op de site genereert dit cookie (via de WebServer). De server geeft het door aan de browser van de gebruiker en deze slaat het op op de schijf van de gebruiker.

Elke keer als de gebruiker naar die site terug gaat, geeft de browser het opgeslagen cookie weer 'terug' aan de webserver

zie c:\winnt\cookies (IE) of c:\program files\netscape\users\yourname\cookies.txt

De oplossing die Microsoft heeft bedacht voor het 'stateless' zijn van HTTP is als volgt :

MS onderscheidt 'applications en 'sessions'

Een Application is een directory op de Web Server (met executable rechten). De directory moet de 'root' dir zijn van de Web Server of een Virtuele directory (www.webserver.com/virtualdir/) .Elke root- of virtuele directory kan dus een aparte Application bevatten met een eigen Application Object.

Een Session is de sessie van een individuele gebruiker met een Application

Als een Application voor het eerst door een gebruiker wordt benaderd (een gebruiker laad een pagina uit die dir) wordt er een Application Object aangemaakt, maar ook een Session Object voor die specifieke gebruiker (want het is de 1ste keer dat hij de Application benadert) en volgende gebruikers.

Bij het aanmaken van een Application Object hoort ook het uitvoeren van de Application OnStart subroutine . Bij een Session Object gaat het om de Session OnStart subroutine. Deze subroutines staan in een apart bestand (global.asa) dat kan worden beschouwd als een soort Autoexec.bat bestand. Wat er in deze subroutines komt te staan wordt bepaald door de programmeur.

Elke gebruiker krijgt een uniek sessionid wat dmv een cookie wordt bijgehouden. Bij elk contact van de browser met de site wordt het SessionID naar de server gestuurd. De rest van de sessie-informatie staat in het geheugen van IIS (MS Webserver) en wordt via het SessionID aan de gebruiker gekoppeld. Het is dus belangrijk dat de SessionObjects worden opgruimd als ze niet meer nodig zijn anders loopt het geheugen van IIS vol !

Normaal gesproken gaat dit vanzelf omdat je een timeout waarde (default is 20 minuten) kunt instellen. Als de gebruiker dan een tijd niets doet, wordt de sessie verbroken en het Sessie object opgeruimd.

De programmeur kan zoveel info aan het session object (en ook aan het Application Object) toevoegen als hij wil. Dit gaat als volgt :

<%session("LastName") = "van Roeden" %> of <%session("Score") = 10%> of

<%application(message") = "Maak nu gebruik van onze geweldige korting op alle UNIX producten!" %>

Session data ophalen gaat zo :

Mijn achternaam = <%=session("LastName") %> of

Uw score = <%=session("Score")%> of : Let op ! <%=application("message")%>

De gegevens die in het Application Object staan zijn dus voor alle gebruikers van de Application (Site) beschikbaar en die in het Session Object zijn voor 1 gebruiker beschikbaar zolang zijn sessie duurt.

Het spelletje kan je dus dmv het Session Object programmeren omdat je hierin kunt bijhouden welke vragen zijn beantwoord en wat de score is.

ASP docs :