Re: Reasons to choose CLISP over other free implementations

rpw3@xxxxxxxx (Rob Warnock) writes:

Raymond Wiker <raw@xxxxxxxxxxxx> wrote:
+---------------
| Slobodan Blazeski <slobodan.blazeski@xxxxxxxxx> 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.

I was about to say that this is the same as what I suggested,
but it (obviously) is not, and I agree completely that this may be the
best option.

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.

No, HTTP is connectionless, but is commonly implemented on top
of a connection-oriented 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@xxxxxxxx>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
.

Relevant Pages

  • Re: HttpContext.Current.Session is null
    ... private static readonly CProjTest Instance = new CProjTest; ... HttpContext,as well as Session are created only for a HTTP request, ... I think you're trying to get session from a code that has nothing to do ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Hardening the TCP/IP Stack Qt. - KeepAliveTime
    ... TCP resources are not held for two hours. ... connection, makes the request, receives the reply, and then closes the TCP ... HTTP 1.1, on the other hand, uses HTTP keep-alives by default. ... App session state controls application-side sessions created using ASP, PHP, ...
    (microsoft.public.win2000.security)
  • Re: Reasons to choose CLISP over other free implementations
    ... session, but can be good for authentication data [with suitable ... each HTTP request. ... Or maybe even holds the same connection open ...
    (comp.lang.lisp)
  • Where is HttpSession ? System.net or System.web?
    ... I'm trying to do a http request and read a http session. ... I have looked arond a bit, but I cant find any "HttpSession" object .. ...
    (microsoft.public.dotnet.framework)
  • Re: Hardening the TCP/IP Stack Qt. - KeepAliveTime
    ... the session is never fully ... > TCP resources are not held for two hours. ... > connection, makes the request, receives the reply, and then closes the TCP ... HTTP 1.1, on the other hand, uses HTTP keep-alives by ...
    (microsoft.public.win2000.security)