With normal CGI, a process is spawned for each request. You have to make sure that you identify the user, for example by examining the session. If two of these requests happen at the same time, it's the web server's job not to confuse them.
Perl 6 - links to (nearly) everything that is Perl 6.
| [reply] |
Thanks moritz
How do we ensure that the server will do it's job right not to confuse the two users - it's a shared server.
| [reply] |
> How do we ensure that the server will do it's job right
> not to confuse the two users - it's a shared server.
You have to do this, not the server. Imagine user A is looking at a web page. On that web page, it says, "Hello user A", which is a result of a template, say, welcome.tmpl, which says "Hello user <TMPL_VAR USERNAME>", which, in turn, is filled by a script, say, query.cgi, which queries a data store $tmpl->param(USERNAME => $self->getuser).
Since query.cgi was called by user A, which caused welcome.tmpl to be filled with the retrieved values and sent back to user A, user B can never see what user A requested. This is because the web is stateless. One query does not know from another, even from the same user, let alone from different users. Unless...
Unless, user A is requesting something that is held in the server's memory. This is where things get screwy. This is where the concept of sessions comes in. Somehow, you, the programmer, has to ensure that the web server "remembers" who is requesting what. The web server can't do that on its own. You have to do something to make this happen. An excellent way to do that is by using a module such as CGI::Session, or CGI::Application::Plugin::Session, essentially a wrapper around the former.
Using sessions, you utilize a cookie (or a URI parameter) to make one request be connected to a previous request. Then you utilize that connection to make sure you are getting the correct data back for the user that has requested it.
--
when small people start casting long shadows, it is time to go to bed
| [reply]
[d/l] |
| [reply] |