Raymond Wiker <raw@RawMBP.local> wrote:
| Slobodan Blazeski <firstname.lastname@example.org> 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
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 Warnock <email@example.com>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607