[3897] in WWW Security List Archive
RE: Maintaining state with CGI
daemon@ATHENA.MIT.EDU (John W Pierce)
Mon Dec 23 21:12:36 1996
From: John W Pierce <jwp@r2systems.com>
To: "'www-security@ns2.rutgers.edu'" <www-security@ns2.rutgers.edu>
Date: Mon, 23 Dec 1996 16:33:30 -0800
X-MDaemon-Deliver-To: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
The frame technique is exceptionally nice when you can control the browser. I particularly like the gif idea (hadn't thought of that)
and will happily steal it :). The two mechanisms are complimentary,
not exclusive. "Persistent" CGI works very well when coupled with
frames as described (and you don't need to keep state on the page).
One point of persistent CGI is to maintain a virtual circuit
connection to a backend application. Relational database work is
a good example of something that's eased by that. The database
portion can be done exactly as if it were a (data-knowledgeable)
part of a standalone program. This allows use of a good amount of
"legacy" code: nobody wants to rewrite a 100K lines of COBOL order
entry data verification just to make it web-based. Interactive
programs are often good candidates for this sort of thing. We even
once built web access to a program that would only talk to 3270s
(this was a terrible project, actually - 3270s have ugly I/O).
The most common case (for us) is where what's sent to the browser
depends on complex relationships among data elements obtained in
previous browser contacts during the "session" (and, often, on
other data on the server). Web-based surveys are a good example:
"If this is a Caucasian female programmer who responded 'yes' to
question 7, 'no' to question 19, got question 26varC [the variant
for question 26 is randomly selected], then skip question 49, and
ask questions 52varB and 53varA; however, if she got question 26varA
and we have had less than 37 respondents in her category, use
question 53varD; however..." (This is not much exaggerated, either.)
Sure, you can maintain all of this on a page in "hidden" variables
(thus exposing it to the user), or in files, or in a database table
for temporary incomplete entries. And then map the session key to
the temporary entries if they're not on the incoming page. And every
time you need state, it has to be read and reparsed (and, if it was
stored on the page, verified). And, of course, for every browser
contact you incur the overhead of a server fork and the exec of the
interpreter for your CGI program (unless you've written it in C/C++).
You also have clean up of temporary files/tables to handle, multiple
scripts to check if you change a variable name on a form, etc, etc,
ad infinitum. And you have to figure out how to allow the user to
go back and edit stuff they've already sent (or prevent them from
doing so, as the case may be).
Persistent CGI scripts don't solve all problems; nothing does. It won't even (unfortunately) get rid of all uses for Java. But it does
make a lot of problems easier to solve at the expense of something
like 200 lines of code that you can write (and get right) once and
then ignore. The httpd server forks only once for each session,
rather than many times, and the interpreter starts up only once for
each session. The overhead reduction is considerable, at the expense
of a runnable process and an open port for the period of each session
(which is the reason for putting in a time-out).
-- John W Pierce, R2 Systems, San Diego
jwp@r2systems.com
