The CGI protocol is wonderful for the remote execution of short tasks. But how do you execute a longer task? A task can’t just run without giving some kind of feedback to the user — eventually either the user will get bored or Apache will drop the connection.
The CGI protocol is wonderful for the remote execution of short tasks. But how do you execute a longer task? A task can’t just run without giving some kind of feedback to the user — eventually either the user will get bored or Apache will drop the connection.
I’ve seen (and written) some solutions that depend on “server push”, but not all browsers support that feature. Other solutions I’ve seen slowly write simple HTML and rely on the browser to incrementally render a page to reflect activity. Again, you can’t count on that behavior across the browser spectrum.
But one solution that minimizes server overhead and dependence on browser peculiarities is client pull, also called “meta refresh”. In client pull, the initial request forks a process to perform the real work and redirects the browser to a new URL that “pulls” the results obtained so far. While the results remain incomplete, an additional header instructs the browser to “refresh” the data after a predetermined number of seconds.
All that sounds messy. For example, how will each CGI invocation know what data to display? Where will this data be? And, how will requests manage inter-process communication? Believe it or not, the solutions are not as daunting as they might seem.
First, each CGI request will be assigned a unique “session key” that’s hard to guess, but easy to hand around. This session key provides all the differentiation we need. In my sample code, I’m using the MD5…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including:
