Raymond Wiker  <raw@RawMBP.local> wrote:
+---------------
| Slobodan Blazeski <slobodan.blazeski@gmail.com> writes:
| > How do you use sessions in single thread? Or some other mechanism
| > for people to get their customized page when they login?
| 
| One word: cookies.
| Alternatively, encode a session id in query parameters.
+---------------

The problem with cookies is that they're common to all window/tab
instances within a browser. When a user has multiple windows/tabs
open on your site, if you store state information in cookies you're
going to leak information between different active windows/tabs.
This is rarely good for storing "continuations" within a single
session, but can be good for authentication data [with suitable
encryption].

The problem with encoding session IDs in query parameters is
garbage collection of "sessions".

A third method is to store the entire continuation within
(hidden) query parameters. I tend to prefer this one, as
it allows diffent user windows/tabs to take different paths
within your site and collect separate stateful data along
the way, without leaving any "session" state on the server
that needs garbage collecting.

Authentication/encryption/serialization to avoid replay attacks
is needed for all three methods.

+---------------
| This is necessary, whether you have threading available or
| not, as HTTP is a connectionless protocol. 
+---------------

Slight quibble on terminology: HTTP *is* a connection-based protocol,
since it uses TCP, which sets up [and tears down] a connection for
each HTTP request. Or maybe even holds the same connection open
across *several* requests, if both sides respect the HTTP 1.1
"Connection: open" protocol.

What you're trying to say is that HTTP is *stateless* between
HTTP requests, which it is, even when there are multiple HTTP
requests within a single TCP connection.


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607