Hi Hallvard, > OK, the reason I did this, is I wonder if I can have a CGI script close the > connection to user and then continue processing some data afterwards. So that > the web user wouldn't have to wait ages for the browser to tell him the page > has finished loading when actually it is. > > The following CGI script didn't do the trick. Anyone got an idea?
I tried to find a foolproof way of doing this for something we needed or REBOL.org. I failed. Part of the problem is that you can't control when the server sends the data. If you only have a small amount of data (not enough to fill whatever is a block transmitted across the Internet) that probably won't be until your CGI quits. I tried various cunning schemes, like explicitly setting a Content-length header and then sending more data than that (to force a block transmit). They didn't work. In the end, in our case, as we only need to run some non-user background stuff occasionally, I added some rudimentary code to check that the request is not from a human being. So we only run the "background task" if the referrer is a bot. I don't mind keeping them waiting a couple of seconds once in a while. And the "background task" is self-limiting -- it'll stop after a couple of seconds, whether it's finished or not. The site is hit by bots hundreds of times a day -- so the background task never has to wait long to resume. This kludge works because the background processing we need to do is not related to the current message -- it's the equivalent of an occasional recycle to keep things current. Of course, we have to check that the background task isn't already running (if we get two bots that trigger it in the same second or so). If you find a better solution, please let me know! Sunanda. -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
