[EMAIL PROTECTED] writes:
> > I suspect he was trying to say that BaseHTTPServer has no mechanism for
> > handling state. As you know, of course, this is most relevant across
> > multiple successive connections to a server from the same client, and
> > has little to do with threads.
Usually you would do that with browser cookies.
> Correct. My own 'brew' is multi-session-clients enabled (in fact I test
> with two applets from the same PC) but indeed I used confusing language
> saying 'client' for 'session'.
>
> Again: ThreadingMixIn doesn't give you 'session threads' in which you
> store persistent information - a candidate for some generic extension
> of SocketServer ?
What exactly do you mean by session? Let's say the client does
the following:
1. Sends
GET /abcde HTTP/1.1
Connection: Keep-Alive
and downloads the abcde page
2. Sends
GET /fghij HTTP/1.1
and downloads the fghij page, re-using the TCP connection from step 1
3. Opens a completely new TCP connection and sends
GET /klmno HTTP/1.1
through the new connection, and downloads klmno through that
connection.
How many sessions took place here? It sounds like you want the answer
to be one session, that operations 2 and 3 are part of the same session.
But that makes no sense unless you associate them somehow, say using
a client cookie and a global session table indexed by the cookie.
Why don't you take a look at any of the web frameworks that get
discussed here (Spyce, CherryPy, Zope, Django, whatever). They all
have mechanisms like that. BaseHTTPServer doesn't try to operate
at that level.
--
http://mail.python.org/mailman/listinfo/python-list
