Session State
HTTP is a stateless protocol in that each request is independent of the requests before it and after it. However, many applications need to store client state to operate effectively. Web site login mechanisms are a good example of needing to store client state so that subsequent requests by a user can be authorized to access private portions of the site.
To implemenet session state, a means of tagging each request with a unique identifier is employed. This is most often via a client side cookie which stores a session identifier. The web server then uses that identifier to locate a state variable store for that particular client.
To implemenet session state, a means of tagging each request with a unique identifier is employed. This is most often via a client side cookie which stores a session identifier. The web server then uses that identifier to locate a state variable store for that particular client.
ESP Session State Overview
Embedded Server Pages supports an integrated session state facility. It creates and manages user sessions including creating client session cookies, session expiration and cleanup and per-session state variable stores. The ESP session state service may be utilized from JavaScript in the ESP pages or from C/C++ code using the ESP C API.
The ESP session mechanism stores the client session state data centrally in AppWeb and indexes the sessions using a session ID that is also stored in the client's browser via a session cookie. Once a session is created, subsequent requests from the client's browser will include the Session ID cookie which is then used by AppWeb to locate and access the session data for requests from that client. The session cookie is automatically created on the first request that requires session handling. The cookie is given an expiry time that corresponds to the configured session expiry time.
A session data store corresponds to a unique browser instance. If a user creates multiple windows or browsing tabs, these may actually share a session. AppWeb ensures that session data accesses are as fast as possible by storing session data at the server and by using a fast hash lookup.
A Session data store is maintained for each user session and is automatically destroyed after a configurable timeout period of inactivity (usually 30 minutes). In AppWeb, the SessionTimeout configuration directive may be used to modify this timeout period. In WebServer, this is a config.h setting. Session timeouts may also be explicitly specified by using the createSession JavaScript command.
Sessions may be explicitly manipulated, but are normally created automatically for ESP pages if the SessionAutoCreate directive is enabled. Otherwise, an ESP page should call useSession or createSession first thing in the ESP page.
The following example demonstrates accessing the session data store and the session ID. It assumes that SessionAutoCreate is enabled.
The session[] array can store any arbitrary JavaScript data type or object.
How It Works
The ESP session mechanism stores the client session state data centrally in AppWeb and indexes the sessions using a session ID that is also stored in the client's browser via a session cookie. Once a session is created, subsequent requests from the client's browser will include the Session ID cookie which is then used by AppWeb to locate and access the session data for requests from that client. The session cookie is automatically created on the first request that requires session handling. The cookie is given an expiry time that corresponds to the configured session expiry time.A session data store corresponds to a unique browser instance. If a user creates multiple windows or browsing tabs, these may actually share a session. AppWeb ensures that session data accesses are as fast as possible by storing session data at the server and by using a fast hash lookup.
Timeouts
A Session data store is maintained for each user session and is automatically destroyed after a configurable timeout period of inactivity (usually 30 minutes). In AppWeb, the SessionTimeout configuration directive may be used to modify this timeout period. In WebServer, this is a config.h setting. Session timeouts may also be explicitly specified by using the createSession JavaScript command.Sessions may be explicitly manipulated, but are normally created automatically for ESP pages if the SessionAutoCreate directive is enabled. Otherwise, an ESP page should call useSession or createSession first thing in the ESP page.
The following example demonstrates accessing the session data store and the session ID. It assumes that SessionAutoCreate is enabled.
<%
if (request['REQUEST_METHOD'] == "POST") {
//
// User has submitted the page
//
if (ok == "Cancel") {
redirect(prev);
} else if (ok == "Ok") {
session["name"] = form["name"];
session["address"] = form["address"];
sessionId = request["SESSION_ID"];
}
} else {
var name = "Your name";
var address = "Your address";
trace("Session ID" + request["SESSION_ID"]);
}
%>
The session[] array can store any arbitrary JavaScript data type or object.