The session object

HTTP is a stateless protocol, and yet applications need to maintain state on the server related to the interactions of a particular user. For example, in a shopping cart application, requests from multiple users must be distinguished so that the views they see reflect all their previous requests, and only their own prior requests. This requires a mechanism for implementing stateful interactions layered on top of the stateless HTTP transport protocol.

Most Web frameworks use the session concept to allow applications to maintain state associated with requests from a specific client. This is generally implemented by storing a session identifier on each client that is passed back with every request and can then be used on the server side as a key to a lookup table that contains the state for the client.

Woof! provides this feature through the session object. When a request comes in, Woof! creates an object of class Session, which may correspond to a new session or contain content of an existing session to which the request has been mapped. Application code may access and store items in this session using the standard Map, interfaces. Internally, Woof! implements sessions through the use of HTTP cookies on the client to store the session identifier.

When the request is handled, the contents of the session object are automatically stored by Woof! and restored when the next request is received from the same client.

Because storage/retrieval has a non-trivial cost, sessions are created in lazy fashion. If the application does not store data in the session, no overhead is imposed.

Refer to the sample application in the chapter Quick start for an example of using the session to store state.

The session cookie

The session identifier is sent by the client as an HTTP cookie. By default, the name of the cookie is woofsid. If there are multiple Woof! installations on a single site, each installation needs to use a different cookie name to prevent confusion between sessions belonging to applications for each installation.

To prevent this, you can change the name of the cookie by assigning the variable session_key_name in the configuration file. Each installation for the site should use a different name.