[3827] in WWW Security List Archive
RE: Germany bans cookies! (and a whole lot more)
daemon@ATHENA.MIT.EDU (John W Pierce)
Tue Dec 17 18:12:32 1996
From: John W Pierce <jwp@ucsd.edu>
To: "www-security@ns2.rutgers.edu" <www-security@ns2.rutgers.edu>
Date: Tue, 17 Dec 1996 13:19:12 -0800
Errors-To: owner-www-security@ns2.rutgers.edu
Jacob Rose[SMTP:jacob@whiteshell.com]
... if you mean that Web servers should spawn stateful threads to handle
each session, this isn't possible either without some kind of client
identification, since HTTP requests from a single client are all
totally independent, each a seperate event.
While this is technically true, where state is needed between separate HTTP
requests from the same client, it's possible to achieve what's usually needed
on a practical level with CGI. Rather than pass state or ID info from one page
to the next via hidden variables or cookies a CGI script that implements the
following algorithm (more or less) will work:
http server accepts contact and starts the CGI script
CGI script selects a random unused port
CGI script forks
in the parent
send a redirection message to the client, sending it to the new port
exit
in the child
start up some timeout procedure
listen for the incoming connection
process the request
wait for more requests
when we timeout or get some other "done" indication
exit
(In case it's not obvious, you need to fork and have the parent exit in order
to convince the controlling httpd process to go away, otherwise it hangs around
for the entire "session", which is wasteful at best.) This is trivial in Pike
or Tcl or C (or C++ or Perl or Java, but I find those just too ugly to use).
Clearly, each client HTTP request is still a separate entity (as Jacob points
out, that's the nature of HTTP), but the "feel" of a virtual circuit connection
can be provided. All state can be maintained on the CGI side, it can open a
persistent connection to a database server, etc.
-- John W Pierce, Chem & Biochem, UC San Diego
jwp@ucsd.edu
